General information

This page will go more into details regarding the purpose, current state, use cases etc. of the FHIR Observation to PHMR service.

Purpose

This service was originally build as part of a "Proof of Concept" for a medical microservice architecture. At that time it was build to a "4S maturity level" of "Prototyping", meaning that only a subset of Observation resource attributes were converted and some content of the PHMR were hardcoded.

As part of a new project entitled "KomTel" (Components for Telehealth or Komponenter til Telesundhed in danish) it has been upgraded to make use of newer versions of a series of libraries as well as having a more generic structure and avoiding the use of hardcoded content.

The microservice is a converter service, that converts incoming FHIR Observation resources into HL7 PHMR format documents following version 1.3 of the danish profile of PHMR (http://svn.medcom.dk/svn/releases/Standarder/HL7/PHMR/Dokumentation/PHMR-DK-Profile-v1.3.pdf).

The service subscribes to Kafka on a topic in order to receive FHIR Observations, and it writes the converted PHMR documents to another Kafka topic.

Maturity level

This service has a maturity level of "Mature prototype" in relation to 4S maturity level

Current state

At the time of writing, the service is able to listen to a predetermined Kafka topic for FHIR observations, convert the FHIR observation to PHMR that adheres to the danish profile and output this PHMR-document as an XML-string to a different predetermined Kafka topic.

As this project did not include building services for handling organizations or practitioners, all data regarding organizations and practitioners in the PHMR-document is mock data i.e. data regarding the author, custodian and the legal authenticator. The service is however able to use data from config-files to inject static data into the PHMR-document. Example config-files with mockdata can be found in the resources folder of the src-directory.

References to patients, observations and device-components are resolved using http-requests from the service, as long as the references contain full (and unsecured) URL's to the resources. Though it is possible in PHMR to have both nested resources and device components, this service is only able to resolve two levels of nesting for each of these types of resources.

Within the architecture of the project this service is updated for, a consolidator/validator service will process data before it is handed of to this service. Therefore this service does not object if vital information is missing from the FHIR observation, but will insert a null-value in place of the vital information in the PHMR-document.

As UCUM-units are required for all observations in PHMR, but not in FHIR, this service can lookup some of the units based on the MDC-code. This functionality is, however, far from comprehensive.

Finally there are a series of "TODO"'s in the code. These are mostly questions regarding certain elements in the PHMR, that still need work.

Use cases

Prerequisites

A running microservice architecture running with Kafka messaging

Flow

1. A FHIR Observation is pushed from a Microservice to the Kafka queue on a topic
2. This service consumes the observation and processes it
3. This service produces a PHMR-document created from the observation on a different topic

Decisions and reasoning

This section will describe some of the decisions made regarding this service, and why they were made

Decision: If a patient doesn't have a CPR-number - all fields for that patient will be left empty.

Reasoning: In order to avoid duplicate information about a patient, a patient is required to have a CPR-number

Decision: Both organizations and practitioners in the PHMR are created using mockdata.

Reasoning: No organization- or practitioner servers are part of this project. Therefore there is no way to resolve the references from the FHIR-resources.

Decision: All observations are required to have an MDC-code.

Reasoning: The PHMR-document requires that all observations have either an MDC- or a SNOMED CT-code. As there are no simple way to translate from NPU or another danish system to MDC- or SNOMED CT-codes. These are required on the FHIR resource.

Decision: All FHIR resources are expected to be Continua compliant.

Reasoning: In order to make a Continua compliant system. We require the input to the system to be Continua compliant as well.

Decision: PHMR documents requires the unit of each observation/measurement to be in UCUM-units. The converter can lookup some of the units based on the MDC-code, but it is far from comprehensive.

Reasoning: There is no simple way to lookup units based on the MDC-code, therefore the converter will no the most commonly used UCUM-units as well as all the units used in the CTG- and weight-measurement used for testing.

License

The FHIR Observation To PHMR Service source code is licensed under the Apache 2.0 license.