Ok here is something really cool.
Take an openEHR template like ReSPECT-3
hand it to the wizard that is @yampeku
and 10 seconds later back comes this FHIR logical model
Very much a first cut proof-of-concept but I can see all sort of possibilities.
Great job.
No problem 
. I will release a new version of the tool next week that solves some problems when using the Logical model generator from OPTs.
Nice work! Just from a quick look, my guess is you could:
Yup! 
I have a whole bunch of suggestions for @yampeku but am trying very hard to “curb my enthusiasm”
Yeah, I would say now is like done in a 80/20 way. Adjusting things like the ones you say or adding others like original openehr path won’t be difficult changes, but probably deciding them takes more time 
Don’t start me off on abuse of the Pareto principle… 
This is superb work though. We have direct applications for this in the openEHR>FHIR work we are about to embark upon. Hopefully we can put this to use very soon.
Yes, however I think it’s good enough right now, probably very little discrepancies remain (as in, it parses and loads in simplifier, but maybe other external services use different validators). I know for sure that ArtDecor does indeed use a different one, and some extra things were added so the logical models can be parsed.
I don’t fully understand the scope of this yet. Can anyone explain it to me?
Some context: I’ve been trying to generate FHIR resources from the archetypes in a template directly. So far it seems to be an uphill battle since the expressivity of FHIR is not comparable to openEHR.
Will this help with mapping compositions to and from FHIR?
I don’t think that this can be used for data transformation directly, but for modelling purposes. The logical models want to represent faithfully the original models in the system (in this case openEHR). For data transformation there are already other developments for Observation profiles and questionnaire instances
Questionnaire instances
Observation profiles
Considerations on FHIR<—>openEHR
Hi Sidharth,
Agree with Diego. FHIR logical models are essentially clinical requirements documents, although they use basic FHIR structures and datatypes, these are not implementable FHIR artefacts. Someone has to actively choose the correct FHIR resources/profiles, which as you recognise is the hard part.
Nevertheless there is merit in using openEHR tooling and templates to develop FHIR logical models, particularly if these can auto-gnerated from templates, which Diego has shown can be done. @heather.leslie was involved in work in Australia which used openEHR methodology and tooling to create templates which were then handed over tot he FHIR technical people to decide on the appropriate resources and profiles. The advantage for us in openEHR is that our work clinical y and technically is finished when we have the template - no need for further engineering.
This becomes most obvious when we move out of FHIR’s comfort zone into detailed Care pathway datasets where right now openEHR has a whole bunch of concrete models e.g the recent Ceilings of Treatment archetype which are likely to be represented in FHIR as questionaire resources. That might be fine for exchange but it really does not support app building adequately.
And, of course we can autogenerate Questionnaire bundles from templates too.
Thank you for the explanation @yampeku and @ian.mcnicoll. I can see how this can be used to bridge different openEHR and FHIR teams by just using the logical model as the intermediary. Very exciting!
@yampeku I’ll read your articles about FHIR and openEHR mapping.
I blogged about it last year - openEHR, SNOMED CT & FHIR collaboration: an emerging case study — Atomica Informatics.
The process has worked well from a modelling POV. I use ClinFHIR as the modelling tool, and the logical modelling is 98% based on openEHR archetypes. The poor FHIR modellers are having a tough time though as the clinical data requirements far exceed the FHIR resources. For example, 10 data elements from the tobacco smoking requirement need to be represented in separate FHIR observations. Originally it was going to be a 1:1 relationship between each openEHR data element and a single FHIR observation, but I think they’ve started to group the ‘per episode’ data as a component, otherwise separate FHIR observations for ‘start date’ and ‘stop date’ and ‘description’. Surely this is not sustainable at a global level, compounded by the fact that each profile will potentially be grouped differently…
Phase 2 has now been completed. Phase 3 is awaiting lockdown funding paralysis to be sorted, although all the participants enthusiastically want it to continue. The requirements gathering process and the role of openEHR has been well received. The FHIR IG and implementations are still to come.
