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).

omi-resource-overview

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.