With this basis, using some of these resources as if they were reference model classes to be used in archetype definition tools seems like a good experiment.
The FHIR Reference Model
Luckily for us, even if FHIR 'source of truth' are 'Excel spreadsheets saved as XML plus a variety of ini, html and XML files', FHIR also provides a set of XML Schemas for validation purposes and code generation. We can use these XML Schemas as a way of importing FHIR Reference Model (RM) into LinkEHR Studio |
| LinkEHR reference model manager |
With this, we can create new archetypes based on FHIR RM (at least from the one it makes sense to do that). Having everything else in the RM is also helpful to create mappings between these resources and other RM (e.g. HL7 CDA, openEHR, ISO13606, CDISC ODM...) in order to generate transformation programs for them.
 |
| FHIR profile as archetype |
There are probably two drawbacks to this approach, and both are due to non-technical reasons (and probably related): There are already a couple of tools for profiling in FHIR, and most people from FHIR community doesn't see the benefits of using archetypes for profile definition. So what else can be done to ease these concerns? Two come to mind: Integrate into FHIR workflow by providing means of going from profiles to archetypes, and provide added value to attract people to use the tooling.
From Profiles to Archetypes (& Added Value)
Luckily, the definition of profiles themselves follows a known structure (StructureDefinition resource) and can be easily parsed to generate archetypes from them. We added LinkEHR the ability to import FHIR profiles. |
| Importing a FHIR profile as an archetype |
Right off the bat, these FHIR archetypes provide some advantages, such as multilinguality, solving profile consistency, and reuse of semantic artifacts (archetype slots, internal references, and semantic patterns)(More about this on [1]). In addition to that, they also allow the use of our tooling to derive from these FHIR archetypes interesting reference materials such as mindmaps, schematron rules, Json Schema, implementation guides, and more importantly, automatic generation of transformation programs from mapping definitions.
Furthermore, FHIR StructureDefinitions also contain mappings definitions to several standards and terminologies. Terminology mappings (Loinc, etc.) can be added as archetype terminology bindings. Mappings to other standards such as HL7 CDA can be used to create mapping definitions that LinkEHR can understand.
 | |
| FHIR archetype with mapping imported from profile | definition |
These mapping definitions can be then automatically compiled into an XQuery program to transform CDA data instances into FHIR data instances. Notice that users do not need to provide any additional mappings for this automatic generation (but they can if needed, of course).
 |
| Automatic generation of XQuery |
 |
| Testing the XQuery |
What is Next?
With this, we have generated a one way import process from profiles to archetypes. The other way around (archetypes to profiles/StructureDefinition) seems like the obvious next step, and shouldn't be too hard.[1] Combining Archetypes with Fast Health Interoperability Resources in Future-proof Health Information Systems
MIE presentation
