I have a project that I’m working on. We’re creating a CPOE for medication, and we’re not sure which information model we should use to store our content. I’m more familiar with FHIR, but I’m also a fan of openEHR. I have heard from the openEHR community for quite some time that they encourage developers to store data in the openEHR model.
So, to do this project, I decided to analyze which one to choose. Here are the processes I did for this work.
- I used Archetype Designer to create a template and include the Medication Order archetype.
- I filled in almost all SLOTs with pertinent archetypes. I haven’t filled in those who didn’t specify any archetypes in the “Include” part of the SLOT (I don’t know what it calls). Other ones are not much related to the medication order (such as the minor detail of the administration device).
- I exported it as an Excel file and re-format it to be more similar to FHIR.
- I filled in some descriptions or comments from the CKM and studied each element to learn the meaning.
- I duplicated it to another sheet and mapping with FHIR. I exclude SLOT and CLUSTER elements because their main goal is structuring (I think the way they work is quite similar to complex and backbone elements in FHIR).
And here is the result
Disclaimer: I’m not an expert in openEHR or FHIR, especially openEHR. I might understand the meaning of some elements wrong, or I could incorrectly map. But I have tried my best. I would love any feedback.
Featured image by Mick Haupt on Unsplash
Read more
Result
In overall, there are 138 data elements in openEHR medication order after the exclusion of SLOTs/CLUSTERs. From these elements, I could map FHIR elements into 97 elements. That is around 70% of all elements. There are 41 elements that I couldn’t find FHIR elements to map (shown as None in the spreadsheet).
However, several things to note here.
- There are many elements that I would say it’s not fully equivalent in the meaning. But it might be OK to use those FHIR elements.
- I mapped many elements as many-to-one, i.e., several openEHR elements share the same FHIR element. I would say that this can be implied that openEHR’s overall granularity is a bit more than FHIR. For example, in the body structure archetype/resource. The openEHR use 3 elements to fine-tune the location (Laterality, Aspect, Anatomical line), but FHIR uses only
BodyStructure.locationQualifierfor all three meanings. - In my opinion, most elements that I can’t find FHIR resources (to map) seem to be not much important and not be used much. I would say even though we build our system based on the FHIR information model, we would not need many extensions.
- I haven’t tried mapping in the opposite direction. I think there might be some elements that exist in FHIR but don’t exist in openEHR as well. I saw the ePrescription (FHIR) template in the CKM. I think it’s an excellent example of mapping in this direction, but it’s pretty outdated now.
Conclusion
I still can’t find my own conclusion about which information model to use in our project. But if I had to choose today, maybe I would prefer FHIR, just because I’m more familiar with it, and it seems good enough to capture essential data. And in my context, the hospital still uses paper prescriptions. I don’t think we can implement a system with comprehensive data capturing capability anyway.
Hi Rath,
Couple of points – 1. OpenEHR has been designed for Clinical Information Modelling and working out persistence of the data while 2. FHIR was mainly designed to work on the exchange of this data – handling the variations in data storage and terms etc…. so both these actually address different aspects in Healthcare Information Technology.
Looking at your Clinical Information Model for medication orders , what seems to be missing is the frequency of the medication and number of days the medication is to be given for. These data elements are important especially when administrating antibiotics or steroids and such . For example a medications may be given tid ( three times a day – not very dependent on the exact time for administration ) or doctor may specify q 8h ( meaning the doses should be given as much as possible in 8 hourly intervals , which again is a frequency of three times a day but more fastidious on the timing of the administration) To complete the picture of the medication order these are needed , you will find data elements for these in Open EHR structured dose and timing directions cluster and in FHIR resource Medication Request (MedicationRequest.dispenseRequest.dispenseInterval and MedicationRequest.dispenseRequest.initialFill.duration)
2. IMHO – it is better to use OpenEHR for Clinical Information Modelling because – for any given clinical concept there will be an archetype- eg Pulse rate – and Open EHR presents to you a “superset of data elements possible for each clinical concept like pulse rate” from which you pick and choose the data elements that are relevant for your particular use case- by deleting the data elements from the super set that are not relevant for you like pulse character or irregular type etc . While in FHIR , you do not find a resource called pulse rate – it is a data element within Vital signs profile as observation/heart-rate but only with quantity being described , not quality such as irregular type and character. ( you can use datatypes such as CodeableConcept to describe the pulse character etc but FHIR does not present a super set of data elements possible for each clinical concept , while Open EHR attempts to do so.)
Hope this somewhat communicates my take to your question – Best Regards, Dr Pramod
Thanks for the feedback and discussion Dr. Jacob
1. Actually, I already included the Dosage and Timing (both daily and non-daily) archetypes in the Google Sheet, starting from row 62. I mapped the frequency to MedicationRequest.dosageInstruction.timing.repeat.frequency because I think it is the element for this data, and many examples in FHIR spec do this as well.
2. This is my opinion today, which might be changed in the future
I think I understand what openEHR community tried to propose. But in my opinion, the value of this approach is not in a data that are pretty simple like basic vital signs. I know openEHR community hate FHIR profiling but I think in this case profiling is good enough to communicate between stakeholders. And FHIR has a standard profile for basic vital signs. So I think it’s standardize enough for my use case.
I know the openEHR community wouldn’t like this, but working with FHIR is still easier, from creating profile to creating a resource json/xml. I appreciated the effort of openEHR community lately to make it easier, such as the introduction of flat/structured json in EHRBase or the making of Archetype Designer free for everyone. But in overall using FHIR is still easier than openEHR. And FHIR has many more tooling around it as well. I think openEHR’s tooling & ease of use will improve in the future. But for now there are still some gaps.
Lastly, even we decide to store data in FHIR model today. I think it will not difficult to migrate to openEHR later if we want because openEHR has every data elements anyway (the ‘superset’ that you mentioned).
This is my opinion now, but like I said, it might change in the future. Thanks for the feedback and discussion Dr. Pramod. It helps me learn more about the topic as well
Nice work,
Here is my effort at mapping MedicationStatment to openEHR Medication Request.
https://github.com/freshehr/openehr-care-connect-adaptor/blob/master/docs/mapping_guidance/openEHR-MedicationOrder-to-FHIR-MedicationStatement-STU3-mappings.adoc
I think your assessment that FHIR may be ‘good enough’ for your immediate use has merits but agree too with Dr Jacob that as your requirements grow (and they will!), you may find that life gets increasingly difficult. There are some really good openEHR-based prescribing systems in production and widely deployed e.g the Better Meds product (hospital) and Pasientsky (GP system).
Alistair Allan just recently published a great analysis of openEHR vs. FHIR for persistence.
https://medium.com/@alastairallen/fhir-openehr-2022-53716f837340
Dear Dr. Ian,
Oh, I apologize that I missed your comment for over a year – it went to my junk folder and I didn’t notice it. Thank you for your feedback.
There’s an update: My team and I are now using the openEHR medication model in our clinical decision support project, as I described in this LinkedIn post:
https://www.linkedin.com/posts/rathpanyowat_my-team-and-i-are-designing-an-information-activity-7033811309209034754-ojsk/
After this work, my team has become more interested in openEHR. We will study it further.