In China, recently, our MOH revised and published the industry standard family - Health data element dictionary (WS/T 363, 17 parts, 2200+ data elements) and its accompanying value domains (WS/T 364, 17 parts, 300+ value domains) . Where should the mappings of national health info data elements to openEHR go? In other words, where to hold these mappings?
Thanks
For example, a specific template to hold the openEHR Archetype data points/groups (as targets of mappings) and the national Health data elements (as sources of mappings)? And the accompanying value domains would be recorded as terminology bindings?
I would definitely capture this information outside archetype and templates, other than perhaps for very local archetypes.
We have had some success in a similar projects in just using spreadsheets to map each national data element to a specific archetype/ archetype path.
Then you can use FHIR ConceptMaps to map any Valuesets, at least where these are straightforward. The nice thing is that these are executable by a FHIR terminology server
thanks, Ian! Very practical feedback and suggestions 
Is this Template relevant to my need/question?
COVID-19 Pneumonia Diagnosis and Treatment (7th edition)
It looks like a structure data set for data exchange.
Yes and no!
It depends on whether you are creating some sort of context-agnostic data dictionary, or actually doing an integration.
That template was built to faciitate reporting to a standard COVID dataset so it might well make use of the mappings defined in some kind of data dictionary bit it does not store the mappings themselves. You would still need to define the mappings from the template into the national data elements for this use case.
Thanks, Ian.
I’m looking for an openEHR formal format/artifact/mechanism to store the mappings.
I’m looking for an openEHR formal format/artifact/mechanism to store the mappings.
I do not think you can do this directly in openEHR except via workarounds. For example using metadata (Annotations, descriptions) around elements/items in models. FeederAudit maybe, to an extent, can at least let you say where the original data came from for any specific data point and perhaps you could separately document how you want FeederAudit to be used in your interop process.
None of these things are probably reliable enough or scalable enough for what you seem to need. I am assuming what you need is a detailed mapping document to state:
Heading or item from Document A ↔ Heading or item in openEHR
To date, and my experience is still pretty limited there, when we have had to do this we keep and maintain external documents describing the mappings.
How you describe the openEHR paths in a consistent syntax in external documents is not yet clear to me though. For example , we have an external term code & description coming into an openEHR item DV_CodedText - how should I document that in an external document?
I do not think you can easily make your ‘National Headings’->‘openEHR’ map machine processable, if that is an objective for you?
Paul
Yup - the simple answer is there isn’t an openEHR way of doing this, or TBH even a ‘standard’ way of doing this.
if the need is just to map one coded term to another then the FHIR ConceptMap idea is pretty good, however if you need to document mappings between different data structures/paths then, so far, there is nothing that has really got traction. FHIR has StructuredMappings but I’ve not seen many real-world examples.
Also some tools like Mauro Mapper which is getting a little traction in UK,
In the past, we have tried to embed mappings in template annotations but that starts to get quite messy and, so far, just using spreadsheets as I suggested above (possibly in concert with FHIR ConceptMaps) has worked best for us and is much easier for 3rd party developers to understand/ share, and I think this is pretty true in healthIT generally, not just openEHR.
I’m sure something better will come along but right now spreadsheets is where I’d go!!
AFAIK, the CKM team is looking into adding a functionality to upload and maintain mappings regarding a certain object (Archetype, Template too?). Maybe @sebastian.garde can share a bit on that.
But, of course, this approach also wouldn’t add the mappings to the openEHR artifact itself. I’d guess the goal here would be to streamline the modeling and mapping work and keep all things in one place, under one governance.
Yes, we will add the ability to add/attach mapping files to archetypes and templates in the forthcoming CKM release.
That said, there are many open questions here - Ian has described some of the challenges a bit above - and my hope is that adding this (initial) capability to CKM will help focus the discussion around this.
In addition to simple Spreadsheets, ConceptMaps or in theory StructuredMappings, etc, I’d like to throw the hats of OMOCL and FHIR Connect into the ring.
Whether this will lead to spec changes to be able to properly specify such mappings directly in the model or whether they will remain separate (my current guess), we will have to see. For external mappings files, the governance in relation to the models (as a moving target) will be important.
Based on where the journey goes, we can do more around this topic in CKM in the future.
@Paulmiller @ian.mcnicoll @jake.smolka @sebastian.garde
Wow, thanks all. And your comments have given me a clearer understanding of the issue, and I’m looking forward to the new feature of CKM and any new openEHR mechanism(s).
This can be a good topic to work together with the FHIR community in the new collaboration framework.
