33 documents tagués avec "Integration"

What is the Server API?

The anamnesisGeneral field captures the structured patient history collected before the image is submitted for analysis, modelled as a FHIR QuestionnaireResponse.

The anamnesisGeneral field captures the structured patient history collected before the image is submitted for analysis. It rides at the top level of the data payload alongside bodySite and pathology.

Post an anonymous diagnostic report

This page explains how the iframe authenticates and how to load it securely in production. Three credentials are involved. Keep them straight and everything else follows.

The condition block describes the suspected or most likely pathology together with the body site where the lesion was photographed. Both fields use FHIR coding[] arrays so the same condition or location can be expressed in the proprietary catalog and in ICD-11 simultaneously.

These fields describe where the lesion is located (bodySite) and what condition the device suspects (pathology). They appear at the top level of the data payload and are the primary keys you use to route a report to downstream workflows.

No, currently we only admit creating EpisodeOfCare with an assigned condition. This eases the tracking of the condition inside the application.

No, we do not accept images in .HEIC format. We accept .JPG and .PNG.

The result.conclusions array represents the list of possible conditions identified, each with a probability and standardized coding. Every entry follows the same coding[] shape as condition.pathology: a proprietary entry plus an ICD-11 mapping.

The conclusions field lives under result and lists the ranked diagnostic hypotheses the device considered for the case. Each entry pairs a pathology type with its associated probability, and the array is sorted by probability descending, so the most likely outcome is always at index 0. Probabilities are percentages from 0 to 100.

Get a diagnostic report

Once the iframe finishes processing an upload and emits the analysis_completed callback with the report identifier, your backend retrieves the diagnostic report on demand from the API. To obtain it as a FHIR-compliant payload, call the endpoint with the ?format=fhir parameter; see the API Endpoint page.

Here, you will find some of the most common questions asked by our clients. If you have any other questions, please feel free to contact us.

The most important feature of the API integration is receiving a DiagnosticReport with the information created by the Artificial Intelligence.

Besides getting the DiagnosticReports linked to patients between your system and our, you can also fetch the AnonymousDiagnosticReports that you had sent, ie, those which are not linked to any patient.

If you are receiving the following message when consuming our API,

Interpreting the results requires careful consideration of the image quality and the context in which it was taken. By following the recommended guidelines, you can ensure more accurate and reliable results.

Il est possible d'intégrer Legit.Health directement par l'API du dispositif médical, sans l'application ; le travail que réalise l'application incombe alors à l'intégrateur.

In order to begin the Server API integration, the first step is to provide information about the organisation that will manage the account.

Comment intégrer Legit.Health à vos systèmes d'information de santé. Legit.Health s'intègre sous forme d'application (une iframe) dans votre système, avec sa propre API pour les rapports.

Two fields in the FHIR payload carry imagery for the case: macroscopicMedia at the top level of data (the lesion photo submitted for analysis, as a FHIR Media resource), and result.observations (the array of every media that was actually sent to the algorithm for analysis).

Two fields in the payload carry imagery for the case: macroscopicMedia at the top level of data (the lesion photo submitted for analysis, plus any detection annotations drawn over it), and result.observations (the array of every media that was actually sent to the algorithm for analysis).

The result field captures the diagnostic process output. Three sibling fields describe the classifier's behaviour for this case: performanceIndicators, clinicalIndicators, and analysisDuration.

The result field encapsulates the comprehensive results of the diagnostic process. Three subfields describe the classifier's behaviour for this case: metrics, preliminaryFindings, and iaSeconds.

Connect a patient

Connect a practitioner

The result.questionnaires array carries the scoring systems applied to the imagery, each modelled as a FHIR QuestionnaireResponse. Every entry records the scoring methodology, the computed score and severity band, the facet answers that fed into it, and an optional explainability media overlay.

The scoringSystems field lives under result and houses one or more scoring models for the identified pathology. These models come into play when the likelihood of the most probable conclusion surpasses a certain threshold, and they are used to estimate the severity of that condition.

Once the iframe finishes processing an upload and emits the analysis_completed callback with the report identifier, your backend retrieves the diagnostic report on demand from the API. See the API Endpoint page for the request format.

In the scope of the domain of programming the integration of the device, the term condition is a pathology, as define in FHIR, in a body site of a patient.

Only the image of the skin lesion is required for the API to return a value.

The Swagger contains the full list of codes for selecting a body site or a pathology in the description of the corresponding properties.