The history of medical information systems has seen many twists and turns, and while there has long been a global standardization body in the form of HL7, it only recently gained a lot of traction with the FHIR standard. As a result, a number of countries have developed their own medical data interchange formats over the years, which now need to be realigned with the global FHIR medical data interchange format. One such example is the Belgian KMEHR format. For this TTC case, we will focus on a specific kind of medical data interchange, namely the Patient Summarized Medical Record. In KMEHR, this is called the Summarized Electronic Health Record (SumEHR). In FHIR, this is called the International Patient Summary (IPS). The primary purpose of such a record is to provide an emergency “cheat sheet” to healthcare providers who don't normally see the patient in question, e.g. a hospital's emergency department. Especially when a patient is abroad, the capability to exchange such data is important, as it will often be the only source of medical background data. This TTC case will require you to translate between the Belgian SumEHR format and the international FHIR IPS format.
CEUR ceur-ws.org
This Transformation Tool Contest case concerns the transformation between two medical data interchange formats: the Belgian “Kindly Marked-up Electonic Healthcare Record” (KMEHR) standard [1], and the international “Fast Healthcare Interoperability Resources” (FHIR) standard by Health Level 7 (HL7) [2].
of medical data interchange, namely the Patient Summarized Medical Record. In KMEHR, this is called the Summarized Electronic Health Record (SumEHR) [3]. In FHIR, this is called the International Patient Summary (IPS) [4]. The primary purpose of a Patient Summarized Medical Record is to provide an emergency reference sheet to healthcare providers who don’t normally see the patient in question, e.g. a hospital’s emergency department, or a diferent doctor than your regular doctor. Especially when a patient is abroad, the capability to exchange such data is important, as it will often be the only source of medical background data.
Please follow the link in the footnote and create a pull request with your own solution. tion 2 describes the structure of the KMEHR to FHIR case. Section 3 describes the proposed tasks for this case. Section 4 mentions the benchmark framework for those tion 5 mentions an outline of the initial audience-based nologies: Applications and Foundations (STAF) federated conferences, evaluation across all solutions, and the approach that will be followed to derive additional prizes depending on the attributes targeted by the solutions.
for bridging the gap between two medical data standards, KMEHR and FHIR, that use vastly diferent document structures and medical code systems. The metamodels for KMEHR and FHIR have been automatically generated from their published XML schemas2 using the EMF XSD generator3. The resulting metamodels are too large to include in this paper, but they can be viewed online at the “kmehr-emf”4 and “fhir-xml-emf” 5 Github projects. The metamodels consist of 297 and 1110 metaclasses, respectively. Please note that the original XSD files are also included in these GitHub repositories.
many concepts, but also due to accidental complexity that body, and to a lesser extent by EMF’s representation in Ecore of XML schemas. It is necessary for an industrial space [5] that is used, and not require the end user to manually translate from the provided technical format to the modeling technology of choice. Having to bridge standards, which often don’t target modeling technology.
It is also apparent that the level of accidental complexity is proportial to the size of the standardization body, as solutions that focus on raw performance. Finally, Sec- technical spaces is common for industrial data format CEUR Workshop Proce dings htp:/ceur-ws.org ISN1613-073
Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop Proceedings (CEUR-WS.org) https://github.com/dwagelaar/ttc2023-kmehr2fhir provides an XML representation. 3https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.emf. doc%2Ftutorials%2Fxlibmod%2Fxlibmod.html
can be seen in the size diference between the KMEHR 4.8.0 release of ATL, which allows for eficient execution and FHIR metamodels. FHIR simply has a much larger of matched rules with many input element. For example, scope, and must be general enough to apply worldwide. the Posology rule shown in Listing 1 uses four input It therefore also covers many more corner cases than elements, which would require iterating four times KMEHR. through the entire input model before ATL 4.8.0. As
Figure 1 shows a small part of the FHIR metamodel of ATL 4.8.0, the filter expressions on lines 7–9 are that shows how primitive types, such as strings, inte- translated by the compiler into local search expressions gers, and booleans, are wrapped inside a container object. for the tx, i, and s input elements. Only the f input The KMEHR metamodel does not do this, and an addi- element needs to be found by iterating over the entire tional translation step is necessary to bridge this – purely input model. An additional mapsTo keyword is required technical – gap. In this case, the Composition metaclass, to indicate that the output element t does not map to which represents the body of the medical record sum- the entire collection of input elements, as is the default, mary, typically has a custodian. The custodian is the but rather directly maps to the input element s. That medical party that is responsible for keeping the medical way, whenever another transformed model element record summary up to date, and is typically your general is assigned a reference to KMEHR!PosologyType s, practitioner in Belgium. The custodian property is repre- ATL’s implicit tracing mechanism will translate it to sented as a reference string in FHIR, which resolves to the FHIR!MedicationStatement t. type and identifier of a Resource (document attachment) The Posology rule is responsible for translating the inside the same FHIR Bundle (document). statement of how and when medication must be administered – e.g. ”once daily, after dinner” – from a id : Id Composition [0..1] encounter javSat.rliannggP.rSimtriintigve aKsMwEeHllRa!sPdousorilonggywTyhpicehttoima eFHpeIRri!oMdeidtiicsaatipopnlSictaabtelem(ethnet, immeptlaic:itMReutlaes : Uri [0..1] display effectivePeriod). Another transformation rule Posololtcaeonxngttu:aNiangaeerdr:a:CtRiovedeseourceContainer [0..*] subject [0..1] reference rguylWebityhUadnditiAngndaTuankietsaenxdisdtso,swaghei,ceh.ge.xt”e1ncdasptsh.”e. PTohsisolrouglye emxotednifiseiornEx:tEexntseinosnio:nExtension Reference String is shown in Listing 2. iudreln:Utifirier : Identifier teyxpteen:sUiorin : Extension veaxltueen:sSiotnrin:gEPxtreimnsitiiovne Note how ATL modularizes the accidental complexity tsytapteu:sC:oCdoemabploesCitoionnceSptattus identifier : Identifier of wrapped primitive types in FHIR by delegating the category : CodeableConcept creation of the wrapper objects to lazy rules, such as the dauntsoatetteeeCsot::eDAnrtnae:ntCxeotoTt:maiUmtipsoeoangsietCioonnAttetxetster [0..1] cus[1to..d*]iaanuthor cFahnirSntorwingsirmuplelyshworwapn tihneLmisteidnigca3t.ioTnhreefPeorseonlcoegystrriunlge reevleantets:TCoom:RpeolastiteidoAnErtvifeanctt [0..1] version inside a FHIR String by invoking the lazy rule. Note section : CompositionSection that the remaining medication reference wrapper objects, [0..1] name CodeableReference and Reference, could also have been [1..1] title modularized in a lazy rule, further increasing the clarity of the Posology rule. This has not been done here, beFigure 1: Extract of the FHIR metamodel cause those wrapper objects are only used once in the entire transformation code. Instead, only the wrapper objects that must be created several times are extracted
A transformation tool’s ability to deal with this acci- into lazy rules. dental complexity is an important factor for industrial The transformation translates a SumEHR document, acceptance. Not only should the transformation tool be which is efectively a KMEHR document with a header able to process the accidental complexity, but it should and a folder that contains administrative patient data and also allow the user to hide away or otherwise modular- a “sumehr” type transaction. The sumehr transaction ize the part of the transformation code/specification that contains a number of items of the following types: deals with this accidental complexity.
The reference transformation is written in ATL/EMFTVM [6] and comprises approximately 1300 lines of code, divided over the main KMEHRtoFHIR.atl transformation module and the libKMEHRtoFHIR.atl helper library. Both of these files can be found in the aforementioned case Github repository. It uses advanced features of the EMFTVM runtime, such as multiple rule inheritance and invocation of native Java code. It also relies on the local search compiler included with the • gmdmanager: the doctor that is responsible for keeping the patient’s main medical record up-todate. It is translated to a custodian Practitioner element in FHIR. • contactperson: a key contact person of the patient, such as a family member or employer. It is translated to a list of contact CodeableConcepts in FHIR, embedded within the Patient element.
• socialrisk: a health-related risk originating from
Listing 1: Posology rule rule Posology { from f : KMEHR!FolderType, tx : KMEHR!TransactionType, i : KMEHR!ItemType, s : KMEHR!PosologyType ( i.posology = s and tx.item->includes(i) and f.transaction->includes(tx) and i.isMedication) to } the patient’s social context. It is not included in a FHIR IPS document. • risk: a health-related general risk for the patient.
It is not included in a FHIR IPS document. • problem: an ongoing condition the patient suffers from, or – if inactive – a historic condition.
Listing 2: Posology rule
It is translated to a Condition element in FHIR. • medication: currently prescribed medication for the patient. It is translated to a Medication element in FHIR, with the embedded KMEHR Posology being translated to a MedicationStatement element in FHIR. • vaccine: a vaccine/immunization the patient has received in the past. It is translated to an Immunization element in FHIR. • adr: an adverse drug reaction that the patient suffers from. It is translated to an AllergyIntolerance element of type ”intolerance” in FHIR. • allergy: an allergy the patient sufers from. It is translated to an AllergyIntolerance element of type ”allergy” in FHIR.
Listing 3: Posology rule lazy rule FhirString { from
s : String
If focusing on performance, the solution authors should integrate their solution with the provided benchmark framework. It is based on that of the TTC 2017 Smart Grid case [7], and supports the automated build and execution of solutions. For this specific case study, the visualisation of the results is currently disabled.
The benchmark consists of three phases:
SumEHR and FHIR IPS, but for the purpose of the TTC case, the types are limited to the ones listed.
In addition, the reference model transformation does not (fully) translate between the medical coding systems used in KMEHR and FHIR for the sake of simplicity, and simply embeds the KMEHR medical codes within the 4.1. Solution requirements FHIR document. Submissions to this case should follow Solutions should be forks of the main Github project9, the same strategy. and should be submitted as pull requests.
That said, a full translation would have to map addi- Each solution wishing to use the benchmarking frametniootnaabllymuendiitcsaolfcomdeiansgursey6staenmdsvianccoinrdeeirntdoicbaetiocnomcopdleetse7,. work should print to the standard output a line with the following fields, separated by semicolons (“;”): Finally, a translation of the Belgian CNK codes for medication to the international ATC standard would be very useful, but that would require incorporating a database in the transformation, such as SAM8.
basic infrastructure (e.g. loading metamodels).
These measurements are optional. 2. Load, which loads the input models. 3. Run, which runs the consistency checking, finding a number of consistency violations in the mutated DocBook model.
There is a mandatory task and an optional task in this case: • The mandatory task is to re-implement or improve the original transformation itself, in a way that lends itself better to after-the-fact consistency checking. Your transformation tool may have better support for this, or ATL could be made to deal better with larger versions of this model. • The optional task is to define the reverse transformation that translates the generated FHIR IPS document back to SumEHR.
7https://www.ehealth.fgov.be/standards/fhir/vaccination/ ValueSet-be-vs-vaccine-code.html 8https://www.samportal.be/
framework, solutions should add a subdirectory to the solutions folder of the benchmark with a solution.ini file stating how the solution should be
Solutions can focus on eficiency, conciseness, or clar- built and how it should be run. As an example, the ity of presentation to the user. Clarity of presentation is solution.ini file for the reference solution is shown key for this kind of transformation, as domain experts on Listing 4. In the build section, the default option must typically validate the correctness of the transforma- specifies the command to build and test the solution, and tion logic by reviewing the code. the skipTests option specifies the command to build the solution while skipping unit tests. In the run section, the cmd option specifies the command to run the solution.
The repetition of executions as defined in the benchmark configuration is done by the benchmark. For 3 9https://github.com/dwagelaar/ttc2023-kmehr2fhir • Tool: name of the tool. • Source: base name of the input KMEHR model
(e.g. “sumehr_example10.kmehr”). • Target: base name of the output FHIR model (e.g.
“output.fhir”). • RunIndex: index of the run of this combination
of tools and inputs. • PhaseName: name of the phase being run. It
may be Initialization, Load, or Run. • MetricName: the name of the metric. It may be the Memory used (b) in bytes, the wall clock Runtime (ns) spent in integer nanoseconds, or the number of Bundle Entries found in the output FHIR model.
[build] default=mvn package skipTests=mvn package --skipTests=true
This paper used the TTC 2019 Live Case paper by Antonio García-Domínguez and Georg Hinkel [8] as a template. [run] cmd=JAVA_OPTS="-Xms4g" \ java -cp target/reference-0.0.1-SNAPSHOT.jar:
target/dependency/* \ ttc2023.kmehr2fhir.reference.Driver $SourcePath $TargetPath [1] KMEHR standard (v1.38), eHealth-platform, 2023.
Online: https://www.ehealth.fgov.be/standards/ kmehr/en. [2] FHIR Specification (v5.0.0: R5), HL7 Community,
2023. Online: https://hl7.org/fhir/R5/. [3] Summarised Electronic Healthcare Record v2.0, eHealth-platform, 2016. Online: https://www. ehealth.fgov.be/standards/kmehr/en/transactions/ runs, the specified command will be called 3 times, pass- summarised-electronic-healthcare-record-v20. ing any required information (e.g. run index, or input [4] International Patient Summary Implementation model name) through environment variables. Solutions Guide (v1.1.0), HL7 Community, 2022. Online: https: must not save intermediate data between diferent runs: //hl7.org/fhir/uv/ips/STU1.1/. each run should be entirely independent. [5] J. Bézivin, Model driven engineering: An emerging
The name and absolute path of the input model, the technical space, in: R. Lämmel, J. Saraiva, J. Visser run index and the name of the tool are passed using (Eds.), Proceedings of GTTSE 2005, Revised Papers, environment variables Tool, SourcePath, TargetPath, volume 4143 of LNCS, Springer-Verlag, 2005, pp. and RunIndex. Solution authors are suggested to study 36–64. doi:10.1007/11877028_2. the reference solution on how to use these values to run [6] D. Wagelaar, M. Tisi, J. Cabot, F. Jouault, Towards a their transformation. general composition semantics for rule-based model transformation, in: J. Whittle, T. Clark, T. Kühne 4.2. Running the benchmark (Eds.), Proceedings of MoDELS 2011, volume 6981 The benchmark framework only requires Python 3.3 to of LNCS, Springer-Verlag, 2011, pp. 623–637. doi:10. be installed. Furthermore, the solutions may require 1007/978-3-642-24485-8_46. additional frameworks. We would ask solution authors [7] G. Hinkel, The TTC 2017 Outage System Case for Into explicitly note dependencies to additional frameworks cremental Model Views, in: Proceedings of the 10th necessary to run their solutions. Transformation Tool Contest, volume 2026, CEUR
If all prerequisites are fulfilled, the benchmark WS.org, Marburg, Germany, 2017, pp. 3–12. URL: can be run using Python with the command python https://ceur-ws.org/Vol-2026/paper1.pdf. scripts/run.py. Additional options can be queried us- [8] A. García-Domínguez, G. Hinkel, The TTC 2019 ing the option --help. The benchmark framework can be Live Case: BibTeX to DocBook, in: Proceedings configured through the config/config.json file: this of the 12th Transformation Tool Contest, volume includes the input models to be evaluated (some of which 2550, CEUR-WS.org, Eindhoven, The Netherlands, have been excluded by default due to their high cost with 2019, pp. 61–65. URL: https://ceur-ws.org/Vol-2550/ the sample solution), the names of the tools to be run, paper8.pdf. the number of runs per tool+model, and the timeout for each command in milliseconds.
• How eficient is the approach in time and space (memory)? • How understandable is the transformation code for domain experts to review and validate?