extract data type mapping

[joostholslag]

I like the explicit data type mapping. I know there's currently multiple implementations of this mapping in other projects. e.g. veratech's and aucdi. So I think it would be helpful to extract this mapping, review it, and have it available for more projects. A good candidate for collaboration between fhir and hl7.

[joostholslag]

notes in discussion with @gasperr:

Gašper Andrejc
how/why would you want to have it consistent with other fhir to openehr mappings?

How: I would like it to be a computable artefact. Like a json file with a schema or something (maybe FHIR concept map or similar could work too?)

Why is a good question. It’s currently an underbelly feeling that this is useful. Which is what I’m trying to validate with you.

Some thoughts are:

• FHIR connect is one standard, but there are many implementations of openehr to FHIR, Diego had one, Ian had one, Nedap has one, probably many many others. It’s more achievable to standardise the data type mapping than to also standardise the archetype/template mapping.

• it being smaller in scope makes it easier to maintain it jointly with hl7.

-it competes less with other standards like FHIR mapping language

• it allows independent maintenance and versioning.

• it allows a wider group of people (like me) to work on it. Shareing the load and increasing quality

One area I expect there might be problems in is the complicated data types. Eg dv text which has term mappings in openehr or human name and address in FHIR. It might need more logic than a simple json file allows.

My assumption is that it's straightforward and little work (hours -days) to extract it. If this is wrong it might not be worth the effort.

On the openEHR part the delineation is quite clear: data types are all (and only afaik...) here: https://specifications.openehr.org/releases/RM/development/data_types.html#_data_types_information_model
none of the archetypes are part of the spec itself.
some FHIR data types might be archetypes in openEHR which would be an issue to my idea. My hope is this is not practically an issue. Human name and address for example are out of scope for fhir-connect I hope, because it's demographics that is not part of CKM archetypes. If this hope is idle, it may be a reason not to seperate out the data type mapping.

(mapping of primitive types e.g. string, integer, boolean etc.) I'm ok with mapping implicitly, assuming FHIR and openEHR implementations both assume common programming languages with shared (or close enough) definitions on those. right?