Workflows

This section contains examples of workflows that organisations may implement in their systems, related to the data output by our device.

We understand that it may be challenging to figure out how to use the data from the API, especially if this is the first device of this kind that your organisation implements. We hope that these examples may help you in this process.

Keep in mind that organisations may implement any workflow they wish and that this section does not constitute a best-practices list nor a recommendation. This is because every organisation is different. Furthermore, it is the responsibility of the managing organisation to design the workflows according to their best practices and recommendations from their physicians.

Prioritisation

Organisations may implement workflows regarding the prioritisation.

Each organisation will have their workflows and protocols to assign priority to patients, to increase the adequacy of referrals and assure that the right patient sees the right health care professional at the right time.

With merely illustrative purposes, the following section explains a few workflows that a managing organisation may implement to assign priority to episodes based on the diagnostic report information.

Malignancy

The malignancy suspicion is one of the variables that HCP use in their decision-making.

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

Preliminary findings

{
  // ...
  "preliminaryFindings": {
    // ...
    "isMalignantSuspicion": 62
    // ...
  }
  // ...
}

The parameter isMalignantSuspicion may be used to help in the decisionmaking of assigning priority to patients.

A very simple rule would be:

• From 0 to 5, the patient can be considered normal priority
• If the patient has a isMalignantSuspicion higher tan 5, it can be considered high priority.

graph LR A[Diagnostic report] -->B{isMalignant<br/>Suspicion} B -->|>5| E[High priority] B -->|<5| F[Normal priority]

And furthermore:

• If the patient has a isMalignantSuspicion higher tan 20, it can be considered high prioriy and it can be fast-tracked.

graph LR A[Diagnostic report] -->B{isMalignant<br/>Suspicion} B -->|>20| E[High priority and fast-track] B -->|>5| F[High priority] B -->|<5| G[Normal priority]

Order by malignancy

Organisations may go further and even order cases depending on their malignancy. For instance, a patient with a malignancy suspicion of 60 and a patient with a malignancy suspicion of 30 would both be High priority. However, even the high priority group can be triaged depending on the number, from higher to lower.

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:

isMalignantSuspicion: 6%	isMalignantSuspicion: 62%

Other workflows

Severity

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

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

Evolution

{
  // ...
  "evolution": {
    "domains": {
      "ASCORAD_LOCAL": {
        // ...
        "grade": {
          "score": 4.486,
          "ranges": [
            {
              "min": 0,
              "max": 0,
              "normalised": 0,
              "category": "None"
            },
            {
              "min": 1,
              "max": 20,
              "category": "Mild",
              "normalised": 1
            },
            {
              "min": 21,
              "max": 50,
              "category": "Moderate",
              "normalised": 2
            }
          ]
        }
      }
    }
  }
  // ...
}

As you can see, the grade object includes a score value. In that example, we see that the severity score is 4.486.

Then, in the array called ranges, you can see that the values between 1 and 20 fall under the severity 1 - meaning that it is the lowest severity possible. And the category for that severity is Mild, which is a semantic interpretation of the score that directly reflects the severity.

A very simple rule would be:

• If the category is severe, it would trigger workflow A
• If the category is mild, it would trigger workflow B

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

graph LR A[Diagnostic report] -->B{grade.category} B -->|mild| C[Workflow A] B -->|severe| D[Workflow B]

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,

And furthermore, you can enrich the process by adding information of the patient history. For instance, if you send to the API also information inside previousMedia when you post your request. The result could be:

• If the category is moderate, and the previous photo was not severe, it would trigger workflow C
• Otherwise, it would fallback to workflow A

graph LR A[Diagnostic report] -->B{grade.category} B -->|mild| C[Workflow A] B -->|severe| D[Workflow B] B -->|moderate| G{Previous<br/>grade.category} G -->|severe| C G -->|mild| E[Workflow C]

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 in the array ranges:

grade.category: mild	grade.category: severe

Prior existance of the condition

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

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

Conclusions

{
  // ...
  "conclusions": [
    {
      "code": {
        "code": "DA04.5",
        "codeSystem": "ICD-11"
      },
      "name": "Mucous cyst",
      "probability": 87.77
    }
    // ...
  ]
  // ...
}

What that information shows is that a condition has a probability of 87.77. The name of the condition is Mucous cyst, coded as DA04.5 according to the system ICD-11.

What a HCP could do is look up wether or not that condition has been previously diagnosed to the patient, and use that information in their decisionmaking.

graph LR A[Diagnostic report] --> B[conclusions] --> C{Is the condition<br/>already assigned<br/>to the patient?} C -->|yes| E[Trigger workflow A] C -->|no| F[Trigger workflow B]

Pre-malignancy

You may have seen that the API returns a value named isPreMalignantSuspicion, which is different to isMalignantSuspicion, as follows:

Preliminary findings

{
  // ...
  "preliminaryFindings": {
    // ...
    "isMalignantSuspicion": 0,
    "isPreMalignantSuspicion": 8.6000000000000001
    // ...
  }
  // ...
}

A premalignant condition (also known as a precancerous condition) is one that if left untreated may turn into cancer.

Out of the possible conditions output by the API, there are

• 10 malignant conditions
• 42 malignant conditions

This means that is more likely that a report may return a higher pre-malignancy suspicion.

Here is a sample table of conditions classified as malignant or pre-malignant, according to the relevant literature:

	Condition	Malignant	Pre-malignant
1	Acanthosis nigricans
2	Acne
3	Acne fulminans
4	Acrolentiginous melanoma
5	Actinic cheilitis
6	Actinic elastosis
7	Actinic keratosis
8	Actinic porokeratosis
+ +	+ + + + + + + + + + + + + +	+ + + + + +	+ + + + + + + +
234	Xeroderma pigmentosum
235	Xerosis

The complete table is 235 rows long. Feel free to reach out to your sales representative to request further information.

caution

Keep in mind that the conclusions key of the diagnostic report returns a full list of the conditions detected by the device. As such, an organisation may chose to assign malignancy of premalignancy differently to the value showed in isMalignantSuspicion and isPreMalignantSuspicion. The device provides those values for the convenience of the organisation and to add more transparency into the inner workings of the device.

The steps that a HCP may follow are:

graph LR A[Diagnostic report] -->B{isPreMalignant<br/>Suspicion} B -->|>60| E[Trigger workflow A] B -->|>30| F[Trigger workflow B] B -->|<15| G[Trigger workflow C]