“Smart data, smarter healthcare”

Last week Hugh Leslie & I spent time in Shanghai and Huangzhou at the invitation of Professor Xudong Lu and Professor Huilong Duan. It was a privilege to be invited and particpate in the very first openEHR meetings to be held in China.

It follows on from a surprise discovery of Professor Lu’s work presented at the Medinfo conference in Brazil last year, and Prof Lu attending our openEHR training in Kyoto in Janauary.

Hugh & I presented at two events:

• a seminar of invited guests and VIPs for the first openEHR meeting to be held in China on April 18 in Shanghai – an introduction to openEHR (Heather) and an overview of openEHR activity in Australia (Hugh); followed by
• an introduction to openEHR – at the China mHealth & Medical Software conference, Shanghai on April 19

Watch my introduction to openEHR, ‘Smart data, smarter healthcare’ presentation, available via slideshare:

Bridging the interop chasms

The dilemma for implementers is: how to standardise clinical content yet use it in different clinical scenarios? How to lock down clinical content yet express variation in clinician requirements. How to create clinical content standards when every day the scope, depth and detail of the content is dynamically evolving? And then if we somehow manage to specify the content enough to successfully implement our own system, how to make that solution interoperable with others?

Everyone is running around (often in circles) trying to find the holy grail of health IT, the ‘one ring to bind them all’ of standards and, more recently, the ‘Uber of healthcare’. The sheer number of approaches reflects that there is no clear single approach at this point, no clear winning strategy.

My proposal: if we want to achieve any degree of semantic interoperability in our clinical systems we need to standardise the clinical content, keeping it open and independent of any single implementation or messaging formalism.

I noticed that John Halamka, CIO at Harvard & Beth Israel Deaconess Medical Center, was quoted in a rather unappetising Forbes article yesterday – worth reading for the interesting content but please leave the title and analogy at the door. His quote:

“FHIR is the “HTML” of healthcare. It’s based on clinical modeling by experts but does not require implementer’s to understand those details. Historically healthcare standard were easy for designers and hard for implementor’s. FHIR has focused on ease of implementation.” 

Totally agree: FHIR is the newest technology on the block and indeed many are considering it the HTML of healthcare. It has created a massive buzz of excitement around the world. But remember that HTML itself is a content free zone. Without addition of content, HTML is essentially just a technical paradigm. Similarly, without high quality clinical content, FHIR runs the risk of just being a marvellous new technical approach, elegantly solving our current implementer nightmares. We need more…

I have blogged previously about my experience participating in a FHIR clinical connectathon this time last year: The challenge for FHIR: meeting real world clinician requirements. My opinion about FHIR is neutral. I am not a software engineer. However as a clinician it was not offering enough to meet my recording needs a year ago. Little of my world has been FHIRified since. No doubt the FHIR team have a strategy for that, it will evolve, sometime.

My potentially controversial position is that it does not necessarily follow logically that the clever minds who devised FHIR are best placed to develop the clinical content that will ensure FHIR’s success. The great majority of FHIR models created to date are related to the US domain and within a rather limited scope that are largely focused on supporting existing messaging requirements and simple document exchange.

This is not a FHIR-specific problem – it is ubiquitous across the healthIT ecosystem. We need to transition away from the traditional business approach where the technicians/vendors dictate what clinicians would have in their EHR, and the data structure is determined by software engineers who have to investigate, interpret and then attempt to represent the world and work of the clinician in every EHR. With the best of intentions from both sides there is still a massive semantic chasm between the two professions.

What most technical modellers haven’t yet grappled with is the huge scope of clinical content – the sheer breadth and depth is astounding and as new knowledge is discovered it is also dynamic and evolving, which only compounds an almost impossible task. Most clinical recording in systems to date is relatively simple – usually focused on the ‘one size fits all’ minimal data set approach to enable some information to be shared broadly. It certainly has had some limited success but how long will it be before we realise that we need to standardise more than the minimum data sets.

