General information

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

Purpose

This service was build as part of a project entitled "KomTel" (Components for Telehealth or Komponenter til Telesundhed in danish).

The microservice is a converter service, that converts incoming FHIR Questionnaire Response resources into HL7 QRD format documents following version 1.2 of the danish profile of QRD (http://svn.medcom.dk/svn/releases/Standarder/HL7/PRO/QRD/Dokumentation/DK-QRD-v1.2.pdf).

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

Maturity level

This service has a maturity level of "Proof of Concept" 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 questionnaire responses, convert the FHIR questionnaire response to QRD that adheres to the danish profile and output this QRD-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 QRD-document is mock data i.e. data regarding information recipient and custodian. The service is however able to use data from config-files to inject static data into the QRD-document. Example config-files with mockdata can be found in the resources folder of the src-directory.

References to other FHIR resources are resolved using http-requests from the service, as long as the references contain full (and unsecured) URL's to the 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 questionnaire response, but will insert a null-value in place of the vital information in the QRD-document.

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

Use cases

Prerequisites

A running microservice architecture running with Kafka messaging

Flow

1. A FHIR Questionnaire Response is pushed from a Microservice to the Kafka queue on a topic
2. This service consumes the questionnaire response and processes it
3. This service produces a QRD-document created from the questionnaire response 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: All AddressUse is sorted into either Home or Work, Home being the default.

Reasoning: FHIR has a series of enum's describing AddressUse. The CDA-builder only allows for either Home or Work.

Decision: Group-elements are ignored by the converter-service

Reasoning: CDA only supports a single level of questions. Therefore FHIR elements of the "group"-type does not have an equivalent type in CDA.

Decision: Display-elements are ignored by the converter-service

Reasoning: CDA does not support text-elements with no associated questions. Therefore FHIR elements of the "display"-type does not have an equivalent type in CDA.

License

The FHIR Questionnaire Response To QRD Service source code is licensed under the Apache 2.0 license.