Body

In general, mappings always operate under the idea that we can map paths in openEHR and FHIR against each other. For this purpose, FHIRPath and openEHR paths are used. This is also the biggest limitation of these mappings: if a corresponding representation of a path is missing in one of the models, it must be added to the model in FHIR or openEHR. Otherwise, there is no mapping.

All mapping files start with the mappings key in their body, which is a list containing a set of named mappings.

The mappings: body is followed by mapping methods, each part starting with - name: "mappingName". This is called a mapping method, and the children contained underneath are called child methods.

mappings: # starts mappings
  - name: "dateTime" # name of the mapping

Name of the mappings - name: "dateTime" is used also when a mapping is being extended (for overwrite or append, see: Extension methods).

It is proposed that camelCase is used when specifying mapping names, otherwise apart from being used when referenced in extension methods, they serve no deeper meaning.

with

Inside these mapping methods, there is always a with: statement that contains fhir and openehr keys. These two keys indicate the paths that are mapped against each other.

mappings: # starts mappings
  - name: "dateTime" # name of the mapping
    with:
      fhir: "$resource.onset"
      openehr: "$archetype/data[at0001]/items[at0077]"

In this example, FHIR path onset is mapped to the corresponding openEHR path at0077 (date-time of diagnosis onset). The data types of the mapped fields are automatically resolved by the engine. In this case, it would map an onset into a DV_DATE_TIME. If the engine encounters two data types that are not transformable into each other, mapping will not be executed.

Sometimes, mappings do not transform these paths directly, depending on the mapping type used. Specific keywords, explained in the following chapters, do not automatically transform these paths but use them in another way. If no specific keys are used, the default behavior is that these paths are mapped against each other.

Top down processing

The general way of processing in FHIRconnect is top down. If two mappings are mapped to the same path with a cardinality of 0..1, the later one in the order will overwrite the first one. Also, when nesting methods, the child methods will always aim on the path of the parent, the idea here is that you iterate down the path of an element and step by step map each of the fields contained. This is explained further in the FollowedBy and Recurrence chapter

Undirectional

To execute a mapping method unidirectional the undirectional key can be added to a - name: method. This way the mapping contained is only executed in one direction. The allowed values are either "openehr→fhir" or "fhir→openehr" This is also true for all the child method contained underneath of this with method.

mappings: # starts mappings
  - name: "dateTime" # name of the mapping
    with:
      fhir: "$resource.onset"
      openehr: "$archetype/data[at0001]/items[at0077]"
    unidirectional: "openehr->fhir"