On Tue, Dec 18, 2018 at 2:50 PM Thomas Beale <thomas.be...@openehr.org> wrote:
> > 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* pablo.pa...@cabolabs.com +598 99 043 145 skype: cabolabs Subscribe to our newsletter <http://eepurl.com/b_w_tj> <https://cabolabs.com/> http://www.cabolabs.com https://cloudehrserver.com
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
