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.
Please read the Installation Manual section of the Instructions For Use for more info.
DiagnosisSupport endpoint keys
SeverityMeasure endpoint keys
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.
Arranging the puzzle
The same output can support very different workflows. A safety-first triage flow might rely heavily on urgentReferral, 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 that operational goal.
Primary vs. secondary care
In this scenario, the organization splits cases into two outcomes:
| Primary care | 1 |
|---|---|
| Secondary care | 2 |
One possible workflow is:
This flow uses urgentReferral as the first escalation signal, entropy as the uncertainty gate, highpriorityReferral as the next referral filter, and severity scoring as the final discriminator when it is available.
To determine the thresholds, the organization must take into account two things:
- What are the possible outcomes of the workflow?
- What is the sensitivity and specificity of the parameter?
If the organization wants to reduce the risk of missing severe cases, it should favor conservative escalation thresholds for outputs such as urgentReferral and highpriorityReferral.
Remote vs. in-person consultation
An organization may also want to decide not only who should review a case, but how it should be reviewed.
| Remote | In-person | |
|---|---|---|
| Primary care | R1 | P1 |
| Secondary care | R2 | P2 |
Why this matters
This kind of workflow helps organizations increase the proportion of safe remote consultations while reserving in-person specialist capacity for cases that are both high risk and hard to classify.
Workflow example
This version keeps the same triage order and maps the more conservative branches to in-person specialist review, while lower-risk cases remain suitable for remote assessment.
Chronic patient follow-up
Organizations may want to monitor chronic patients remotely and surface cases that appear to be worsening or behaving unexpectedly.
In this case, the outputs can be simplified into:
| Progressing as expected | OK |
|---|---|
| Anomaly | ! |
For follow-up, a practical pattern is to first confirm that the condition is still present, and then determine whether severity suggests deterioration:
This workflow uses hasCondition as an explicit gate before interpreting severity or uncertainty.
Thresholding
As shown above, some puzzle pieces require choosing a threshold before they can trigger an action. That threshold should always be selected with the target workflow in mind.
How to decide a threshold
To determine an appropriate threshold, organizations typically rely on the confusion matrix of the relevant output.
A confusion matrix compares the predicted class against the actual class and helps quantify how many cases fall into each of these categories:
- True positives
- True negatives
- False positives
- False negatives
In practical terms, a threshold defines the point at which a score is considered high enough to trigger a decision.
- A lower threshold captures more positive cases, but may increase false positives.
- A higher threshold reduces false positives, but may increase false negatives.
The best threshold is therefore not a purely technical choice. It reflects what type of error the organization is more willing to absorb in a given workflow.
Adapting the threshold to the use case
The right threshold depends on the operational consequence of being wrong.
- For
urgentReferral, many organizations will prefer a lower escalation threshold because missing a truly urgent case has a high cost. - For
entropy, a higher threshold may be appropriate if in-person review is scarce and only highly uncertain cases should be escalated. - For
hasCondition, the threshold may vary depending on whether the workflow is screening for persistence, relapse, or treatment response.
Threshold for urgentReferral
urgentReferral is especially useful when the organization needs an early safety gate in the workflow.
- A lower threshold sends more cases to specialist review and reduces the chance of missing urgent presentations.
- A higher threshold protects specialist capacity, but increases the risk that some urgent cases remain in a lower-priority path.
For triage workflows where urgent review is the main concern, urgentReferral is a natural first decision point.
Threshold for entropy
entropy measures how concentrated or dispersed the model probability distribution is.
- Lower entropy means the model is relatively focused on fewer diagnostic options.
- Higher entropy means the model distributes probability across more competing options.
This makes entropy useful as an uncertainty gate. In a conservative workflow, high-entropy cases can be escalated for in-person or specialist review even if referral-oriented outputs remain below threshold.
Threshold for highpriorityReferral
highpriorityReferral is useful for distinguishing routine cases from cases that may not require immediate escalation but still deserve prioritized specialist handling.
- A lower threshold increases sensitivity for higher-priority conditions.
- A higher threshold narrows the specialist queue to more concentrated cases.
This is often a good second-stage filter after urgentReferral, because it helps separate urgent review from accelerated but non-immediate review.
Other workflows
The same pieces can also support other designs:
Prioritization
urgentReferral, highpriorityReferral, and entropy can be combined to sort waiting lists into urgent, accelerated, and routine review queues.
Pigmented lesion routing
pigmentedLesion can be used to split cases into a pigmented-lesion pathway versus a more general inflammatory or non-pigmented workflow.
Severity
scoreCategorySeverity can be used on its own when the objective is to distinguish low-impact cases from moderate or severe presentations.
Prior existence of the condition
hasCondition can support workflows focused on persistence, relapse, or treatment response.
Uncertainty review
entropy can be used as a dedicated operational signal to request additional images, force manual review, or avoid automated downstream actions when model certainty is low.