Legit.Health Plus

In this section, we present practical examples of workflows that can be integrated into your systems, utilizing the data provided by our device's API.

We recognize that incorporating data from our API into your existing systems can be a complex task, particularly if this is your organization's first experience with such a device. These examples are designed to assist and guide you through this integration process.

Please note that the flexibility of our API allows for a wide range of workflow implementations. The examples here are not exhaustive and should not be interpreted as the only methods or as endorsements of particular practices. Each organization has unique needs and requirements. Consequently, it's crucial for managing organizations to develop workflows that align with their internal best practices and adhere to the guidelines set forth by their medical professionals.

Puzzle pieces

Consider the output from our device akin to pieces of a puzzle. The device generates a JSON file, abundant in data, organized under various keys. These keys serve as fundamental elements in your workflow design process. You can envision each key as a distinct branch in a decision-making tree or, more creatively, as a unique puzzle piece. This analogy highlights the flexibility and adaptability of the data; you can arrange and integrate these pieces in numerous configurations to suit your specific workflow needs.

Further reading

Please read the Installation Manual section of the Instructions For Use for more info.

DiagnosisSupport endpoint keys

SeverityMeasure endpoint keys

There are more puzzle pieces

The API returns many more fields than the ones shown here. These examples only highlight a small subset of keys that are especially useful for triage and operational routing.

Workflows by Clinical and Operational Objective

The same output can support very different workflows. A safety-first triage flow might rely heavily on urgentReferralProbability, while a capacity-oriented flow may use entropy and severity to decide which cases can stay in lower-intensity pathways.

In practice, organizations usually combine several objectives at once: reduce missed severe cases, protect specialist capacity, and keep low-risk follow-up manageable. The examples below illustrate how the same pieces can be arranged differently depending on the operational goal.

1. Empowering Primary Care (Triage)

Objective: Reduce first visits to dermatology by filtering out benign or straightforward cases at the primary care level.

This flow uses urgentReferralProbability as the first escalation signal, highPriorityReferralProbability as the next referral filter, and entropy as an uncertainty gate.

2. Enabling Telemedicine (Remote vs In-Person)

Objective: Decide which visits can be safely resolved remotely and which require an in-person consultation, minimizing unnecessary hospital visits.

	🤳 Remote	🏥🚶 In-person
Primary care	R1	P1
Secondary care	R2	P2

Organizations can reserve in-person specialist capacity for cases that are both high risk and hard to classify.

3. Optimizing Chronic Patient Follow-ups

Objective: Reduce the volume of unnecessary follow-up visits, particularly in chronic pathologies, by checking if the condition persists and assessing its severity.

Progressing as expected	OK
Anomaly	!

By incorporating the patient's history, we can determine if a previously diagnosed condition is still present and assess if the severity indicates an anomaly.

4. Routing to Sub-specialists (Pigmented Lesions)

Objective: Direct cases involving pigmented lesions exclusively to specialized dermatologists (e.g., experts in dermoscopy or melanoma).

5. Cross-specialty & Custom Pathology Routing

Objective: Route patients to other medical specialties (such as gastroenterology, rheumatology, allergology, or genetics) when the dermatological lesion is a manifestation of an underlying systemic disease, a comorbidity, or a rare condition.

This relies on the hypotheses array. Organizations can define criteria to trigger these referrals, such as checking if a specific code appears in the Top-1 or Top-3 results, if its probability exceeds a certain threshold (e.g., >20%), or even based on the sum of probabilities for a group of related conditions.

6. Filtering Non-Dermatological Consultations

Objective: Prevent unnecessary primary care consultations for issues that do not correspond to dermatological problems.

7. Prioritizing Waiting Lists

Objective: Reorder current waiting lists dynamically to ensure patients with higher clinical needs are seen first.

8. Prevention Campaigns & Occupational Health

Objective: Implement automated screening flows during occupational health checks or public prevention campaigns.

9. Automating Pre-requisite Medical Tests

Objective: Automate the scheduling of supplementary tests (such as scans or biopsies) prior to the specialist appointment if certainty metrics are met.

Real-World Case Studies

Sanitas Hospitales: Primary vs. Secondary Care Triage

In this scenario, the organization (Sanitas Hospitales) splits cases into two outcomes to effectively manage their patient flow between Primary and Secondary Care levels.

Primary care	1
Secondary care	2

Here is their configured workflow with real operational thresholds:

This flow uses urgentReferralProbability as the first escalation signal, entropy as the uncertainty gate, highPriorityReferralProbability as the next referral filter, and sign intensity as the final discriminator when available.

DKV: Enabling Telemedicine via Clinical Protocols

In this scenario, the organization combined the AI outputs with traditional clinical questionnaires, such as the 7-point checklist (7PC), to determine the most appropriate consultation method.

The 7-point checklist (7PCL) is recommended by NICE for routine use in general practice to identify clinically significant lesions requiring urgent referral.

Thresholding

