On 18/12/2018 17:04, Pablo Pazos wrote:
Yes, in fact the closest we can get to automatic transformations is just defining the mappings between openEHR classes and the correspondent FHIR resources, and feed that to a system that, for a specific openEHR instance, provides a mapper user with constrained options of FHIR resources to choose from, and vice-versa, given a FHIR resource, provide the options of openEHR classes to map to. Then will end up mapping fields of correspondent types. No magic here for now :(
this will not generally work. There is no logic to what is in FHIR resources. For example, there is no openEHR class matching the FHIR resource 'MedicationAdministration'. The latter has attributes mostly matching various Medication archetypes, but is more like a template than an archetype. But it also has some attributes matching openEHR context (RM) attributes, e.g. subject, context, performer etc. And some things that really just should not be there, like eventHistory. And things unlikely to work, e.g. 'instantiates'. And some strange things like the pair reasonCode (reason why administration performed) and statusReason (reason why the administration was not performed).
But then go have a look at FHIR Observation, and you see it is much more generic, but very inflexible. To find e.g. Blood Pressure (measurement) you have to find a profile, like this one on simplifier.net <https://simplifier.net/coreprofilesstu3/bp>. This gets rid of the main valueQuantity and then packs in the required BP structure (or at least a bit of it) as a free-tree 'component' at the bottom.
I have been unable to ascertain any scientific or formal principles on which FHIR modelling is based, which is something you need in order to write a model converter (unless your converter just has new code for every single model).
I don't claim that openEHR RM or archetypes are perfect by any means, but they have many underpinning principles which are generally followed, and that enables one to write the openEHR side of any converter based on those principle, with exceptional handling for places where we made a mistake or there is an anomaly.
- thomas
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
