CDA2FHIR 2024

Short Description

The main purpose of this track is to test the conversion of the Austrian HL7 CDA Laboratory Report (Version 2.06.3 and Version 3.0) to FHIR by leveraging the CDA Logical Model and the current status of the CDA2FHIR maps. Furthermore, this track may be used to get an insight of the FHIR Mapping Language.

Long Description

Mapping Specification

The architecture of the Austrian EHR system (ELGA) is mainly based on HL7 CDA leveraging the IHE XDS framework. Recent national and international projects (e.g. myHealth@EU) are evaluating the use of HL7 FHIR as parallel or even as replacing architecture. As the existing CDA documents would have to be accessible in an HL7 FHIR environment as well a mapping to HL7 FHIR is required.

For this purpose, the international CDA Logical Model has been enhanced by the elements required by the Austrian CDA XML Schema. Furthermore, HL7 FHIR maps have been created in order to be used for mapping from HL7 CDA to HL7 FHIR.

Currently, the HL7 FHIR maps target the HL7 Europe Laboratory Report and as of now, the maps are able to create a FHIR Bundle which contains the header information (participants) as well as the clinical data (observations). The generated Observation resources already conform to the HL7 Europe Laboratory Report. The rest of the Bundle is still work in progress and shall soon be aligned with the IG specification.

Mapping Execution

Along with the specification of the mapping this track is also focusing on the execution of the mapping. For this reason the following tools may be tested and the results compared:

Expectations

Throughout the course of this track we expect and hope to achieve:

  • increased understandability of maps (StructureMap)
  • increased understandability of the differences between HL7 CDA and HL7 FHIR
  • feedback regarding the current status of the maps
  • feedback regarding the tools used for the execution of maps

Type

Test the design of a Resource/set of Resources

Submitting Work Group/
Project/
Accelerator/
Affiliate/
Implementer Group  

TC FHIR - AG ELGA CDA Laborbefund zu FHIR

Track Lead(s)

Track Lead Email(s)

tc-fhir@hl7.at

Related Tracks

FHIR Version

FHIR R4

Specification(s) this track uses

https://github.com/HL7Austria/CDA-core-2.0/tree/cda-ext-elga (Austrian CDA Logical Model)

https://github.com/HL7Austria/CDA2FHIR/tree/hl7eu (Austrian CDA2FHIR maps which have the HL7 Europe Laboratory Report as target)

https://hl7.org/fhir/R4/structuremap.html (StructureMap)

https://build.fhir.org/mapping-language.html (Mapping Language)

Artifacts of focus

-

Expected participants


Date / Time

Monday March 11, 09:00am-03:30pm CET

Test Servers

See Test Servers

Track Details

Prerequisites (recommended)



System roles
FHIR Transformation Server (Matchbox)

For service providers, implement the following operations:

Support additional capabilities:

CDA2FHIR Transformer

Implement any one or more of:

  • Set up the transformation framework locally
  • Transform a HL7 CDA Laboratory Report (Version 3) to HL7 FHIR
  • Inspect/Edit the mapping
  • Validate the created resources
Discussion
Scenarios
1 - Transformation of HL7 CDA Laboratory Report

Using the examples of HL7 CDA Laboratory Reports in GitLab test the transformation to HL7 FHIR.

2 - Execution of simple mapping example

Use the following example together with https://hl7.org/fhir/R4/practitioner-example.xml.html in order to create a Patient resource.

Sample Mapping
map "http://hl7.at/fhir/HL7ATCoreProfiles/4.0.1/StructureMap/simple-sample" = "PractitionerToPatient"

uses "http://hl7.org/fhir/StructureDefinition/Practitioner" alias Practitioner as source
uses "http://hl7.org/fhir/StructureDefinition/Patient" alias Patient as target

group PractitionerToPatient(source practitioner: Practitioner, target patient: Patient) {
  practitioner.identifier as identifier -> patient.identifier = identifier;

  practitioner.name as name -> patient.name = name;

  practitioner.telecom as telecom -> patient.telecom = telecom;

  practitioner.birthDate as birthDate -> patient.birthDate = birthDate;
}

REST-Requests

REST-Request
### 1. POST SimpleSample.map
POST {{host}}/StructureMap HTTP/1.1
Accept: application/fhir+xml;fhirVersion=4.0.1
Content-Type: text/fhir-mapping

< ./maps/SimpleSample.map

### 2 POST practitioner.xml
POST {{host}}/StructureMap/$transform?source=http://hl7.at/fhir/HL7ATCoreProfiles/4.0.1/StructureMap/simple-sample
Accept: application/fhir+xml;fhirVersion=4.0.1
Content-Type: application/fhir+xml;fhirVersion=4.0.1

< ./input/practitioner.xml
  • Try to inspect/edit/execute the mapping
    • Add a "birthDate" to the Practitioner resource
    • Map the address of the Practitioner
    • ...
3 -  Validate the created resources

Use the FHIR Validator for validating the created resources.

4 - Load created resources to FHIR servers
  • Use the provided 3. Hackathon: Test Servers to load the created FHIR resources to the FHIR servers and inspect their behaviour.
    • What happens with the created Bundle?
    • Is it possible to access the single resources?
    • Is there an operation to split up a Bundle?
    • How to recreate a Bundle based on a Composition resource?