# FHIR Logical models from openEHR templates
**URL:** https://discourse.openehr.org/t/fhir-logical-models-from-openehr-templates/1144
**Category:** LinkEHR
**Created:** [4 December 2020 13:46 UTC](https://discourse.openehr.org/t/fhir-logical-models-from-openehr-templates/1144 "2020-12-04T13:46:15Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [4 December 2020 13:46 UTC](https://discourse.openehr.org/t/fhir-logical-models-from-openehr-templates/1144/1 "2020-12-04T13:46:15Z")
Ok here is something really cool.
Take an openEHR template like [ReSPECT-3](https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJGQ0MjcyZmVjMWI1MDQ0YjZhNjlmNThlMzNlYTExM2Vk)
hand it to the wizard that is @yampeku
and 10 seconds later back comes this [FHIR logical model](https://simplifier.net/snippet/ianmcnicoll/4)
Very much a first cut proof-of-concept but I can see all sort of possibilities.
Great job.
---
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [4 December 2020 14:39 UTC](https://discourse.openehr.org/t/fhir-logical-models-from-openehr-templates/1144/2 "2020-12-04T14:39:45Z")
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.
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [4 December 2020 14:52 UTC](https://discourse.openehr.org/t/fhir-logical-models-from-openehr-templates/1144/3 "2020-12-04T14:52:56Z")
Nice work! Just from a quick look, my guess is you could:
- rename Tree and List nodes to ‘data’ (Item\_tree nodes as well I think)
- rename protocol\_Tree, protocol\_Item\_tree nodes to ‘protocol’
- presumably the same could happen for state\_xxx -\> ‘state’, inside Observations.
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [4 December 2020 14:59 UTC](https://discourse.openehr.org/t/fhir-logical-models-from-openehr-templates/1144/4 "2020-12-04T14:59:02Z")
> [@thomas.beale](#):
>
> - rename Tree and List nodes to ‘data’ (Item\_tree nodes as well I think)
> - rename protocol\_Tree, protocol\_Item\_tree nodes to ‘protocol’
> - presumably the same could happen for state\_xxx → ‘state’, inside Observations.
Yup! 😀 I have a whole bunch of suggestions for @yampeku but am trying very hard to “curb my enthusiasm”
---
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [4 December 2020 15:21 UTC](https://discourse.openehr.org/t/fhir-logical-models-from-openehr-templates/1144/5 "2020-12-04T15:21:17Z")
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 🙂
---
### Author:  [@johnmeredith](https://discourse.openehr.org/u/johnmeredith)
#### Post date: [4 January 2021 12:40 UTC](https://discourse.openehr.org/t/fhir-logical-models-from-openehr-templates/1144/6 "2021-01-04T12:40:59Z")
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.
---
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [4 January 2021 13:08 UTC](https://discourse.openehr.org/t/fhir-logical-models-from-openehr-templates/1144/7 "2021-01-04T13:08:26Z")
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.
---
### Author:  [@Sidharth\_Ramesh](https://discourse.openehr.org/u/Sidharth_Ramesh)
#### Post date: [11 January 2021 16:20 UTC](https://discourse.openehr.org/t/fhir-logical-models-from-openehr-templates/1144/8 "2021-01-11T16:20:40Z")
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?
---
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [12 January 2021 08:03 UTC](https://discourse.openehr.org/t/fhir-logical-models-from-openehr-templates/1144/9 "2021-01-12T08:03:50Z")
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](http://standardsmania.blogspot.com/2020/04/generating-fhir-questionnaire-resources.html)
[Observation profiles](http://standardsmania.blogspot.com/2019/10/using-linkehr-to-generate-fhir.html)
[Considerations on FHIR\<—\>openEHR](http://standardsmania.blogspot.com/2019/07/openehr-observations-to-fhir-profiles.html)
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [12 January 2021 08:44 UTC](https://discourse.openehr.org/t/fhir-logical-models-from-openehr-templates/1144/10 "2021-01-12T08:44:42Z")
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.
---
### Author:  [@Sidharth\_Ramesh](https://discourse.openehr.org/u/Sidharth_Ramesh)
#### Post date: [12 January 2021 09:15 UTC](https://discourse.openehr.org/t/fhir-logical-models-from-openehr-templates/1144/11 "2021-01-12T09:15:52Z")
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.
---
### Author:  [@heather.leslie](https://discourse.openehr.org/u/heather.leslie)
#### Post date: [12 January 2021 09:36 UTC](https://discourse.openehr.org/t/fhir-logical-models-from-openehr-templates/1144/12 "2021-01-12T09:36:53Z")
> [@ian.mcnicoll](#):
>
> @heatherleslie 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.
I blogged about it last year - [openEHR, SNOMED CT & FHIR collaboration: an emerging case study — Atomica Informatics](https://www.atomicainformatics.com/archetypical/2020/3/4/openehr-snomed-fhir-collaboration).
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.