I’ve been working with CSIRO’s Australian eHealth Research Centre (AeHRC) on their Primary Care Data Quality Foundations specifications for the past 18 months.
The project is quite unique in its approach, at least for Australia, in that it is unashamedly using an open, transparent, co-design, co-development approach - and it’s getting rave reviews from those participating. It is actively engaging clinicians, terminologists, vendors and policy/organisation stakeholders. The outputs are agreed information models and terminology value sets, which form the basis of a national data dictionary. The information models (currently published as a Word doc only) and value sets are used by the AeHRC team to build FHIR AU profiles that will be implemented by participating primary care clinical systems.
It is being shared at the CSIRO eHealth Research colloquium in Brisbane today. The project materials are all publicly available and the team are encouraging the widest possible dissemination through open publication and active networking/sharing. All materials can be freely accessed on CSIRO’s confluence site. Feel free to delve into the details and share with your networks as well.
So how on earth has an openEHR person been engaged to work on a FHIR project? There has been a lot of FUD spread about openEHR & FHIR in the past, and it is super pleasing that David Hansen, Kate Ebrill and their team have been able to push past this nonsense and bring the right group of participants into this project. And it’s working so well…
I’m bringing my best openEHR modelling skills to the table, even though it’s not technically an openEHR project, as an information modeller and a clinician informatician. I’ve analysed both the data currently in the AU primary care clinical systems and potential data needs for our use cases. Working closely with AeHRC’s best SNOMED CT terminologists, I’m proposing the potential information models in this project, using the openEHR archetypes as our starting point. So as a clinician, informatician and modeller I’m acting as a bridge between the grassroots clinicians and stakeholders who own the clinical requirements and software engineers building the FHIR profiles and implementation guides.
In Phase 1, the outputs were deliberately simple – an agreed basic set of standardised atomic data that we wanted to be implemented in the same way across all existing systems. Our use case was a Practice-to-Practice transfer of patient data and the level of detail was simply enough to be safe, and requiring only a minimum of change or additions to existing software. Essentially, we were testing the collaboration and co-design process. Phase 1 deliverables (R1)are published here, with the initial version of the AU primary care data dictionary being published as a Word doc.
Phase 2 is currently building on this foundation, aiming to reuse and extend the concepts from Phase 1 plus adding new concepts. Phase 1 extensions include a addition detail about individual family members in a Family history plus usage details related to Alcohol consumption and Tobacco smoking. The use case is focused on a standardised and digital version the Aboriginal and Torres Strait Islander health assessment (MBS item 715) that can be implemented in clinical systems. In truth the scope of a 715 form is massive and covers most of primary care, and in the initial iteration we are reusing the R1 models and adding clinical concepts around social determinants of care (SDOH).
R1 models in green; R1 extensions in purple; SDOH in yellow
All of the massive collective clinical engagement and knowledge and experience held in the openEHR archetype library is being used to inform the data structures in this national project. That it has a FHIR implementation is effectively irrelevant from my point of view - it’s the openEHR clinical content shaping the SNOMED value sets and FHIR outputs.
I was deliberately pretty tentative about declaring the openEHR source in the early days, but increasingly finding that the clinicians don’t care, nor do the CSIRO team or vendors, as the archetypes are fast-tracking the clinical requirement gathering and confirmation. As the foundation for sensible discussions around a coherent set of Australian primary care data, the openEHR archetypes are also being validated as fit for use in this Australian context for the first time. Our philosophy of building archetypes for broad reuse across different domains aligns perfectly with the philosophy of this AeHRC project and potentially how this work is broadened and deepened over time.
To be truthful, I expected more push back from clinicians, but once the approach is explained the straw-man content as recommended has been almost universally accepted. Clinicians are agreeing with it and feeding back that it is better than they’ve seen before, so why change it! Subsequently the focus of most discussion is about the level of detail they want exposed for the use case and the content of the terminology value sets – an important and familiar discussion, and a primary reason for using templates in an openEHR-enabled world.
With my openEHR hat on, this is business as usual. We’ve been making data sets using this methodology for many years.
But where I’m starting to get just a little excited is where it connects with FHIR…
For my own purposes and in the interest of transparency to the FHIR team, last week I uploaded my modelling work on the 715 form to an openEHR CKM incubator for the AU Primary Care Data Quality Project. It’s not a formal thing for the project, but useful as a way for me to govern the openEHR related artefacts for my modelling purposes.
Only two archetypes have been added for this project, otherwise all are reused from the openEHR CKM. Template for two data sets have been created, plus 7 reusable subtemplates for reuse of R1 & R2 constrained models.
You can see the master template for the Aboriginal and Torres Strait Islander health check which is still a very early draft, firstly needing confirmation of the content, then more constraints applied as we nail down the first draft content with the stakeholders. It is fascinating to see how paper forms built without consideration of clinical data can require significant refining and revision - but that is the story for another blog post…
What I want to emphasise are the 7 ENTRY level templates, each prefaced with R1 or R2. You will note that I’ve created R1 and R2 versions of Tobacco smoking summary and Family history item. These are the constraints applied for phase/release 1 and 2, with R2 demonstrating the extended content agreed only last week. R2 Education and R2 Housing are templates for new content on Social determinants of health to be included in this next phase.
R2 Occupation is a template comprising the EVALUATION for Occupation summary and it’s repeating CLUSTER for each occupation or role. They concurred with our openEHR community decision that the scope should be broader than just ‘employment’ but embrace all roles in life including ones that didn’t focus on paid employment. I actively tried to persuade the clinicians to reduce this amount of content for this phase, but after demonstrating how the model could potentially be extended with more detail about each job or role in the future, they wanted it all and they wanted it now! Not so much for SDOH purposes but to support generation of medical certificates and a more comprehensive occupation history.
As the Australian information models get agreed, finalised and published, I intend to use this incubator and these templates to support my modelling efforts for this project. I need at least this level of project governance to keep track of changes and evolving content.
Imagine if the FHIR profiles were built to match these clinical models – likely not on a 1:1 basis given the technical constraints, but in principle - one templated concept matching a known set of FHIR profiles. This means that as easily as I drag and drop a subtemplate into my next data set, we could conceptually do the same with the matching FHIR profiles. If the project modelling work and the FHIR profile generation were aligned and changes synchronised, this would showcase the build once, reuse many times principle across both the openEHR and FHIR efforts.
Clearly the FHIR tooling is not yet available to support this work. CKM can’t accept FHIR profiles at present, so we’d need to use GitHub or similar. But with potential Ontoserver integration to CKM and EHRbase, there’s a pretty neat little ecosystem evolving.
We’re getting closer to a sweet semantic ecosystem here. It just takes a willingness to play together and abandon the turf wars. Participants are raving about the process and return to each meeting with much enthusiasm. I absolutely commend David and Kate’s leadership to initiate this collaboration here in Australia - it demonstrates a depth of vision that has not been present for a long, long time.
If we can continue this process, I’m feeling more optimistic about Australian #healthIT than I have for a long time.