Minimum data sets are woefully inadequate when we need to represent the detail that clinicians record as part of day-to-day patient care, for patient-specific data exchange with other clinicians, to drive complex decision support, for data querying, aggregation, analysis. Patients vary, so that no one approach will suit all – the needs for a surgical patient, a neonate, a pregnant woman vary hugely. Clinicians vary, so that no one approach will suit all – generalist vs specialist; medical and nursing notes may focus on the same things but from a completely different point of view. Clinical contexts vary, so no one approach will suit all. Many aspects of clinical recording needs recurring, fractal patterns. There are homunculi, questionnaires, normal statements, graphs, video, audio. The ‘one size fits all’ approach to health data standards is an absolute myth – in fact, the truth is actually that one size fits none.

Take the timing of medications as an example. Just this one seemingly simple data element raises a huge number of challenges for EHRs. I challenge you to show me one system in the world that enables prescribing today at the following level of detail:

This is the level of detail that clinicians need today in their clinical work. Yet most clinical systems only cater for the ability to prescribe to the level of complexity where someone can take one tablet, three times a day, after meals. Even if you try to prescribe a skin cream, many systems are unable to do anything but represent it in the most rudimentary way.

Below is the mind map of the current Medication Order archetype:

You can see and download the corresponding archetype that is currently undergoing review here. This clinical content specification is the result of years of research, investigation of existing clinical systems, engagement with vendors and standards organisations and direct clinical informatician experience. The amount of work involved in specifying this common clinical order should not be underestimated, nor should it need to be undertaken ever again if we can get appropriate levels of agreement through international domain expert review! (Please register in CKM and adopt the archetype to participate in the international review.) It is massive. It is hugely complex.

Via a similar process, we have just achieved a consensus view on our Adverse Reaction Risk archetype: 12 review rounds completed; 91 participants from 16 countries; 182 total reviews; 0 face-to-face meetings! A core concept in any clinical system, with every system implementing it slightly differently. Now we have a line drawn in the sand, a starting point for being able to share adverse reaction data that has been designed and verified by clinicians, yet immediately computable. This work was done in collaboration with the FHIR/HL7 patient care community – note the joint copyright!

Archetypes bridge the semantic chasm between clinicians and software engineers.

Using archetypes as the means to represent clinical knowledge in an open, non-proprietary way is major breakthrough in our quest to “help kill the “golden goose” of proprietary EHR data”, as the Forbes article phrases it.

One does not have to be a rocket scientist to recognise that if we leverage the 400+ existing archetypes already in the international CKM, which already incorporates a huge breadth of clinician knowledge and expertise, we can kickstart any serious development of implementable resources for any technical paradigm willing to join in.

There is a powerful logic in actively separating out development of clinical content from the implementation formalism. In that way we can develop, agree and verify the clinical content specifications once. The resulting archetypes become the free, open standard representing the clinician’s knowledge in an implementation agnostic way. Subsequently technical transformations will be able to deliver the content to the implementer in any formalism that they choose. No longer just one archetype for openEHR implementation alone, but leverage the content to develop FHIR, CIMI, CDA, v2, UML resources… Now there is a vision!

Archetypes bridge the semantic chasm between implementation formalisms.

IMO this is probably the greatest benefit : the archetyped clinical content is created once, verified as fit for use by our clinicians, and remains as a governed infostructure resource for the next years, decades and beyond. Governance processes ensure that the archetypes are maintained and can evolve within a robust versioning framework. Different implementations will have the same, standardised clinical content.

One solid truth that we can rely on in the world of technology is that FHIR, HL7v2, HL7v3, CIMI, UML, AML, openEHR and other implementation formalisms will likely be overtaken at some time in the future. As sure as death and taxes. We really don’t want to start the process of building content for the each and every new technical invention that comes along.

Archetypes bridge the chasms created by the volatile fads and fashions in IT: our resulting ehealth INFOstructure will be a non-proprietary representation of clinical knowledge that can withstand and outlast the inevitable waves of technology as they come and go. 

Archetypes are a pragmatic and sustainable approach to interoperability: between professions; between implementations; beyond our current technologies!

 

 

 

 

 

 

Ocean Case Study: Clinical Engagement

This case study of my experiences in clinician engagement is about to be published on the Ocean website and might be of interest…

Bridging the gap between the clinical experts and software engineers involved in eHealth projects is well known for being difficult and frustrating for both sides. Ocean Informatics has been at the forefront of developing a new approach that gives the clinicians an ability to drive, not just contribute to, eHealth specification development while at the same time satisfying the technical needs of the implementers.

