A patient-free protocol for evaluating injection mapping software

Injection mapping can mean several different things. A product may place marks on a generic diagram, annotate a patient photograph, preserve coordinates on a three-dimensional face, store a quantity beside each point, or simply attach an image to a free-text note. Those interfaces are not interchangeable. Write down the record your practice needs before comparing how attractive each map looks.

For this protocol, the core job is narrow: a qualified practitioner deliberately records locations and values that the practitioner has already chosen, reviews the derived summary and later reopens those details in the correct patient and treatment context. Clinical assessment, anatomical judgement, product selection, dose selection and technique remain outside the test. A map should represent practitioner input; it should not quietly become an unverified recommendation engine.

Create a synthetic profile clearly labelled DEMO. Do not use a colleague, a real patient, a real date of birth or an identifiable photograph. Select a fictional treatment label, a test product name and a lot value such as DEMO-LOT. Choose at least two neutral test areas and several deliberately distinctive sentinel values. The values exist only to make omissions, swaps and calculation errors visible; they are not treatment quantities and must not be reused clinically.

Write the expected result before the test begins. Record how many points should exist, which point owns each sentinel value, what summary should be derived, whether a correction must be visible and where the final record should be found. Give every vendor or internal build exactly the same scenario and record the observed evidence consistently so the comparison remains useful.

Begin from the professional workspace rather than a pre-opened demonstration screen. Locate the synthetic patient, start the fictional treatment and observe how the product preserves the active patient, practitioner and treatment type while the evaluator moves forward and backward. Add every planned point and value, then review the calculated result against the written expectation.

Do not award a pass because a map looks correct before saving. Complete the workflow, reopen the treatment from the patient history and compare the persisted record with the expected result. If the product offers more than one view—practitioner history, clinic dashboard, export or patient-held history—record which details appear in each view and which access action produced them.

Most software demonstrations show one uninterrupted forward path. Operational failures occur at the edges: a point is misplaced, the wrong value is entered, a user goes back, connectivity drops, an attachment remains pending, or a save button is pressed twice because the result is unclear. The evaluation should make these states visible before the team uses the system with real records.

Perform only controlled disruptions in a test account. Never simulate failure against live patient data. After every correction or interruption, write down what the user saw, whether the system preserved valid work, whether a duplicate could be created and how the final state was confirmed. A recoverable workflow should explain what happened and what action remains; silence is not recovery evidence.

Score each critical requirement from observed evidence such as a reopened record, an export, a documented security answer or a controlled test observation. Give reliable point-level retrieval, correct summaries and patient-context integrity their full weight instead of allowing convenience-feature counts to dominate the result.

Then evaluate category fit. A focused documentation platform can provide deep mapping and patient continuity, while broader clinic suites and general medical systems emphasise different operating jobs. The strongest decision follows the practice's primary workflow and the quality of verified evidence rather than the longest feature list.

A product that passes the fictional protocol has earned a pilot, not automatic production approval. Define a small permitted cohort, named implementation owner, training method, exception route and review date. The clinic remains responsible for role eligibility, consent, documentation requirements, data protection, retention and any professional supervision that applies in its jurisdiction.

Repeat the protocol after material product changes and before expanding to additional treatment categories or locations. Preserve the dated result so the team can distinguish verified behaviour from assumptions carried forward from an older version. If a requirement changes, update the expected record first and then rerun the scenario.

drylabs GmbH created this protocol from clinician-led workflow design, software implementation and testing of the published Aesthetic Pass product. The method deliberately uses a fixed patient-free scenario, observable acceptance evidence and failure paths. It is not an independent market ranking, certification, clinical protocol, penetration test or legal assessment.

drylabs GmbH sells Aesthetic Pass. No external vendor paid to be included, and the protocol can be used with any product. Aesthetic Pass should pass the same acceptance gates it asks evaluators to apply elsewhere. The resource will be reviewed after material mapping-workflow changes, relevant source changes or evidence from repeated provider evaluations.