FHIR Profiling
OMI uses the FHIR Standard for representation of Algorithms but also resulting artefacts. While relying on the HL7 FHIR Standard for OMI provides several benefits profiling ensures compliance to requirements.
Components of the OMI Registry and -Protocol
The following shows the components of the FHIR model that represents the Algorithm itself (Device Resource) and its instantiation as a service (HealthCareService Resource).
In addition to the schematic rendering shown above we want to provide an overview on which element represents which resource in the data model.
Object Modelled | FHIR Resource Type | Description |
---|---|---|
Algorithm | Device | Algorithms are a core component to the OMI protocol. They represent inference on clinical imaging- and structured data defined by in- and output parameter. Algorithms are defined as profiled Device resources. |
Service | HealthcareService | A service operationalizes an Algorithm to make it accessible via Endpoints for inference requests. Additionally it holds information about the service provider and maturity indicators. Within the OMI protocol a service is defined as HealthcareService resource. |
Endpoint | Endpoint | Defines where and how a inference service is available. It is defined by an Endpoint resource. |
In-/Output Parameter | Parameter | Input parameters defines data necessary for an algorithm to execute inference. Output parameters represent the inference result. In- and Output parameters can be images (DICOM/DICOMWEB) or (structured) clinical data. Structured data is defined in the FHIR format. |
Further Questions
Why do we need profiling?
Algorithms that are offered as services in the OMI registry need to comply to the standard defined in the OMI Implementation Guide. This ensures interoperability and enables algorithm driven selection of algorithms.
What is profiled?
Each service within the OMI Protocol needs a profile. Service instances need to comply and validate against this profile in order to be listed in the OMI Registry.