For anyone interested in how we can get openEHR and FHIR working together, I’m very pleased to share this news…
The Australian Core Data for Interoperability (AUCDI) Release 1 has been released as a draft for public comment.
Yes, it’s part of the Australian Sparked FHIR accelerator; the first outside of the US and the first focused on clinical data standards.
And yes, for a project with FHIR outputs, it sounds very openEHR-like in philosophy and approach because the AUCDI itself is a library of modular clinical requirements based on openEHR archetypes; and the plan for the future road map is to gradually and intentionally include more archetypes (to increase scope) and reveal more detail from each existing archetype.
I have to admit that I now sometimes wear a FHIR t-shirt under my openEHR hoodie!
TLDR…
"The AUCDI is changing the approach to health data and is set to become a national asset focused on creating an independent foundation of reusable, standardised information models and related artefacts. It is intentionally agnostic of:
Any single clinical use case while being constructed as a foundation for many clinical use cases;
Any single clinical system vendor while being strongly informed by functionality and data available in current clinical systems, and
Any single technical implementation or exchange approach while providing the clinical data requirements for developing the FHIR AU Core specifications and subsequent Implementation Guides (IG)."
"The AUCDI:
Will provide the initial foundation for an evolving ecosystem of agreed data groups, purpose-built to reflect clinical requirements for the data required to support the provision of care, exchange, aggregation for analysis, and clinical decision support.
Describes and defines a set of data groups comprising one or more data elements, forming the foundation of a common language to allow systems to exchange semantically accurate data more efficiently.
Will act as an agent for change by bridging fragmented silos of data and providing a foundation of building blocks of standardised data applicable to multiple use cases across a variety of clinical specialties, geographical locations, and professional contexts and problems.
Incorporates and builds upon existing standards and prior work from national and international programs and initiatives. It has not been developed in isolation.
Is a living artefact that will evolve and grow in future iterations to support additional use cases – adding breadth by including new clinical data groups and depth by expanding with further granular detail.
AUCDI Release 1 (R1) is focused on an agreement of the ‘core of the core’ common data elements, meaning the absolute minimum data required to support standardised clinical information capture at the point of care as well as enable the safe and meaningful exchange of information to other care providers"
The AU FHIR community is now hard at work interpreting the AUCDI clinical requirements into logical models, profiles and IGs.
"The FHIR program will create the following products during the two-year program:
Australian Core Data for Interoperability (AUCDI),
AU eRequesting Data for Interoperability
AU Core FHIR Implementation Guide,
AU eRequesting FHIR Implementation Guide,
Royal College of Pathologists Australasia (RCPA) ValueSets
Royal Australian and New Zealand College of Radiologists (RANZCR) ValueSets,
Target Operating Model for Standards development, and
Standards development roadmap to highlight priorities and sequence going forward."
You can find the AUCDI specification and feedback forms on this Confluence page:
My impression is that FHIR was designed to exchange partial data from/to source systems that already have a somewhat decent internal (often proprietary) somewhat consistent model of healthcare data, and that FHIR was not primarily designed to consistently across use cases model data ‘de novo’ in e.g. national content standardisataion projects.
Does the above resonate with your experience?
Is what you have done in Austraila something like using openEHR as a national shared model of a vendor neutral “source system” and then build FHIR models from that?
Will you be speaking/telling more about this approach in any context?
Are you allowed to explain why the official documents/statements do not mention openEHR and its role (or do they mention it somewhere inside)?
The view in AU is that FHIR is focused on exchange.
AUCDI is part of the accelerator but is creating a national approach to creating an independent clinically agreed/validated library or data dictionary of clinical data requirements. This is, in turn, directly informing the national FHIR exchange standards so they are not built in isolation by software engineers.
– The vision is that the AUCDI will then be used as modular components to support any use case - very ‘openEHR’ in philosophy. Moreso that this will also inform new clinical system development and provide a road map for the enhancement of existing clinical systems. Important to note: Vendors are actively participating in the process, ranging from local primary care systems and diagnostic providers to the major US vendors.
– The Clinical Design Group has been focused on identifying and documenting clinical requirements and ensuring clinical safety. I led the modelling component of this work, using archetypes as the vendor-neutral ‘straw person’, rather than starting from scratch. This fast-tracked the discussions because there was not a lot of disagreement about the content in the archetypes, descriptions etc. So the discussion was then tightly focused on what was in scope for the first release and what was out of scope. The clinicians felt engaged and heard in ways they haven’t in the past.
Only one data group is not directly derived from an equivalent archetype - the context of an encounter, and it probably needs to be pushed back to CKM as a change request.
– Release 1 of AUCDI is very tightly scoped - the adopted mantra is ‘core of the core’, the common bare bones of data that will start us on a journey towards a growing library of ‘data groups’/archetypes. I think of the current scope of AUCDI R1 as a minimalistic openEHR template but in a temporary Word format.
– The Technical Design Group takes the AUCDI and transforms it into FHIR logical models and IGs.
– Tooling of the end-to-end tool chain from clinical requirements gathering through to FHIR Igs including traceability is also in scope. We have early draft tools creating FHIR logical models directly from mindmaps in the first instance, and potentially ADL in the near future.
I did speak to it at the Netherlands meeting, although it was not recorded. I do intend to re-record it, and hopefully will carve out some time for that now that the AUCDI is in the wild!
Even better, I can introduce the Sparked team leads to other interested programs. No more, just ‘Heather says’! There has already been a significant collaboration with many national programs - transparency and collaboration is the only way they know to operate, which is hugely refreshing!
The AUCDI Release 1 document out for public comment accurately discloses what is the current public position - that openEHR archetypes have played a critical part in the development of the specs. And the simple reason for this is that the AeHRC team leading this work determined it was the best tool for the job and was a far better use of public funds than starting from scratch!
I have no authority to make any further representation about what Australia is ‘thinking’. However, I will emphasise that this new program and new approach is sponsored by all the peak bodies in Australia - led by the Australian eHealth Research Centre (as part of the CSIRO, Australia’s national science agency); funded and driven by the Australian Department of Health and Aged Care; supported by HL7 Australia and the Australian Digital Health Agency. This significant partnership has never happened in this way before.
We have a very ambitious 2-year funded plan with multiple deliveries. Information about the program is publicly available on Confluence. AUCDI Release 1, as the first delivery, was released for public comment last Friday and will be published in May. Planning for R2 is about to begin, and a parallel eRequesting program of work (consuming some of the AUCDI release 1 work) commenced with F2F workshops yesterday.
Great! We discussed this within openEHR Sweden today and would like to have a meeting to hear/ask more. We’ll try to coordinate this as a joint meeting with HL7 Sweden. If I am correctly infomed I also believe that Maria https://www.linkedin.com/in/maria-bäcklund-hassel-7507605/ at The Swedish eHealth Agency has connections to Sparked and might also help contact them regarding such a meeting.
If I have understood things correctly there will be a meeting on Monday the 22:nd of April, at 08.00-09.00 CET.
It is the Swedish eHealth Agency (via @Daniel_Karlsson?) that has invited representatives from the Australian SPARKED project. Info about the meeting is also distributed via HL7 Sweden and openEHR Sweden.
**The AUeReqDI builds upon and complements the foundational Australian Core Data for Interoperability (AUCDI) and focuses on the specific use case of eRequesting.
The AUeReqDI aims to standardise the capture, structure, usage, and exchange of health data to support a broad approach to eRequesting within the Australian health context.
The initial release of the AUeReqDI focuses on electronic pathology and medical imaging requests in primary and community-based care provision.
The community comment period for AUeReqDI R1 closes on 14th June 2024.
To find out more and provide feedback on the AUeReqDI, please see the Sparked website ."
This is the second deliverable in 9 months for Sparked!
The main reason it is evolving at a ripping pace is because the clinical requirements specifications are underpinned by our openEHR archetypes again and, in return, it is also funding and providing new archetypes back to the openEHR community:
The long-published Service request, and its’ new specialisations: Lab test request and Imaging exam request - both funded by this Sparked FHIR accelerator work
The new Implanted medical device summary to support identifying devices that might be contraindicated for an MRI or other imaging test.