As you can see, the puzzle pieces sometimes require deciding on a threshold from which different actions may be taken. Different use cases may require different thresholds, usually depending on the possible outputs of the workflow.

How to decide a threshold

To measure what is the appropriate threshold for a parameter, we use confusion matrixes.

A confusion matrix is a fundamental tool in statistical classification and machine learning. It is a specific table layout that allows visualization of the performance of an algorithm, typically a classifier. The matrix compares the actual target values with those predicted by the model, providing insight into not only the performance of the classifier but also the types of errors it is making.

The confusion matrix is typically a 2x2 matrix for binary classification tasks:

• True Positives (TP): These are cases where the classifier correctly predicts the positive class.
• True Negatives (TN): These are cases where the classifier correctly predicts the negative class.
• False Positives (FP): These are cases where the classifier incorrectly predicts the positive class (also known as Type I error).
• False Negatives (FN): These are cases where the classifier incorrectly predicts the negative class (also known as Type II error).

In a classification task, especially in probabilistic classifiers, the threshold is a concept that must be correctly understood. In essence: a threshold is the point at which the probability of a data point being in one class over another is decided.

• When the model's predicted probability for a class is higher than the threshold, it classifies the data point into that class.
• Conversely, if the probability is lower than the threshold, it classifies the data point into the other class.

Where is this value?

The confusion matrix is provided by us, as it is the result of the extensive testing and validation of the device. This value is usually expressed in terms of specificity and sensibility. May vary from one task to another. For instance, the image quality has a different value than the classification of a condition.

With the information of sensitivity and specificity, each organisation may decide on a specific threshold, depending on their use case.

Adapting the threshold to the use case

Determining the appropriate threshold is fully dependent on the use case. For example, in deciding whether to refer to a specialist or a primary care practitioner:

• A lower threshold may lead to more cases being referred to a specialist, potentially catching more true positive cases but also increasing false positives.
• A higher threshold may reduce the number of false positives but can lead to missing true positive cases.

Therefore, the threshold must be chosen by the organisation with its specific use case in mind, balancing the outcomes of false positives and false negatives.

Threshold for malignantConditionProbability

malignantConditionProbability is one of the values output by the device for which an organisation may need to choose a threshold.

malignantConditionProbability represents a quantified suspicion level: the higher the value, the greater the suspicion of malignancy. Unlike a binary output, this continuous scale provides a more nuanced understanding but also necessitates a well-defined threshold to classify a case as malignant or not.

malignantConditionProbability is not a straightforward binary indicator but a cumulative measure derived from summing the probabilities of various classes deemed malignant by a multi-class classification algorithm. This approach is significant for several reasons:

1. Ambiguous nature of lesions: lesions can exhibit characteristics that span multiple classes. In such cases, a singular classification might be insufficient to capture the full scope of the lesion's nature.
2. Evolving conditions: Some lesions represent conditions in transition; for example, a benign lesion that is in the process of becoming malignant.

That is why capturing the probabilities across classes allows for a more dynamic understanding of the lesion's current state.

Practical example

Imagine 100 people ask for a consultation, but only 12 of them actually have a malignant condition. If we refer or prioritise cases where isMalignantSuspicion is higher or equal to 05101520253035404550556065707580859095100, then...

12 🙌 Are prioritised and should be prioritised True positives (TP)	88 😅 Are prioritised but should not be prioritised False positives (FP)
0 😣 Are not prioritised but should be prioritised False negatives (FN)	0 👏 Are not prioritised and should not be prioritised True negatives (TN)

Keep in mind that the number 12 in every 100 people does not give insight as to how many people actually will submit malignant images. What this gives you is knowledge of the accuracy of the algorithm, with a given ratio of malignant to non-malignant images.

Threshold for imageQuality.score

imageQuality is one of the values output by the device for which an organisation may need to choose a threshold.

imageQuality contains different aspects of the quality and validity of an image. Inside the technicalSummary key, there is an imageQuality object which contains the score.

Unlike a binary output, imageQuality.score provides a continuous scale with a more nuanced understanding of the image quality. However, it necessitates a well-defined threshold to classify a case as having enough quality or not.

Practical example

Imagine 100 images are sent to the device. Each image has a mediaValidity.score between 1 and 100. In order to separate good quality images from bad quality images, any image with a mediaValidity.score higher than 0%10%20%30%40%50%60%70%80%90%100% will be accepted.

In this case, due to the threshold of 0%10%20%30%40%50%60%70%80%90%100%, out of the 100 images, only 87 have enough image quality. As a result:

84 📸👌 Have enough quality and are proccessed True positives (TP)	6 😅📸 Have enough quality but are discarded False positives (FP)
3 😅📸 Don't have enough quality but are processed False negatives (FN)	8 📸👏 Don't have enough quality and are discarded True negatives (TN)

This can also be understood through an acceptance chart. In the following chart, you will see how many images are accepted depending on the threshold of the imageQuality.score. As examples, there are marks set at the thresholds for 40 and 80. In the second case, one can see that half of the images will be rejected.

