Version 2 - FHIR Mapping Scenarios

The testing scenarios below are in preparation for FHIR CAT #9 in Paris.

Mapping HL7 version 2 to FHIR

One of the main use-cases for mapping will be to populate a FHIR Resource Repository using data derived from a HL7 version 2 message feeds. The FHIR Specification details some of the differences between HL7v2 and FHIR. This test track will focus on the most commonly used HL7v2 trigger events, i.e. ADT and ORU.

The wording below distinguishes between three kinds of actors:

• FHIR Client: a software application that has the capability to create/assemble FHIR based requests.
• FHIR Server: a software application with the capability to receive and process FHIR based requests. The server need not have a stiorage capability for FHIR resources.
  • A Messaging Enabled FHIR Server is a kind of FHIR server which supports the messaging interoperability paradigm.
• Transformation Agent: the software component that transforms HL7v2 to FHIR and/or vice versa. The role of Transformation Agent will be combined with that of a FHIR client and/or a FHIR Server.

ADT Query

Demographics and visit query according to IHE ITI specs (IHE ITI Volume 2a, section 3.22 "Patient Demographics and Visit Query").

1. Test for Transformation Agent / FHIR Client:
   • Determine (e.g. by querying the FHIR server) the ID of a patient which has an active encounter on a particular FHIR server. Edit the HL7v2.5 query example to include that identifier.
   • Process/read a HL7v2.5 QBP^ZV1 query, send corresponding query to FHIR server, transform response to HL7 v2.5 RSP^ZV2.
   • Determine the ID of a patient which doesn't have an active encounter; edit the HL7v2.5 query example to include that identifier and retest the transformation/request process.
   • Determine the ID of a patient which doesn't exist; edit the HL7v2.5 query example to include that identifier and retest the transformation/request process.
2. Notes:
3. Example/test messages:

xx to do xxxxxxxx

ADT

Hl7v2.5 ADT messages: process a sequence comprised of A31, A01, A02, A08, A03 trigger events. The sequence A31-A01-A02 will contain 2 allergies, A08 drops one allergy (A08 and A03 only contain 2 allergies).

1. Test for Transformation Agent / FHIR Client:
   • (easy option, assumes that the FHIR Server supports Messaging) - process/read this sequence of HL7v2.5 messages, transform each of them to a FHIR Message, send FHIR messages to FHIR Server.
   • (difficult option, assumes that the FHIR server only supports REST) - process/read this sequence of HL7v2.5 messages, transform each of them into a series of FHIR resources, query/update/delete resources on the FHIR Server.
     • The Transformation agent will have to detect that one allergy has been dropped from the message -compared to the previous message about the same patient and encounter-, and that an allergy has to be deleted.
     • A provenance resource SHOULD be created to document the fact that certain resources were sourced from a single message
2. Test for FHIR server:
   • If the FHIR Server supports Messaging it should be able to detect 'information which has been removed from a snapshot'
     • Tt will have to detect that one allergy has been dropped from the message -compared to the previous message about the same patient and encounter-, and that an allergy has to be deleted
3. Notes:
   • You SHOULD populate the text option in the generated resources
   • See David hay's blog for his reflections on this kind of mapping.
4. Example/test messages:

xxx to do xxxxxxxxxx

Lab Results

HL7v2.5 Lab results: a sequence comprised of ORU temporary result, and ORU final result. Chem tests.

• This requires updating of existing resources, which is a challenge in that there are no unique resource.ids in HL7 v2.

1. Notes:
   • The following policy applies: given that the Lab system isn't the 'master' when it comes to data OTHER than the actual results (ORC/OBR/OBX/SPM/SAC/..) all other data should be considered to be references (to e.g. patient/encounter) only. The Transformation Agent should (somehow) inform the server that certain resources should NOT be updated. See also [1] (blogpost)
   • You SHOULD populate the text option in the generated resources