The Northern Territory (NT) is a sparsely populated state in the very north of Australia, with small settlements scattered across the territory and limited access by road. A small, dedicated group of clinicians triage and manage remote patients via phone, and arrange recovery of critically ill patients from remote locations using the ubiquitous Royal Flying Doctor Service.  Their wish: an application that would bring their telephone triage processes into the digital age. Ocean Informatics was engaged to identify the clinical requirements and develop content specifications for a third party vendor to implement in purpose-built software.

This case-study discusses how the pragmatic ‘openEHR methodology’ approach developed by Ocean informaticians has been used to bridge the clinician-to-technologist gap.

It is very rare for this dedicated group of NT GPs to be in the same physical place at the same time, so we needed to leverage our access to their expert knowledge very efficiently. They were gathered in Darwin on two days back in 2012—we had a single opportunity for a face-to-face meeting.  Our modelling team comprised two clinical informaticians – one driving the discussion, the clinical modeller documenting the discussion.

Most of these participating clinicians had no knowledge of electronic health records (EHRs); none had any experience with openEHR. The task: to capture the clinician’s expert knowledge, convert it into computable specifications and then produce an output that could be given to the software developers for implementation.

In a workshop held over one and a half days, we:

1. Identified and recorded the clinical requirements, workflow and business rules using mind maps. From a blank mind map we gathered and organised the clinical requirements, documented their workflow and the logic that underpinned each data point. In practice we displayed the mind map on screen and used it as a living requirements document, evolving through the discussions and continuous feedback, being reorganised as we identified the complexities, dependencies and relationships of all the components.

1. Built draft clinical specifications in parallel to the mind map development, directly in front of the clinicians. This involved the clinical modeller aggregating existing openEHR archetypes into templates that accurately represented the clinicians’ mind map as well as identifying the requirements for new archetypes. The clinicians were able to verify each template’s data points and constraints against their mind map—the template was easily interpretable alongside their mind map, so they were able to easily participate. Both the mind map and templates were refined through this process.
2. Output a draft technical specification at the end of the second morning, potentially implementable.

While further refinement on the specifications was still needed due to addition of new archetypes identified in the mind map process, the project manager reflected observed that what had been achieved in less than two days would normally take them 6 months and the result would have been of a much lesser quality. Re-use of the archetypes is also a critical factor in the speed of specification development using this approach and we will see increases in the proportion of re-use as every project is completed—adding to the pool of clinically agreed archetypes that will be available for use in the next project.

Commencing a project with a face-to-face meeting has been found to be most effective way to create an environment where all participants have a baseline understanding of the process. However, after the initial workshops, further refinement of archetypes and templates can mostly be carried out via web conference, email and online collaboration using the Clinical Knowledge Manager tool (CKM) – http://www.openehr.org/ckm – or national CKM instances.  The online CKM tool enables asynchronous Web 2.0-style collaboration to iterate and refine the archetypes until the clinician consensus recommends them as ‘fit for purpose’!

Despite the Ocean clinical modeller living over 2000 kilometres away from these clinicians, ongoing collaboration was able to continue online, without the need for an expensive sequence of face-to-face meetings that would be disruptive to clinician work commitments and impair the important work-life balance.

This methodology is having great success in bringing the non-technical clinicians along with us on the clinical modelling journey. Even the less technologically savvy ones are able to actively contribute to the ‘pattern’ of the data that they can collect. The overwhelmingly consistent feedback from participants such as these is that the workshop participants enjoy the experience and are keen to be involved in ‘next steps’.

It also has the beneficial side effect that the clinicians have a sense of ownership over the data specifications – it is ‘theirs’ in a way no other clinical requirements gathering process allows. We have seen usually mild mannered clinicians take software engineers to task where their agreed template has been modified for technical reasons, demonstrating an understanding about the data that has not been easy to acquire before this approach. This kind of engagement by clinicians in development of eHealth specifications IS a rare but very fine sight to see!

Giving non-technical clinicians a very real voice and ensuring that the clinical content is appropriate in our eHealth solutions is major innovation enabled by this openEHR methodology. The simplicity and effectiveness of this approach still continues to surprise the team each time they work alongside a new group of clinical experts.