Header

The header is contained in each FHIRconnect mapping file. It is standardized for both FHIRconnect and OMOCL.

There are three different types of mapping files in FHIRconnect. For this header explanation and basic chapter we will focus on the model mappings that map an openEHR-archetype to a FHIR resource. Other types are explained later in the chapter Types of mapping files

Grammar and Type

Here we define which grammar version is used, for FHIRconnect its FHIRconnect. The name is followed by the version of the grammar used seperated by a /. The type defines what type of mapping-file this is it can be either: model, extension or context.

grammar: FHIRConnect/v1.0.0  # what grammar and version is used in this file
type: model  # the type of mapping: model, extension or context

Metadata

The metadata defines the name of the mapping, that is a unique id used to identify the mapping and reference it. The version represents which version of the mapping. Different versions can coexist, as sometimes its necessary to maintain several versions.

grammar: FHIRConnect/v1.0.0  # what grammar and version is used in this file
type: model  # the type of mapping: model, extension or context
metadata:
  name: ACTION.informed_consent.v0  #the name of the mapping
  version: 0.0.1-alpha # version of this particular mapping

Spec

This defines what standard is mapped by the file, in our case FHIR and which Release of it. The current spec was designed based on R4. FHIRconnect has not been tested with any other FHIR Releases, but no problems are expected as FHIRconnect operates on paths.

grammar: FHIRConnect/v1.0.0  # what grammar and version is used in this file
type: model  # the type of mapping: model, extension or context
metadata:
  name: ACTION.informed_consent.v0  #the name of the mapping
  version: 0.0.1-alpha # version of this particular mapping
spec: # schema specific to the FHIRConnect v0.0.1 engine
  system: FHIR  # What is mapped
  version: R4
  openEhrConfig:
    archetype: openEHR-EHR-ACTION.informed_consent.v0 # what openEHR archetype is mapped in this model mapping
    revision: 0.0.1-alpha
  fhirConfig:
    structureDefinition: http://hl7.org/fhir/StructureDefinition/Consent # to what FHIR structureDefinition this is mapped

The openEHRConfig.archetype defines which archetypes is mapped, in case of a model mapping. The openEHRCondig.revision states what revision of the archetype this mapping applies for.

The fhirConfig.structureDefintion contains the information about which FHIR StructureDefinition is mapped. This is just information for the user and has no impact on the mapping.

Naming convention

Naming conventions are as follows: Names of model mappings always start with the type of openEHR class (e.g., EVALUATION) and the full name and version. It can happen that two resources are transformed into one archetype. In this case, the name of the mapping is to be extended with what FHIR type is mapped to what openEHR archetype:

  • CLUSTER.medication.v2 (this maps medication-to-medication)

  • CLUSTER.medication.v2.substance-to-medication (this does not map a FHIR medication but an FHIR substance)

This allows for separately calling these archetype mappings for different use cases. The initial one created always stays as CLUSTER.medication.v2 and is to be seen as the default. All future mappings created that also map to medication but from another FHIR input must add a string to their name as described above. We deem the first mapping as the default one. This will prevent dependency problems by renaming the file later on. For extension and context mapping names, there is no specific style guide, as this is a project-specific decision users have to make.