40 → Acceptance: 99.16%

80 → Acceptance: 49.02%

Keep in mind that this does not give insight as to how many bad images will users actually send. What this gives you is knowledge of the accuracy of the image quality algorithm. It explains the confusion matrix of the DIQA algorithm, with a given ratio of good to bad images.

Where does this come from?

To determine and verify the accuracy of the algorithm, we have tested the algorithm with a dataset that has been labelled by experts at this task. That is how we derive the confusion matrix.

Further reading: Dermatology Image Quality Assessment (DIQA): Artificial intelligence to ensure the clinical utility of images for remote consultations and clinical trials. Journal of the American Academy of Dermatology.

Prioritisation

Organizations can create workflows to enhance the prioritization of patient care.

Each organization develops its own protocols for assigning priority to patients. The goal is to optimize referral processes, ensuring that patients receive timely and appropriate care from the right healthcare professionals.

For educational purposes, this section offers examples of potential workflows that a managing organization might employ. These are based on the diagnostic report information provided by our API, to effectively prioritize patient episodes.

Malignancy

One critical factor in healthcare decision-making is the evaluation of malignancy risk.

The API response includes a segment labeled riskMetrics, which can present information relevant to this assessment. This data can be instrumental in informing the prioritization process, as detailed below:

Risk metrics

{
  // ...
  "riskMetrics": {
    // ...
    "malignantConditionProbability": 62.0
    // ...
  }
  // ...
}

The parameter malignantConditionProbability may be used to help in the decision-making of assigning priority to patients.

Here's a straightforward rule to categorize patient priority based on this parameter:

• When malignantConditionProbability is from 0 to 30%, the patient can be categorized as normal priority.
• If malignantConditionProbability exceeds 30%, the patient should be considered high priority.

This decision-making process can be visualized using a flowchart:

Expanding upon this:

• Patients with malignantConditionProbability exceeding 30% are not only a high priority but may also be candidates for fast-tracking.

Another flowchart can help illustrate this extended decision-making criterion:

Order by malignancy

Organizations can refine their prioritization strategies by ordering cases according to the level of malignancy suspicion. For example, two patients who both fall into the High-priority category due to their malignancy levels — one at 60 and another at 30 — can be further triaged. This approach involves ranking patients within the High-priority group from highest to lowest based on their malignancy score.

This method enables more nuanced prioritization, ensuring that those with higher suspected risks are attended to more urgently.

If the managing organization opts to make this malignancy information visible to healthcare professionals (HCPs), the following type of chart could be implemented to facilitate this refined prioritization process:

malignancy: 6%	malignancy: 62%

Other workflows

Severity

The severity of a condition is one of the variables that HCPs use in their decision-making.

A response from the API contains a section called findings that may include the following information for each detected sign:

Findings

{
  // ...
  "findings": [
    {
      "signIdentifier": "erythema",
      "intensity": {
        "grade": 5.8,
        "gradingScale": "Legit.Health"
      }
      // ...
    }
  ]
}

As you can see, each sign (like erythema) includes an intensity object. In that example, we see that the sign intensity.grade is 5.8.

A very simple rule would be:

• If the intensity.grade is lower than 3, it would trigger workflow A
• If the intensity.grade is higher than 7, it would trigger workflow B

This can be useful, for example, when an HCP must decide whether or not to refer a patient to a specialist. It can also be useful information to monitor de effectiveness of a treatment.

In this example, workflow A would be the one applicable when the severity of the condition is under control, for instance, because it is correctly responding to the treatment,

Furthermore, you can enrich the process by adding information on the patient's history. For instance, if you compare with previous records, the result could be:

• If the intensity.grade is 5, and the previous record was 8, it would trigger workflow C (improving)
• Otherwise, it would fallback to workflow A

The managing organisation may also decide to show this information to the HCP, in which case a chart such as the following could be implemented:

The score for the severity can be displayed visually. The way of doing this is using the values returned in the intensity:

intensity.grade: 2	intensity.grade: 8

Prior existence of the condition

Whether a condition is new for a patient, or already diagnosed to that patient, is one of the variables that HCPs use in their decision-making.

A response from the API contains a section called hypotheses that may include the following information:

Hypothesis

{
  // ...
  "hypotheses": [
    {
      "identifier": "Eczematous dermatitis",
      "concepts": [
        {
          "name": "Generalised eczematous dermatitis of unspecified type",
          "code": "EA89",
          "terminologySystem": "icd-11"
        }
      ],
      "probability": 69.82
    }
    // ...
  ]
  // ...
}

What that information shows is that a condition has a probability of 69.82 (69.82%). The name of the condition is Generalised eczematous dermatitis of unspecified type, coded as EA89 according to the system ICD-11.

What an HCP could do is look up whether or not that condition has been previously diagnosed to the patient, and use that information in their decision-making.