This is essential reading for all who care about health data and interoperability here in New Zealand. It clearly outlines the situation we are in and a sensible path towards the goal of excellent data flow in health that we all hope for. @RMcBeth introduces it on eHealthNews.nz here.
Great work @alastairk and team!
hiso-10083-2020-interoperability-roadmap-11sept2020.pdf (1.1 MB)
I do have a concern regarding this Roadmap, from page 17:
Our position on openEHR
openEHR tools and detailed clinical models are welcome in the environment, but they will not be delivered by national programmes nor positioned as HISO standards. Previously, under our now-withdrawn reference architecture for interoperability, openEHR had a level of endorsement, but FHIR is now more prominent and this is where our efforts will go.
This implies that FHIR and openEHR are in competition, and we have chosen the former. Unfortunately, they actually address interoperability at two different levels - and both desperately need attention. They are:
This was articulated last year by @nigelmillarnz:
https://ehealthforum.nz/t/fhir-openehr-and-interoperability-standards-use-in-nz/10026/17
So my concern is that while this approach is good and will address many of the issues that impede effective data exchange, it will not tackle the fundamental long term problem of applications holding their own versions of patient data.
Does anyone else have any thoughts or feedback for this?
FHIR/OpenEHR
I believe it’s much more likely that we can demand compliant FHIR interfaces than compliance with OpenEHR, so this is a pragmatic approach for now at least. Adding an FHIR interface is relatively simple and it’s a lot better than FAX :-).
The history of the WWW shows that simple data exchange/display (HTTP/HTML) formats drive adoption and you then get the network effect giving you huge benefts and usefulness - well formatted data you can’t get is useless 
Cynically/Practically it gives software developers fewer places to hide as OpenEHR implementation while very desirable needs more collaboration and coordination.
Dave
Prof. Dave Parry
Excellent discussion and thanks for starting this @NathanK. I strongly agree that the first purpose of health information (which includes data and the context it exists in) is for the health of the patient.
There are some points of commonality among clinicians for describing health information, but many differences. Including how things are categorised. In my patient portal, a letter from a specialist was filed under lab results, and procedures and diagnoses are both lumped in as classifications. From an ontology perspective, poor organisation makes data even harder to find and work with.
It is fine to have multiple purposes for health information, such as epidemiology, funding reports, etc but these aren’t fully reflected in how we capture and work with health data today. So I hear a lot of criticism about poor data quality in primary care, but we don’t understand what good data quality would look like. AT the end of the day, health data is going to be very diverse, and won’t always include everything one might want. Interoperability needs to recognise that and help users work carefully with information.
Finally, this blueprint needs to initiate participatory work around specifically how it will operate, how issues get identified and resolved, who has governance - and how will it be paid for :). This will take time, and involve a lot of change management. To be successful, it needs to support patients’ journeys and their clinicians’ needs. It should not be another chore to fit into an overcrowded day, using terminology that’s not meaningful or inaccurate because the right words aren’t available, and fit in context.
I talked about this at HINZ last year, using my own patient journey as an example of how information needs to transform at different stages to suit different purposes.
Look forward to seeing how this develops.
Derek, is there any chance you can access that talk and share it with us? We can approach @heatherleslie for this as well.
Hello all
I agree- FHIR and OpenEHR can play together very nicely but both can be hard and the expertise in the sector is low for both. I did my masters looking at using OpenEHR platform for protoyping a clinical app and whilst there were huge advantages in storing clinical data using predefined clinical models there were a lot of gaps (this is true of both FHIR and OpenEHR) which requires significant modelling and extensions.
I’ve attached an article below about the two standards.
In the Northern Region we are starting our journey building FHIR APIs from legacy systems and yes, having data in different formats adds significant time, cost, complexity etc with the mappings. We have started with demographics FHIR APIs (from 4 legacy PAS systems) and now moving onto appointments and encounters. I’m very happy to discuss this journey with anyone and would like to present at the next HINZ on it as I have the privilage of being the product manager for this work.
My two cents worth is that FHIR is a good starting place, and getting vendors into our market with FHIR compliant integrations is a huge step forward. I really believe New Zealand would struggle to deliver an ecosystem using both standards without a huge capability and investment uplift.
INTEROPen-openEHR-and-FHIR_March2019 (1).pdf (649.5 KB)
Thanks Anna-Marie. That is a really good article.
A key point that it makes is that OpenEHR fundamentally changes that way that data is handled - it instead resides outside of applications. This is vital if we are ever going to progress from the wicked problem of exponentially increasing data transactions between applications. I fear that we are missing this in our current OpenEHR vs FHIR mindset here in NZ.
It is explained even more clearly here:
Not everyone in the NZ Health Information Standards Community has an openEHR v FHIR mindset. Certainly, HL7 New Zealand has an MoU with openEHR and some of its members have an active interest in openEHR. It is a controversial topic in some other countries where openEHR has a stronger foothold. From a design viewpoint, much depends on how deeply one believes that either standard/methodology should be implemented within (the technology layers of) an application. Should you wish to persist data in either format then there is an either/or choice to be made.