On Tue, Dec 18, 2018 at 2:50 PM Thomas Beale <thomas.be...@openehr.org>

> 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).
I'm not implying each FHIR resource has a correspondent openEHR class or
vice-versa. To be correct, I should add "create the mappings that can be
done at the IM level", other mappings, might be done between a FHIR
resource and an openEHR archetype or archetypes (like
MedicationAdministration), and others might be done between a FHIR profile
and an openEHR archetype/s. The point was: without this, the
transformations are 100% manual, with this, the transformations can be
assisted at some point, but this is far from automatic transformations.

> 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

*Ing. Pablo Pazos Gutiérrez*
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
openEHR-technical mailing list

Reply via email to