Archetypical
We have had the technology for a purpose-built openEHR-compliant 'plug & play' platform for some time; standalone applications have been built, but just recently it appears that the practical reality of an multi-application platform is also about to happen. "We have the technology. We have the capability..." Stay tuned.
...Reminds me of my 1970's hero, Steve Austin, the Six Million Dollar Man. With apologies to Steve:
"We have the technology. We have the capability to make the world's first universal health platform. openEHR will be that platform. Better than ever before. Robust health data...application independent...semantically interoperable!"
[youtube http://www.youtube.com/watch?v=K7zNY0I5JNI&w=480&h=360]
How valuable do we really think health data is? How seriously do we take our responsibility to preserve the integrity of our health data? Probably not nearly as much as we should.
Consider the current situation of most clinicians or organisations when purchasing a clinical EHR system. What do they look for? Many possible answers are obvious, but there is one question that I suspect very few are asking. How many consider what data they will be able to export and convert to another format, preserving the current data integrity, at the end of the typical 5-10 year life span of the application? Am I wrong if I suggest it is not many at all?
Despite all the effort that we clinicians put into entering detailed data to create a quality health record we don't seem to often consider the " What next?" scenario. How much and precisely what data will we be able to safely extract, export, transfer or convert into the next, inevitable, clinical system? Ironically, we are simultaneously well aware that clinical systems have a limited technical life span.
Any and all of the health data in a health record is an incredibly valuable asset to the holder, to the patient (if these are not the same entities) and to those downstream with whom we may share it in the future - in terms of $$ invested; manpower resources used to capture, store, classify, update and maintain it; and not least the future value that comes from appropriate and safe clinical decisions being made upon the integrity of existing EHR data.
Yet we don't seem to consider it much... yet. However, as more clinicians are creating increasing amounts of isolated pockets of health data, we should be thinking about it very hard.
Every time we change systems we put our health data at risk - risk of absolute data loss and risk of possible corruption during the conversion. The integrity of health data cannot be guaranteed each time it is ported into a new system because current methods always require some kind of intervention - mapping, transformations, tweaking, 'cleaning', etc. Small errors can creep in with each data manipulation and which over time, can compromise the safety and value of our health data. On principle we know that the data should not be manipulated, but being limited by our traditional approach to siloed EHR applications, we have previously had little choice.
We need to change our approach and preserve the integrity of our health data at all costs. After all it is the only reason why we record any facts or activity in an electronic health record - so we can use the data for direct patient care; share & exchange the data; aggregate and analyse the data, and use the data as the basis for clinical decision support.
We should not be focused on the application alone.
Apps will come and go, but we want our health data to persist - accurate and safe for clinical use - beyond the life span of any one clinical software application.
I've said this before, but it's worth saying many times over:
It's. all. about. the. data.
One of the key benefits of the openEHR paradigm is that the data specifications (the archetypes) are defined independently of any specific clinical system or application; are based on an open EHR architecture specification; and are publicly available in repositories such as the Clinical Knowledge Manager. It means that any data that is captured according to the archetype specification is directly usable by any and all archetype-compliant systems. Plus the data is no longer hard-wired into a proprietary application so that it is orders of magnitude easier to accurately share or transfer health data than it has before.
Clinical system vendors that don't directly embrace the archetype-technology may still 'archetype-aware', and can choose to use the archetype specifications as a means to understand the meaning of existing archetyped data and integrate it appropriately into their systems. Similarly they can map from their non-openEHR systems to the archetype specifications as a standardised method for data export and exchange.
The openEHR paradigm enables potential for archetype-compliant systems to share the same archetyped data repository - along the lines of an Apple platform 'plug & play' approach, with applications being added, removed or updated to suit the needs of the end-users, while the data persists intact. No more data conversions needed.
Adapted from Martin van der Meer, 2009Now that's good news for our health data.
This blog, and hopefully some others following, will be about my thinking and considerations as I man an exhibition booth at the huge HIMSS12 conference for the first time next month… Well, we’ve committed. We’re bringing some of the key Ocean offerings all across the ocean to HIMSS12 in Las Vegas next month. If it was just another conference, I wouldn’t be writing about it. But this is a seriously daunting prospect for me. I’ve presented papers, organised workshops, and run conference booths in many places over the years – in Sarajevo, Göteborg, Stockholm, Capetown, Singapore, London, Brisbane, Sydney, Melbourne – but this is sooooooo different!
The equivalent conference here in Australia would gather 600-800 delegates, maybe 40-50 exhibition booths. Most European conferences seem to be a similar size, admittedly these are probably with a more academic emphasis, rather than such a strong commercial bent, which might explain some of the size difference. By comparison, last year’s HIMSS conference had 31,500 attendees and over 1000 exhibition booths – no incorrect zeros here - just mega huge!
I can’t even begin to imagine how one can accommodate so many people in one location. I have never even visited HIMSS before – we are relying heavily on second hand reports. You may start to understand my ‘deer in headlights’ sensation as we plan our first approach to the US market in this way.
Ocean's profile is much higher elsewhere internationally. Our activity in the London-based openEHR Foundation and our products/consulting skills have a reasonable profile in Australia and throughout much of Europe; and awareness is growing in Brazil as the first major region in South America. In many ways the US is the one of the last places for openEHR to make a significant impression – there are some pockets of understanding, but the limited uptake is clearly an orthogonal approach to the major commercial drivers in the US at present, however we are observing that this is slowly changing... hence our decision to run the gauntlet!
openEHR’s key objective is creation of a shareable, lifelong health record - the concept of an application-independent, multilingual, universal health record. The specification is founded upon the the notion of a health record as a collection of actual health information, in contrast to the common idea that a health record is an application-focused EHR or EMR. In the openEHR environment the emphasis is on the capture, storage, exchange and re-use of application-independent data based on shared definitions of clinical content – the archetypes and templates, bound to terminology. In openEHR we call them archetypes; in ISO, similar constructs are referred to as DCMs; and, most recently, there are the new models proposed by the CIMI initiative. It’s still all about the data!
So, we’re planning to showcase two products that have been designed and built to contribute to an openEHR-based health record - the Clinical Knowledge Manager (CKM), as the collective resource for the standardised clinical content, and OceanEHR, which provides the technical and medico-legal foundation for any openEHR-based health record – the EHR repository, health application platform and terminology services. In addition, we’ll be demonstrating Multiprac – an infection control system that uses the openEHR models and is built upon the OceanEHR foundation. So Multiprac is one of the first of a new generation of health record applications which share common clinical content.
This will be interesting experience as neither are probably the sort of product typical attendees will be looking for when visiting the HIMSS exhibition. So therein lies one of our major challenges – how to get in touch with the right market segment… on a budget!
We are seeking to engage with like-minded individuals or organisations who prioritise the health data itself and, in particular, those seeking to use shared and clinically verified definitions of data as a common means to:
These will likely be national health IT programs; jurisdictions; research institutions; secondary users of data; EHR application developers; and of course the clinicians who would like to participate in the archetype development process.
So far I have in my arsenal:
So all in all, this will definitely be learning exercise of exponential proportions.
To those of you who have done this before, I’m very keen to receive any insight or advice at this point. What suggestions do you have to assist a small non-US based company with non-mainstream products make an impact at HIMSS?
With the recent public statement from the Clinical Information Modelling Initiative (CIMI) my cynical heart feels a little flutter of excitement. Maybe, just maybe, we are on the brink of a significant disruption in eHealth. Personally I have found that the concept of standardising clinical content to be compelling and hence my choice to become involved in development of archetypes. During my openEHR journey over the past 5 or so years it has been very interesting to watch the changing attitudes internationally - from curiosity and 'odd one out' through to "well, maybe there's something in this after all".
And now we have the CIMI announcement...
So what has been achieved? What should we celebrate and why?
At worst, we have had a line drawn in the sand: a prominent group of thought leaders in the international health informatics domain have gathered and, through a somewhat feisty process, recognised that a collaborative approach to the development of a single logical clinical content representation (the CIMI core reference model) is a desirable basis for interoperability across formalisms. Despite most of the participants having significant investment and loyalty to their own current methodology and flavor of clinical models, they have cast aside the usual 'not invented here' shackle and identified a common approach to an initial modelling formalism from which other models will be derived or developed. Whether any common clinical content models are eventually built or not, naming of ADL 1.5 and the openEHR constraint model as the initial formalism is a significant recognition of the longstanding work of the openEHR Foundation team - the early specifications emerged nearly 20 years ago.
At its idealistic best, it potentially opens up a new chapter for health informatics, one that deviates from the relatively safe path of incremental innovation that we have followed for so many years - the reliance on messages/documents/hubs to enable us to exchange health information. There is an opportunity to take a divergent path, a potentially transformational innovation, where the focus is on the data itself, and the message/document/EHR becomes more simply just the receptacle or vehicle for the data. It could give us a very real opportunity to store lifelong health information; simplify data exchange (whether by messages or documents), aggregation, querying and analysis; and support knowledge-based activities such as decision support - all because we will (hopefully) have non-proprietary, common, agreed and fully defined models of clinical content and known transformations between each formalism.
Progress during the next few months will be telling. In January 2012, immediately before the next HL7 meeting in San Antonio, the group will gather again to discuss next steps.
There is a very real risk that despite best intentions all of this will fade away to nothing. The list of participating organisations, including high profile standards organisations and national eHealth programs, is a veritable Who's Who of international health IT royalty, so they will all come with their own (organisational and individual) work experience, existing modelling resources, hope, enthusiasm, cynicism, political agendas, bias and alliances. It could be enough to sink the work of this fledgling group.
But many are battle-weary, having been trudging down this eHealth path for a long time - some now gradually realising that the glacial incremental innovation is not delivering the long-term sustainable answers required for creating 21st Century EHRs as they had once hoped. So maybe this could be the trigger to make CIMI fly!
I think that CIMI is a very bright spark on the health IT horizon. Let's hope that with the right management and governance it can be agilely nurtured into a major positive force for change. And in the future, when its governance is mature and processes robust, we can integrate CIMI into the formal standards processes.
Best of luck, CIMI. We're watching!
The bulk of openEHR archetype modelling is focused on how to record the positive presence of data – for example the diagnosis of diabetes or asthma, or orders for long-term beta blocker medication. When it is not possible to determine data values – the nature of clinical medicine being not so exact a science – 'null flavours' are used to mark an 'incapacity to obtain data', especially for a mandatory data point. The current openEHR null flavours are:
If there is no data recorded at all, nor any null flavour, no conclusion can safely be drawn from the lack of data; there is a void in our knowledge.
And then there is the need to record things that are noticeably not present. Some approaches subscribe the notion of 'negation' – resulting in a somewhat awkward and potentially ambiguous statement that might go something along the lines of 'diagnosis of diabetes, not', potentially sitting closely alongside another selectable term of 'diagnosis of diabetes'. You can see that it is easy to get it wrong.
The openEHR preferred approach is to record the positive absence of data – an explicit and unambiguous statement of 'no history of diabetes' in an archetype with the explicit intent to record the absence of a diagnosis.
Specific absence of data needs to be recorded positively, where this is sensible:
Examples of global positive exclusion statements include:
Specific positive exclusion statements include:
Keep in mind that exclusion statements are only meaningful and relevant at the decision-making moment at which they are recorded. They have a fleeting temporal validity, and then the question has to be asked again – "Are you allergic to anything?"or "Have you ever had any serious illness or operations?".
Some examples:
So exclusions cannot be relied upon for any future decision-making. They are just 'in the moment' statements that need to be re-asked and regularly updated in records (both paper and electronic) as part of routine clinical practise.
So while they may be valuable, does that mean we desire to model every possible negative statement positively? This is certainly not desirable, nor is it helpful. A pragmatic approach is to research those situations where explicitly modelling exclusion statements provide some obvious value; preferably those that will have consistent re-use or may be utilised in knowledge-based activities such as Clinical Decision Support (CDS) systems.
Improved outcomes may result if CDS systems prompt for the recording a positive statement of:
Currently we have archetypes for recording the presence of an Adverse Reaction, a Problem/Diagnosis, Family History and Medicines. In addition we have a generic parent archetype for Exclusion (ie the positive absence) plus specialisations for Adverse Reaction, Medication, Family History and Problem/Diagnosis exclusions so far. The generic Exclusion archetype can be used as a standardised way to record the more uncommon statements – 'Not (currently) pregnant' might be a candidate here. But if there are regular use cases identified, these too may warrant their own explicit archetypes to ensure that positive absence is recorded consistently and safely.
'Severity' is a pretty simple clinical concept, isn't it?
I thought so too until I first sat down to create a single, re-usable archetype to represent 'Severity'. I soon discovered that I had significantly underestimated it - the challenge was greater than appeared at first glance.
The archetype development process is usually relatively straight forward - a brain dump of all related information into a mind map, followed by rearranging the mind map until sensible patterns emerge. They usually do, but not this time.
However, the more I investigated and researched, the more I could see that clinicians express severity in a variety of ways, sometimes mixing and 'munging' various concepts together in such a way that humans can easily make sense of it, but it is much harder to represent in a way that is both clinically sensible and computable.
The simple trio of 'Mild', 'Moderate' and 'Severe' is commonly used as a gradation to express the severity of a condition, injury or adverse event. Occasionally these are defined for a given condition or injury, however most often these are subjective and there should be concern that one clinician's mild might be another's moderate. Some also include intermediate terms, such as 'Mild-to-moderate' and 'Moderate-to-severe', but one has to begin to be concerned if these more subtle differences make the judgement even more unreliable, especially if we need to exchange information between systems.
Others add 'Trivial' – is this less than 'Mild'? By how much? Is there a true gradation here? And what of 'Extreme'? Still others add 'Life-threatening' and 'Death' – but are these really expressing severity? Or are they expressing clinical impact or even an outcome?
When exploring severity I found examples of severity expressed by clinicians in many ways. This list is by no means exhaustive:
In practice, clinicians can work interchangeably with any of these expressions and make reasonable clinical sense of it. The challenge when creating archetypes, and other computable models, is to ensure that clinicians can express what they need in a health record, exchange that information safely with other clinicians, allow for knowledge-based activities such as decision support.
In addition, there also needs to be a clear distinction between 'severity' and other, related qualifiers that provide additional context about 'seriousness' of the condition, injury or adverse reaction. These sometimes get thrown into the mix as well, including:
Clinical impact/significance might include:
Immediate clinical treatment required might include:
Outcomes might include:
Then there are those that recovered or the condition resolved but there were other sequelae such as congenital anomalies in an unborn child...
Severity ain't simple.
Over time, and repeatedly returning to it when modelling it in various archetypes including Adverse Reaction and Problem/Diagnosis, I've come to the conclusion that I don't think it is useful or helpful for us to model 'severity' in a single, re-usable archetype. It seems to work better as a single qualifier element within archetypes – then we can bind it in to terminology value sets that are useful for that specific archetype concept and for the use-case context.
When a clinical knowledge pattern is easily identified, creating an archetype is easy - the archetype almost writes itself! So over time I've learned not to try to force the modelling. Some archetypes 'work'; some, like this one, just don't.
With this blog I want to establish a simple baseline statement or overview about openEHR archetypes, aggregated from other posts and publications – a reference point if you like – from which we can journey further and in more detail into the issues around clinical modelling using specific archetypes.
Archetypes are a strong basis for data liquidity. Create the archetype once, agree through peer-review, re-use when and where required – the foundation for a 'universal health record'.
An archetype is a computable expression of a domain content model in the form of structured constraint statements, based on a reference (information) model. openEHR archetypes are based on the openEHR reference model. Archetypes are all expressed in the same formalism. In general, they are defined for wide re-use, however, they can be specialized to include local particularities. They can accommodate any number of natural languages and terminologies. [Archetype Definitions and Principles]
An archetype is a structured, computable specification for one single, discrete clinical concept. - much simpler!
Each archetype is a rich health data specification, defined and agreed by the clinicians themselves to ensure that each model is 'fit for clinical purpose'. Collectively these archetypes together can create an electronic health record 'lingua franca', or an example of PCAST report's 'Universal Exchange Language (although archetypes are not limited only to exchange of health information).
Archetypes can be used to model a range of clinical concepts:
Archetypes are:
Using archetypes requires:
Each archetype is designed:
Each archetype needs to represent the variety of data that is required to represent the information required for all aspects of clinical care and related activities, including:
Think about how the clinician may record the data: different clinicians will need differing approaches to recording their health information and the models need to allow for this clinical diversity. Some will prefer to use more free text and others more structure; some need more detail than others; we need to capture current requirements for recording and exchange while keeping in mind what might be best practice in the near and distant future.
The best designers, without a doubt, have a clinical background. I have seen clinicians and non-clinicians given identical clinical content, but the archetypes produces are surprisingly different. Clinician modellers definitely model their domain better than those who are not familiar with clinical practice. They are perhaps better able to envision the fractal nature of medicine and take that in to account in creating archetypes, especially the complex areas which require nesting of archetypes within each other to capture the depth and richness required in the models.
Integration with terminologies such as SNOMED, ICD or LOINC are strategic and important – the structure of an archetype is not enough to represent clinical information adequately, and similarly terminology alone is inadequate. However the combination of terminology within an archetype structure, by naming elements or provision of value sets, is semantically very powerful. There is still considerable work to be done to determine how to represent the information overlap – that which can be expressed either in the archetype structure itself or via terminology. This remains a 'grey zone' and is a pressing area for collaboration or research.
There are four main categories of archetypes that are useful to understand – each corresponding to classes in the openEHR Reference Model.
1. Compositions – which correspond to commonly used clinical documents, such as 'antenatal visit' or 'care plan'. 2. Sections – these are effectively used to assist with human navigation within EHRs and correspond to document headings, for example 'antenatal examination' or 'summary'.
3. Entries – these are the most common and are fundamental building blocks of EHRs. There are four main types of Entry archetypes:
4. Clusters
The Clinical Knowledge Manager (CKM) – www.openEHR.org/knowledge - is an international, online clinical knowledge repository under the auspice of the openEHR Foundation that provides:
Archetypes are freely available under a Creative Commons license.
The need for EHRs to be able to represent clinical diversity is absolutely underrated. Existing EHR systems corral clinicians into certain types of recording etc, but for safety we need more diverse ways for clinicians to record what they need for patient care, and also to ensure that what is exchanged is appropriate for the patient and their individual circumstances. A 'one size fits all' document approach to emergency summaries or messages can be potentially unsafe. Elderly, pregnancy, chronic disease, paediatrics are extremely common examples where there are specific additional requirements needed to summary data sets
Templates are computable specifications for a specific clinical scenario or use-case. The openEHR paradigm takes the governed and agreed archetypes from CKM and creates clinically useful specifications that can be implemented in systems by:
Examples include all clinical content required for a specific Message, Document, Clinical consultation or Report e.g. a histopathology report, a referral, an antenatal visit or a discharge summary.
In this way we can, in colloquial terms, 'have our cake and eat it too'. At the same time, CKM ensures tight clinical knowledge governance, yet templates allow for expression of clinician diversity.
Archetypes provide a 'glide path' to knowledge-level interoperability of health information. They can:
It was with great interest that I read about the the recommendation for a universal exchange language in the recent release of the US report to the President: REALIZING THE FULL POTENTIAL OF HEALTH INFORMATION TECHNOLOGY TO IMPROVE HEALTHCARE FOR AMERICANS: THE PATH FORWARD.
I had asked the Direct project about the existence of a national plan for standardising clinical content only recently... It appeared that here was a plan after all.
So, to the report. The approach and benefits proposed started well...
The best way to achieve a national health IT ecosystem is to ensure that all electronic health systems can exchange data in a universal exchange language. The systems themselves could be designed in any manner desired — they could accommodate legacy systems that prevail or new recordkeeping systems and formats. The only requirement would be that the systems be able to send and receive data in the universal exchange language. (p41)
I have previously blogged about a universal health record underpinned by an application independent library of clinical content definitions, so the intent and benefits are well aligned with my preferred approach.
But then alarm bells started to ring....
Because of its multiple advantages, we advocate a universal exchange mechanism for health IT that is based on tagged data elements in an extensible markup language. If there were another equally good solution, it should also be considered; we have collectively been unable to think of one. (p43)
Issue #1: Isn't it more appropriate for step one to identify the need for standardised clinical content as a policy, rather than specify the format up front? Isn't that really the domain of health informatics experts as part of a subsequent work plan? I feel like we've skipped a couple of steps in the decision-making process. And are they really advocating the creation of this metadata-tagged XML from a zero starting point?
Issue #2: The last 9 words of that paragraph, "...we have collectively been unable to think of one." I'm glad that they are still open to equally good solutions being considered as indeed there are many ways that individuals, groups and organisations are exploring how to standardise clinical content definitions as the basis for a universal exchange mechanism.
In ISO TC 215, the International Standards Organisations Technical Committee for Health Informatics, there is a new work item which has been evolving for at least 2 years, although yet to attain committee draft status, known as ISO 13972 - Quality criteria for detailed clinical models. This work item is targeting a new international standard for determining quality criteria about the development of detailed clinical models - all clinical models, pick your flavour! In the world of international standards it has been recognised for years that with the plethora of different approaches to developing clinical models for EHRs, there is a need for some criteria to support quality aspect in their development. This work is being led by modellers from the Netherlands, with experts participating from the Australian, Danish, German, Swedish, US and Canadian standards organisations. Creating clinical content is definitely not a new field of endeavour by the time it enters the international standards arena.
So, I am extremely surprised that this expert PCAST group have not been able to 'collectively think' of an existing alternative.
In my last blog - Clinical Knowledge Governance in a Web 2.0 world – I pointed to a number of approaches to standardised clinical content to support health information exchange.
1. In the US – including, but by no means limited to:
2. In Europe, and Australia:
In addition, a few more points...
Firstly, the focus of the PCAST report is still only on data exchange, not on ensuring a sound foundation of a person-centric electronic health record. I'll say it again... get the data right and then the data will be able to be re-used, to multitask, be liquid, flowing to where it needs to be. It will become the solid foundation on which to build lifelong health records, simpler health information exchange, data integration & aggregation, research, reporting and knowledge-based activities. By focusing on exchange alone, then... you'll hopefully be able to exchange well and the rest will be considerably more uncertain.
Secondly, the proposed variant of XML is described as a 'straightforward' and 'superior' solution (p44), and the assumption that it will be scalable, protected by encryption, and that data element access services will be enough to support the health information exchange required. By contrast HL7, ISO/CEN 13606 and openEHR have taken decades to develop and refine underlying reference models to ensure that they have an unambiguous, consistent, secure way to represent personal health information – so you know who created the data, who is the subject of care, what the data means, what are the access rules applicable etc. In the openEHR environment, the specification authors developed Archetype Definition Language (ADL) for the purpose - and now part of the ISO 13606 standard - because the alternatives such as standard XML were not robust enough to represent health information. A 'straightforward' XML approach has a strong possibility of failure without a RM underpinning it.
And finally, there is the area of clinical knowledge governance itself. Health is dynamic, complex and diverse. The work required to represent healthcare as computable clinical content definitions or specifications is huge – don't underestimate the sheer volume of work that will be required. It is not realistic to expect a 'rapid mapping' of existing proprietary data structures into tagged data elements. Who will decide the clinical content in the models? If there are over 7000 clinical vendors in the US, which will be 'the source' or sources? Which are 'correct' or 'authoritative'? What methodology will be used to create the models? What level of granularity for each clinical element? How will they be aggregated together to represent clinical documents or events, and constrained to be useful for the clinical purpose? I have a million more questions...
Once the information models are defined, there will be a need for them to be validated before they can become the basis for a standardised or national clinical content library – suitable for consumers, clinicians, organisations, vendors, researchers and jurisdictions. A requirement will be recognised for life-cycle management and publication of these models, roadmaps for legacy data to migrate towards, and harmonise with, the new national health information 'source of truth', plus ongoing maintenance and governance.
Eric Browne stated in his recent blog, Recasting e-Health in the USA:
The work in Sweden, the UK, Singapore and even Australia, based on openEHR or ISO 13606 archetypes (i.e. implementable renditions of Detailed Clinical Models) is far more advanced and promising than that offered by the PCAST approach.
openEHR, which is my interest, has an approach to defining, agreeing and governing clinical content models for electronic health records, known as archetypes. It has taken more than 18 years to develop the openEHR technical specifications, and the last 10 years to achieve its' current approach and position in terms of clinical modelling. It is gaining traction, albeit with a modest volunteer community, especially now that it has a collaborative portal, known as the Clinical Knowledge Manager, to support sharing or models, reviews of clinical content, translation and terminology binding, and model governance.
Standardising health information definitions for health records or exchange is not a trivial task. Learn from what has already been achieved – all shapes, flavours and doctrines. Whatever you do, don't reinvent the wheel and create yet another universal language!
My presentation given to W.H.O. in Geneva last week... [slideshare id=5492832&doc=20101008whoclinician-ledehealthrecords-101019133425-phpapp02]
Just askin'. Just curious...
What single eHealth activity, process or solution now available could:
...now there's a list that covers a broad range of eHealth, including may of our current, collective headaches, doesn't it!
The main thrust of the question is one that doesn't get asked very often, as it is orthogonal to our more common application- and messaging-driven approaches. It focuses on the most important part of any eHealth activities, yet it remains largely ignored - the quality and re-use of health information. Liquid data. Shareable data.
My opinion is that we need a clinical knowledge repository of common and agreed data definitions - that much should be clear from my other posts.
What other alternatives do you think can provide a solution in this knowledge space? How will we fill these needs?
In a world where connectivity is the universal aspiration, our health information is largely still caught up in silos and, in the main, is not accessible to those who need it – patients, clinicians, researchers, epidemiologists and planners. Shared electronic health records (EHRs) are increasingly needed to support the improvement of health outcomes by providing a timely, comprehensive and coordinated foundation for provision of healthcare. For decades people have been attempting to share health information, but the incremental approach has not been wholly successful – progress has been made, but despite enormous investment and resources, the solution has been found to be more difficult than most anticipated; many well-funded attempts have been stunningly unsuccessful. Healthcare provision appears not to fit the model that has been so successful in other domains such as banking or financial services. Why has sharing health information been so difficult? After all, on the surface, data are, simply, data.
Health information is the most multifaceted and largest knowledge domains to try to represent in a computer. The SNOMED CT terminology alone has over 450,000 terms expressing health-related concepts, and our collective knowledge about health is far broader, deeper and richer than that required to represent financial systems. The added bonus in health is that our information domain is dynamic - growing and changing as our understanding increases.
Recording, communicating and making sense of health information is something that clinicians do remarkably well in a localised, non-digital world. However the human cognitive processes and assumptions that underpin the traditional health records do not easily translate into the computerised environment. Consider the need for narrative versus structured data; the complexity of clinical statements; use of the same data in a variety of clinical contexts; the need for clinicians to make ‘normal’ or ‘nil significant’ statements, and also the oft underrated positive statements of absence; and the need for graphs, images or multimedia in a good health record. Grassroots clinicians have different personal preferences for creating their clinical records and to support their requirements for direct provision of clinical care and communication to colleagues. In parallel, jurisdictions have different expectations of the grassroots clinical data collection that will support reporting, data aggregation and secondary use of data.
Throw into this mix the complex and convoluted processes required to support healthcare provision; mobile patient populations; and the need for lifelong health records, and it starts to become easier to understand why eHealth has been more of a challenge that many first thought.
Traditional approaches to the development of EHRs have been software application-driven, hard-coding clinical knowledge into the proprietary data model for each software system and resulting in silos of health information locked away in proprietary databases. This is valuable data, and even more valuable if we can get access to it, exchange it and utilise it. Key stakeholders – patients, clinicians, researchers, planners and jurisdictions – are currently disempowered and are not easily able influence or express their data requirements. We have mistaken the software application for the electronic health record - a classic example of the ‘tail wagging the dog’.
If we focus on the electronic health record being the data, we turn the traditional paradigm upside down. Our EHRs become information-driven by putting the stakeholders at the centre to direct the information content and quality aspects of our EHR systems. It is only then that our systems will be able to reflect the real requirements of stakeholders, ensuring that health information collected data is ‘fit for use’ and will support personal health records, clinician health records and, with appropriate authorisation and permissions, the broadest range of secondary use.
Sharing health information requires common and coherent health information definitions or models – ensuring that health information can be expressed in a way that is meaningful to stakeholders AND that computers can process it. According to Walker et al , Level 4 interoperability, or ‘machine interpretable data’, comprises both structured messages and standardised content/coded data. In practice, it means that data can be transmitted and viewed by clinical systems without need for further interpretation or translation. This semantic, or knowledge-level, interoperability is absolutely required for truly shareable health records, data aggregation, knowledge-based activities such as clinical decision support, and to support comparative analysis of health data. Further, it is only when this health information model is agreed at a local, regional, national or international level, that true semantic interoperability can occur at each of these levels. The broader the level of clinical content model agreement, the broader the potential for semantic health information exchange.
openEHR is a purpose-built, open source, information-driven electronic health record architecture focused on ensuring that the grassroots health information is recorded clearly, coherently and unambiguously in EHRs, and supporting re-use in other contexts where appropriate. It adopts an orthogonal approach to EHRs - a dual-level modelling methodology with clear separation of the technical from the clinical domains, where software engineers focus on their application development and the clinical domain experts focus on the health information definitions. openEHR focuses on the data - using computable knowledge artefacts known as archetypes and templates to formally express health information.
openEHR archetypes are computable definitions created by the clinical domain experts for each single discrete clinical concept – a maximal (rather than minimum) data-set designed for all use-cases and all stakeholders. For example, one archetype can describe all data, methods and situations required to capture a blood sugar measurement from a glucometer at home, during a clinical consultation, or when having a glucose tolerance test or challenge at the laboratory. Other archetypes enable us to record the details about a diagnosis or to order a medication. Each archetype is built to a ‘design once, re-use over and over again’ principle and, most important, the archetype outputs are structured and fully computable representations of the health information. They can be linked to clinical terminologies such as SNOMED-CT, allowing clinicians to document the health information unambiguously to support direct patient care. The maximal data-set notion underpinning archetypes ensures that data conforming to an archetype can be re-used in all related use-cases – from direct provision of clinical care through to a range of secondary uses.
Templates are used in openEHR to aggregate all the archetypes that are required for a particular clinical scenario – for example a consultation or a report. These can also be shared, preventing more ‘wheel re-invention’. Individual content elements of each maximal archetype can be ‘disabled’ in the template so that the only data elements presented to the clinician are those that conform to national or local requirements and are relevant and appropriate for that use-case scenario. For example, a typical Discharge Summary may commonly comprise 10 common archetypes; templates allow the orthopaedic surgeon to express a slightly different ‘flavour’ of the Discharge Summary based on which elements of each archetype being either active or disabled, compared to that required by a Obstetrician who needs to share information about both mother and newborn. One ‘size’, or document, does not fit all. The archetypes, as building blocks, are the key to semantic interoperability; while templates allow flexible expression of the archetypes to fulfill use-case requirements.
How achievable is this? Only ten archetypes are needed to share core clinical information that could save a life in an emergency or provide the majority of content for a discharge summary or a referral. If each archetype takes an average of six review rounds to reach clinician consensus and each review round is open for 2 weeks, it is possible to obtain consensus within an average of three months per archetype – some complex or abstract ones may be longer; other simpler, more concrete archetypes will be shorter. Many archetypes are already well developed in the international arena and within national programs. As archetype reviews can be run in parallel, a willing community of clinicians could achieve consensus for core clinical EHR content within three to six months.
It is estimated that as few as fifty archetypes will comprise the core clinical content for a primary care EHR, and maybe only up to two thousand archetypes for a hospital EHR system including many clinical specialties. The initial core clinical content will be common to all clinical disciplines and can be re-used by other specialist colleges and interested groups. More specialised archetypes will gradually and progressively be added to enhance the core archetype pool over time.
The openEHR Clinical Knowledge Manager (CKM) is an online clinical knowledge management tool – www.openEHR.org/knowledge - which provides a repository for archetypes and other clinical knowledge artefacts, such as terminology subsets and document templates. Based on a data asset management platform it provides a clinical knowledge ecosystem supporting the publication lifecycle and governance of the archetypes. Within CKM, a community of grassroots clinicians and health informaticians collaborate in online reviews of each archetype until consensus is reached and the agreed archetype content is published. Clinicians and other domain experts need no technical knowledge to engage with archetypes - the technical aspects of archetypes are kept hidden ‘under the bonnet’ – but they use their expertise to ensure that the content definitions within each archetype is correct and appropriate. Each content review is conducted online at a time of convenience to the clinician and usually only takes five to ten minutes for each participant. Thus the clinical domain experts themselves drive the archetype content definitions, and CKM has become a peer-reviewed knowledge resource for all parties seeking shared, standardised and computable health information models.
At the time of writing CKM has acquired, largely by word of mouth, 565 registered users from 62 countries, including 181 people who have volunteered to review archetypes, and 73 who have volunteered to translate archetypes. The repository contains 273 archetypes, of which 15 have content that are in team review and 9 published. Two example templates have been uploaded, and we await final publication of the openEHR template specification before we expect to see template activity increase. Terminology subset functionality has been added only recently and our first terminology subsets uploaded. So, while CKM is still relatively new, its Web2.0 approach to artifact collaboration and publishing, combined with formal knowledge artifact governance positions CKM as a pioneering ‘one stop shop’ for clinical knowledge resources online.
Current CKM functionality includes:
A governed repository of shared and agreed archetypes will provide a ‘glide path’ towards full semantic interoperability of health information; a clear forward path for standardisation of data definitions. These will bootstrap new application or program development, provide a ‘road map’ to support gradual transition of existing systems to common data representation and provide the means to integrate valuable silos of legacy data.
A collaborative and domain expert-led approach to our health information provides many benefits which include the following.
Agreed and shared representations of the health information, embracing existing stakeholder requirements and developed rapidly by an active online community, will kick-start and accelerate many currently fragmented eHealth activities. Sharing archetypes as the definition of our health information will not only provide a common basis for recording and exchanging health information but also simplify data aggregation of data, support knowledge-based activities and comparative data analysis. Perhaps even more compelling, we are making certain that our domain experts warrant that the data within our EHRs, and flowing between stakeholders, is safe and 'fit for purpose'.
What do we have?
You can have all the messages, connect-a-thons and profiles that you like - certainly you will achieve short- to medium-term connectivity wins but it is not enough. It is not sustainable and clinicians want and need to share relevant data when it is needed. Predetermined messages and documents will be a great start, but it's not enough.
You can invest huge resources in terminology - we definitely need it - but terminology in isolation is also not enough.
You can demand all the 'damn data' that you want, but non-standardised data will still largely not be computable - largely limited to read-only access.
What do we want?
We hear talk about:
Essentially these phrases describe different aspects of the same 'elephant in the room'; just using different jargon...
We expect our healthcare professionals to be able to safely exchange important health information. To have the right health information available at the right place at the right time. To prevent us repeating our health histories ad nauseum. In fact a huge percentage of patients assume that we can already do this! But we can't... yet. Shared health records are not easy.
What do we need?
A single data-driven "universal health record", an uhr! And please note the deliberate lack of capitals.
What on earth is an uhr, I hear you quite reasonably ask...? A uhr is simply a non-proprietary pool of standardised health data which can be used for any purpose we want - PHR, EHR, EMR, SEHR, IEHR, research, epidemiology, reporting & stats, shared care, clinical decision support & more. There is no particular EHR application associated with it; in fact it works with any and every software program, vendor and healthcare provider.
The key (and I say it yet again)... it's. all. about. the. data.
In addition, and supported by:
As a result:
Gimme a universal health record. Gimme my damn, um,... uhr, and let my data flow...
And so, I archetype;-)
I wrote this overview of openEHR way back in 2007, and it was published in PulseIT (Sydney, Australia) [Internet], pp50-55, Issue 6, November 2007.
The online publisher has removed access to it, so I've posted it here.
The principles remain unchanged. I've updated some links, and indicated some minor parts that are a little out-of-date. My previous posts, What on earth is openEHR & Connect with openEHR provide up-to-date stats and links.
In a world where connectivity reigns, our health information is largely still caught up in silos and, in the main, is not shareable by clinicians. Shared electronic health records (SEHRs) are increasingly needed to provide timely, comprehensive and coordinated healthcare. Over many years there have been ongoing and thorough attempts to achieve the sharing of health information in order to support the improvement of health outcomes, but this incremental approach, gradually building on previous experience, has not been wholly successful. Progress has been made, but despite enormous investment and resources, the solution has been more difficult than most ever anticipated. Healthcare provision does not seem to fit into the same kind of data sharing model as has been successful in other domains such as banking or financial services.
In order to support interoperability of health information SEHRs need clinical content to be standardised. This assists the move to standardised communication of complex health information between systems and the opening of these vertical domain and organisational silos, allowing accurate and semantically computable health information flow. Inevitably the shared clinical content specifications begin to influence the information models within clinical applications. openEHR is an electronic health record architecture based on many years of research and development, and designed to work in partnership with all vendor systems, organisations and providers to facilitate semantic interoperability of health information. It is a comprehensive and transformational solution which applies to the capturing and sharing of information from the most complex and dynamic knowledge domain – health.
Why are Health Records so difficult?
The interoperability of health information problem is twofold – firstly, the evolving clinical needs and requirements for a SEHR are difficult to pin down, and secondly the technical issues related to a SEHR solution.
Why are clinical requirements so difficult to capture and transform into an electronic health record (EHR)? Certainly no-one will argue that our experience of healthcare delivery is changing – hospital in the home projects; supported self-management; patient requests for access to GP and hospital clinical records; personal health records; service coordination; clinical care plans; preventive health priorities... The list goes on, mirroring the rapidly evolving change in clinical EHR requirements needed to support these new paradigms of healthcare delivery. These new ways of delivering care require a coordinated approach – healthcare providers need to collaborate efficiently in real time, which is not adequately supported by traditional methods such as meetings and phone calls. We really need an interoperable and integrated patient record in which all healthcare providers can participate, within a framework providing governance, authorisation and security measures.
Clinical knowledge domain is very complex and dynamic, so any clinical system created using traditional software development methods (embedding the clinical knowledge directly into proprietary application code and databases) has an uphill battle to deal with the changes. Considering the time it takes for a clinical application to be developed, it may already be out-of-date at its launch! The inherent difficulties in updating knowledge structures that are hard-coded into the application and database inevitably lead to a gradual deterioration of the integrity of the system.
Clinical decision support is another difficult area – there is a lot of discussion about it, but there is very little real computerised decision support happening in practice. Certainly, each clinical system has some that is custom built – usually limited to allergy and drug interaction alerts and a reminder system – but there has been very little general progress in this area. Why is clinical decision support (CDS) still largely found only in the academic domain and not implemented in production clinical systems? We already have clinical guidelines and other resources which are approved and used in paper formats – why are they not integrated in our clinical desktop applications? The answer is multi-factorial. Things that have blocked progress include ownership and sharing of intellectual property, licensing problems etc, but the main issue is to do with practical implementation and cost. An approved guideline can be transformed into some proprietary computable format, but then it has to be able to integrate into every other clinical system – lots of interfaces have to be built, paid for and maintained. This is a nightmare. Another approach is for each system developer to take a guideline and integrate it into their system as best they can. This introduces variability and the potential for significant quality and liability issues to arise.
Silos of proprietary information cannot talk to each other without mappings and necessary assumptions. Such transformations inevitably compromise the quality and integrity of the information being shared, thus creating more threats to patient safety. It is only through use of a common logical clinical content model reflected in our EHRs and CDS systems that the guidelines can be created once according to this agreed model and can be integrated meaningfully and accurately with the clinical information systems to give us quality clinical decision support at the point of care.
From a technical point of view, the current reality around the world is that the majority of vendors are competing to build the greatest and ‘best of breed’ clinical software applications, but all are doing it in their own proprietary way. The software may have a rich functionality and a great user interface. It may do a great job in the clinic, hospital or network on which it is installed, but how does it share clinical data? Some software applications may be able to share with the same system in another geographical location because they share a common data structure, but cannot easily share with the system of another vendor.
Current clinical applications can usually send or receive point-to-point messages using a format which is known and agreed, and based on a standard such as the Health Level 7 (HL7) version 2. The software may also incorporate a terminology to assist in capturing and storing common clinical concepts. However, there is a common misconception that if we simply have a messaging standard paired with a terminology, then we have ‘achieved interoperability’.
A New Paradigm for Electronic Health Records
Most of us mistake the software program for the electronic health record; in fact in the USA the word EHR means a clinical application. The openEHR approach asserts that it is not the application, but rather the data, or health information, which makes up the health record. And further, that it is a common and agreed structure of that data is what makes the electronic health record of any use for computing in health.
In order for two clinical systems to be able to share health data unambiguously, such that clinicians can read it and the computer can compute with it, more is required. This semantic, or knowledge-level, interoperability, based on a common and coherent clinical model, is an absolute requirement for truly shareable EHRs and valuable complementary functionality such as clinical decision support and workflow/care planning. Further, it is only when this clinical content structure is agreed at a local, regional, national or international level, that true semantic interoperability can occur at each of these levels. The broader the level of clinical content model agreement, the broader the potential for semantic health information exchange. While an increasing number of health informatics experts agree on this view of the problem, incremental work towards EHR standards based on messaging paradigms, such as HL7 v3, have only had limited degrees of success. At an international level, there is increasing concern that this incremental approach to SEHRs may not be able to solve the issues of semantically interoperable EHRs. Remember that Einstein argued: “We can't solve problems by using the same kind of thinking we used when we created them.”
We need semantic interoperability for our SEHRs and in order to achieve this we need a transformational change. We need to use a different paradigm. The openEHR paradigm has been collaboratively developed, reviewed and refined to realise a collective vision of a high quality, internationally interoperable EHR.
What is semantic interoperability?
Let’s be clear about what semantic interoperability means. According to Walker et al[1], Level 4 interoperability, or ‘machine interpretable data’, comprises both structured messages and standardised content/coded data. In practice, it means that data can be transmitted and viewed by clinical systems without need for further interpretation or translation. This is a basic foundation for a truly shareable EHR and for functionality such as clinical decision support.
For clarity, existing HL7 v2 messages probably fit into Level 3 of Walker’s conceptual framework – ‘Machine organisable data’ which comprises structured messages but unstructured content. According to Walker, a level 3 message “requires interfaces that can translate incoming data from the sending organization’s vocabulary to the receiving organization’s vocabulary; usually results in imperfect translations because of vocabularies’ incompatible levels of detail.” We cannot directly compute on a Level 3 message – it requires interpretation or transformation before the computer can use it. HL7 v3 goes a step further with an underlying semantic model. The problem has been that using this in systems has proved very difficult. The HL7 CDA, chosen by Nehta for communication in Australia, bypasses some of the difficulties by at least enabling us to share documents that we can read. More is needed to achieve semantic interoperability.
What is openEHR?
openEHR[2] is a set of open specifications for an Electronic Health Record (EHR) architecture – but it is not a software application. Its design purpose is to enable semantic interoperability of health information between, and within, EHR systems – all in a non-proprietary format, avoiding vendor lock-in of data.
All clinical knowledge concepts are captured in a structured way - known as archetypes – outside the software. The types of archetypes support the recording required for common clinical activities, with some of the key building block archetypes comprising observations, evaluations, instructions and actions. Data built according to these are stored in an EHR in larger ‘composition’ structures, which have their own archetypes. Compositions are comparable to a document that results from a clinical event which is performed e.g. a consultation record or a discharge summary. Archetypes can be simple, such as temperature, blood pressure or diagnosis, or complex, such as capturing the risk to a fetus if the father has a grandmother with Huntingdon’s chorea. The archetypes contain a maximum data set about each clinical concept, including attendant data required such as: protocol, or method of measurement; related events; and context that is required for the clinical data to be interpreted accurately. The creation of archetypes and templates is almost purely a task for clinicians – openEHR archetypes put clinicians in the driver’s seat, enabling them to create the breadth, depth and complexity of the health record to suit their needs for direct healthcare provision.
Aggregations of archetypes are combined in openEHR ‘templates’ in order to capture the data-set corresponding to a particular clinical task, such as an ICU discharge summary or antenatal visit record. When clinicians look at templates, the information contained within them inherently makes sense and doesn’t require significant training for interested clinicians to be able to create templates for their own purposes – be it domain, organisation or purpose specific. Templates can be used to build generic forms to represent the approximate layout of the EHR in a practical sense, and these can be used by vendors to contribute to their user interface development.
Both archetypes and templates can be linked to terminologies or contextually appropriate terminology subsets that will support appropriate term selection by healthcare providers at the point of data entry.
openEHR is rapidly gaining international momentum, supported by evidence from current high profile implementations of the openEHR specifications such as in the UK NHS Connecting for Health program.
Who is openEHR?
The openEHR Foundation owns the intellectual property of the openEHR architecture specifications. The Foundation is a not-for-profit company, with the founding partners being University College London (CHIME department) and Australian company, Ocean Informatics. The specifications are the result of over 15 years of research and international implementations, including the Good European Health Record (GEHR), and the collaboration of an international community of people who share a common goal – that of the realisation of clinically comprehensive and interoperable electronic health records to support seamless and high quality patient care.
The registered online community has over 1000 members from 75 countries with many actively participating in debate and contributing to ongoing openEHR development from both technical and clinical perspectives.
What is openEHR used for?
openEHR is a specification for secure, shareable health information and provides a foundation on which to build interoperable, modular software applications. These, in turn, can support distributed clinical workflow, such as care plans.
The openEHR specification can be implemented in a number of ways:
- Scalable EHRs – from Personal Health Records to small/medium/large organisations to regional or state clinical record systems and on through to National e-Health programs;
- Message-based, web-service, middleware applications; and
- Integrating existing clinical systems, including virtual federation of data for research or public health purposes.
However, while it has much in the way of additional functionality, it is important not to lose sight of openEHR’s raison d'être – semantic interoperability, or more simply, a truly shareable Electronic Health Record.
How is openEHR different?
There are many aspects of openEHR which clearly differentiate it from other EHR models:
- Open source initiative The openEHR specifications are freely available under an open licence.
- Separation of the technical and clinical domains The openEHR design is markedly different to traditional EHR development - it is a 2 level information model. These 2 levels allow a clear separation of the technical reference (i.e. data) model on which software is based from the clinical knowledge itself. The appeal of this new design is that the technical components of the EHR can be kept quite separate from the dynamic clinical knowledge model. In practice, the technicians manage just the technical aspects, while the clinicians are critical in the development of the clinical archetypes and templates that shape the nature of their EHR.
- Purpose-built EHR The design of the reference and archetype models support many unique openEHR features required for robust clinical record keeping, clinical business process and medico-legal compliance, such as: distributed versioning and merging of EHR records, including audit trails; a strong history and event model for complex observational information; and archetype-driven semantic querying. openEHR designs supports configurable security, anonymous EHRs, fine-grained standards-based privacy, digital signing, and access auditing.
- Knowledge-enabled – capturing the dynamic and complex nature of health information Clinicians are able to contribute actively and directly to the development of the clinical knowledge models that underpin their EHRs. Archetypes can be revised and versioned to reflect the rapid and varied changes in health domain knowledge.
- Terminology agnostic openEHR connects flexibly to any or all terminologies through either archetypes or templates. Terminologies such as SNOMED-CT are leveraged when used alongside archetypes, with the archetype clinical model providing context to minimise the need for post-coordination and complexity. Archetypes and terminologies are not competitive but rather complement each other.
- Semantic querying Archetypes, in combination with terminologies enable powerful possibilities for semantic querying of repository data – whether for individual usage or for population research. Archetype-based querying enables true longitudinal processing of health data, regardless of the originating system.
- Language independent There is no language primacy in archetypes; they can begin in any language and be translated to multiple other languages. Translation enables the same archetype to be used in different countries, with data created in one language to be interoperable with systems developed and used in other languages. Archetypes are currently available in English, German, Turkish, Dutch, Swedish, Farsi, Spanish and Portuguese.
- Sustainable reference model – life-long EHRs The openEHR reference model has been rigorously engineered over the past 15+ years as the foundation for a comprehensive health computing platform. It consists only of generic data types, structures and a small number of generic patterns, resulting in a small, stable and sustainable information model for IT people to maintain. This approach allows a clinical data repository to act as a future-proof data store, totally independent of software applications and technology change. In practice this means that no software application changes, or redeployment, are required when new or revised archetypes are published to reflect changing clinical knowledge. As a result, life-long, application-independent health records are possible for the first time.
- Ease of implementation openEHR is comparatively easy to implement:
- there is little infrastructure required;
- the software required is small, due to being based on a compact and stable, object-oriented reference model; and
- the clinical models (Archetypes) can be developed separately from the software application.
- Ongoing development and enhancement Based on feedback from its international collaborators, openEHR is undergoing continuing development, with ongoing maintenance and releases of specifications and software.
- Governance of shared content Archetypes are created once, and if broadly agreed upon, they can become the basis of consistent sharing of data content between systems, providers and even other countries. While archetypes can be designed and used by a given solo practitioner/researcher or locally within an organisation, the power of archetypes becomes more evident the more broadly they are shared. All systems that use the same archetype – even across country borders and terminologies – will be able to interoperate. The openEHR Foundation is in the process of developing an ontologically based international, open source archetype and template repository[3]. This is being supported by a governance framework which will facilitate archetypes to be submitted for international clinical review, and publication. It comprises a complete archetype and template lifecycle and version management repository and supporting processes to allow countries, regions, organisations or vendors to freely download and utilise these commonly agreed archetypes in their clinical systems. Archetype libraries can also be set up at other levels, as needed – domain, organisational, regional, or national.
- A collaborative model of development rather than a standards-based path The openEHR development to date has been the result of an interested and motivated volunteers from a broad international community of clinicians and software engineers. Formal and rigorous processes have underpinned its progress and both Architectural and Clinical Review Boards, comprising world experts in their fields, have had oversight of the overarching strategy, process and governance. Standards are not rejected in the openEHR approach; they are just not a part of the development process. In comparison to a traditional standards-based approach, openEHR development has been relatively rapid and pragmatic, rather than being held back by the slower process of ‘design by committee’. In fact, the recent European CEN standard for EHR extracts (EN13606) has been based on an earlier version of, and a subset of, openEHR. In addition, openEHR’s Archetype Definition Language (ADL), has recently been accepted as an International Standards Organisation (ISO) committee draft, for consideration as a standard.
Where is openEHR being used? [as at October, 2007]
openEHR is being used in both active research and commercial activities. [4] Research on openEHR is being conducted in Sweden, Australia, United Kingdom, USA, Sri Lanka and Spain. Commercial development is occurring in Australia, United Kingdom’s NHS Connecting for Health, Netherlands, Belgium, Sweden, Turkey and the USA.
The United Kingdom’s National Health Service (NHS) Connecting for Health program has just commenced a formal clinical modelling program using openEHR archetypes and templates to provide a common and agreed clinical content on which to base its clinical applications. In a pilot early in 2007, content developed for NHS Maternity and Emergency domains were provided to vendors for implementation in new clinical application development.[5] These archetypes are available in the public domain, and have undergone broad internal review by expert clinicians prior to being approved for NHS usage. The Emergency templates developed reflect the top 10 presentations to an Emergency Department – including chest pain, shortness of breath and collapse. The Maternity templates followed the clinical journey of a pregnant woman – from a pre-pregnancy consultation and antenatal visits, through to capturing the labour and delivery record, including Partogram data. Each template is made up of a variable number of archetypes – ranging from a few simple templates containing only 2 or 3 archetypes through to complex templates containing up to 80 discrete clinical concepts.
Current openEHR status and supporting tools [as at October, 2007]
- openEHR Specification The latest openEHR Specification (Release 1.0.1) was published on 15 April 2007.
- Clinical Content Development of archetypes and templates has gained significant momentum in the past 12 months:
- Archetypes As a result of initial Australian modelling work and, more recently, within the UK NHS, there are now approximately 250 archetypes.
- Templates Over forty distinct templates representing clinical needs in Emergency and Maternity were developed over a short time period in March/April 2007.
- Commercial Tools Currently there are a number of commercial tools supporting the open source openEHR implementation. The major tools to date are developed in .Net and Java. Australia’s Ocean Informatics[6] has developed a suite of products supporting openEHR implementation in .Net, while Sweden’s Linkoping University have developed an Archetype Editor in Java and Cambio Healthcare Systems[7] have an early Java kernel.
The Ocean .Net products include:
- Clinical Knowledge Suite:
Archetype Editor (open source) and Template Designer, including semi-automated screen form construction based on templates;
- Terminology Toolset – including a caching terminology server and subsetting tool, incorporating SNOMED-CT in the first instance; and
- Archetype-powered Query Designer
- OceanEHR platform – including a universal data repository, demographic service binding, generic EHR Viewer; and data integration & transformation services.
- Archetype/Template Library Service as an online template and archetype repository
Get involved with openEHR
Membership of the openEHR community is free and open to everyone via the openEHR website[8]. It assumes a commitment to a common vision for high quality, interoperable EHRs, and a willingness to share ideas and experience. All levels of interest and contribution are welcome – from novice to expert. The lists range from discussion on technical, clinical and implementer mailing lists through active development of archetypes, templates and tools, to review and critique of clinical content models and technical specifications. Whether you are a clinician, patient advocate, vendor or provider of health care you have a role in the development of what is becoming known as 'the world's record'.
[1] Walker J, Pan E, Johnston D, Adler-Milstein J, Bates DW, Middleton B. The Value of Health Care Information Exchange and Interoperability. Health Affairs 2005 Jan 19 - http://content.healthaffairs.org/cgi/content/abstract/hlthaff.w5.10v1 [2] For more details, see www.openEHR.org [3] For more details, see www.archetypes.com.au [UPDATE 2010: Clinical Knowledge Manager - www.openEHR.org/knowledge] [4] For more details, see www.openehr.org/projects/t_projects.htm [UPDATE 2010: http://www.openehr.org/projects/eiffel.html] [5] For more details of the NHS clinical modeling work, see www.ehr.chime.ucl.ac.uk/display/nhsmodels/Home [6] For more details, see www.oceaninformatics.com [7] For more details, see www.cambio.se/zino.aspx?lan=en-us [8] www.openehr.org
We clinicians expect a lot from our electronic health records (EHR), & so we should.
Yet I am surprised at how remarkably passive we, as a group, are about the structure & quality of the data that underpins it.
Most of us don't know - we just don't tend to look 'under the bonnet'.
Yet we are undeniably clinical domain experts. We also understand what information we need for providing patient care & our research. What if our systems don't capture what we need or in the optimal way for us to use?
We need to ensure that all our efforts to conscientiously enter good patient data is reflected in the underlying data structure - that our clinical data is 'fit for purpose'.
It is important to understand & acknowledge that there are many ways to represent the same data, and not all are equivalent! We need those trained as both clinicians & informaticians to be intimately involved in developing high quality eHealth tools. Clinician informaticians provide the critical link between our software engineers & our grassroots clinician experts.
Have you ever considered how the data in our systems is designed? What is the process? What is the criteria for 'quality'?
I have seen many examples of clinical information requirements that have been gathered 'with extensive stakeholder engagement'. OK, but when you enquire who gathered the requirements it is not always (& sadly, most often not) a clinician informatician who has asked the questions. I have to ask the question. If you are not a clinician & don't understand how health data is going to be used (content, processes, reference models, querying, use of terminologies etc), how can you ask a reference group the right questions in the first place & ensure that you have the right answers? The chances of the reference group consisting of clinician informaticians to spoon feed you the right information is pretty slim. So by my reckoning there may be a significant risk of 'the blind leading the blind' syndrome occurring in this not uncommon scenario. Learning point: Always question the credentials of the initial data requirements!
On a number of occasions I have been shown some data requirements for core archetype modeling - problem/diagnosis, adverse reactions, medication orders & the like. It is frequently clear they have been developed by a technical analyst with very little clinician informatician input. Turning these requirements into an archetype is not an issue, however I have concerns that my 'fit for clinical use' criteria will not be met. They might be perfect for reporting back to government, but for clinical care, decision support, research, sharing etc... maybe not so good, yet they are being created for use in desktop clinical EHRs.
Interestingly in openEHR training sessions I have supplied a set of clinical requirements for an archetype to participants, encouraging them to break into mixed teams of both clinicians & technicians to try their hand at collectively building their first archetype. Not so surprisingly, they most often split into clearly demarcated technical & clinical groups - no cross-pollination at all;-). Despite being presented with the same requirements, inevitably both groups tend to represent the data quite differently - clinicians intuitively represent it the way they know it & need it; the technicians making a best guess based on their incidental domain knowledge.
When I train people in how to build archetypes, I always state that the best archetypes - by that I mean 'fit for purpose' - are those built by clinician informaticians. Next best are those built in close collaboration with clinician experts, preferably staring over their shoulder & offering feedback in real time! Lastly, those built by technical modelers with little or no direct domain understanding. (Unfortunately, by far the most modelers that are in the employ of our national eHealth programs & large vendors are in the latter category.)
I have seen surprisingly bad archetyping efforts by very proficient technical modelers, largely just because they don't understand the clinical context. In most instances, a spreadsheet or UML diagram of requirements just isn't enough. On many occasions over the past few years I have found that their idea of a clinical concept is often quite different to that of a clinician - not unexpected really!
My conclusion - clinical experience matters!
Health informaticians are few on the ground. Clinician informaticians are even fewer. We need a transformational approach to EHR development - working smarter & more efficiently. Clinician informaticians are critical to ensure the development of shareable, 'fit for purpose' clinical content specifications as a solid foundation for good quality health data, both within & for sharing between systems.
Is the tail wagging the dog? Should vendors decide what clinicians need? OR should the professional clinical colleges be driving the EHRs that members need to provide quality healthcare to their patients? From a quality point of view, one could strongly suggest that colleges should be the experts driving this new paradigm of clinical care. As a group, professional clinical colleges as a group usually state that one of their major roles is in establishing and driving the benchmarks for acceptable clinical practice standards in their field of expertise. Most do this very well in the traditional areas of clinical practice.
Scouring the web it is possible to see that some are engaging actively in eHealth. For example, from the website of The Council of the Royal College of Physicians in UK, a vision statement published in January 2010 incorporates this final paragraph:
"Effective implementation of standardised, structured, patient focused records requires strongly led culture change, embraced by all medical and clinical staff. They are essential prerequisites for safe, high quality care and for the safe, efficient and effective migration from paper to electronic patient records. Such records will also enable innovative development of services that cross traditional boundaries and, by giving patients access to their record, empower them to take more responsibility for their own care."
If colleges have had a traditional role in ensuring safe, high quality care, then the advent of electronic health information should logically trigger a natural extension of their pre-existing work and roles into the eHealth arena. I would go further and suggest that they should also be actively driving an eHealth agenda that reflects their college remit regarding provision of quality care and standards; ensuring that the data created, stored, shared and queried is good and fit for use in clinical care.
This agenda may, or may not, be aligned with the activities of national eHealth programs. As we look at the news in recent weeks it is becoming apparent that many are struggling with implementation of top-down agendas. We have seen major changes in the national approach to eHealth happening in Netherlands, Germany, and England's NHS. Perhaps it is time for a grassroots, bottom-up approach from the end-users, the healthcare providers, and their patients, the healthcare consumers.
How can colleges drive eHealth?
Colleges may bundle these new standards-based eHealth activities within existing service provision to, or activities involving, their members.
In addition, commercially savvy colleges could develop ways to develop and sell practical solutions or packages around these quality principles direct to members – products or programs to make it easy for members to put the evidence-based and quality principles into practice.
Herein lies a challenge for contemporary professional clinical colleges – to both embrace eHealth and to actively drive it in a way that promotes and preserves safety, quality and best practice in healthcare, such that eHealth becomes a positive tool for healthcare provision and, possibly even, reform.
And how to do this in practice? Well, it is no secret that I think openEHR can offer a solution to a lot of these issues - see my previous posts 'What on earth is openEHR' and 'Connect with openEHR'.
Time will tell if I'm on the right track. For me as a clinician, the more time I spend with it, the more compelling this openEHR story becomes...
My experience in eHealth started as a suburban General Practitioner using an EHR application for prescribing and clinical notes, and then I moved sideways, becoming involved in building proprietary clinical software and a Personal Health Record. From 2000 I worked for 4 years in a single company that owned that PHR plus a primary care clinical application and a hospital application - the intent being that data created in one could be transferred between the systems, but we found it wasn't that easy - for various reasons they all had different database structures, even within the same vendor! So if we have to do the same thing between disparate vendors in an environment that is more competitive than collaborative, the picture becomes infinitely more complicated.
In more recent years, I have had my world view shifted from the traditional application-drive EHR to a data driven health record (note the deliberate lack of capitalization) - see my previous blog posts. Once we focus on getting the data right, capturing it or displaying it in the applications are just one of the many things we can do with the data.
Why? I first heard about openEHR nearly 10 years ago. I didn't understand openEHR at all initially, but there was something in the commonsense of getting the foundation data defined and standardized that resonated with me. Over time I have become convinced that openEHR provides an orthogonal approach to eHealth that has a very reasonable chance of success, and more importantly, of making a difference. I no longer believe that the traditional application-driven approach to electronic health information management is effective, economic or sustainable.
What is openEHR?Think of openEHR as the open source health equivalent of the iPod/iPhone platform – a technical framework which will allow any compatible application, organization or provider to share 'plug and play' access to standardized data. This is openEHR’s innovation – the focus on ensuring that the underlying health data is correct, robust and trustworthy!
Rich health data definitions known as archetypes, are defined and agreed by the clinicians themselves to ensure that each piece of health information is unambiguously understood, ‘fit for purpose’ and can be dynamically used & reused to support wise and safe health choices, now and into the future. These same archetypes are also computable, so that when these common data definitions are shared, they act as a 'lingua franca', making it much simpler to capture, store, aggregate, query and exchange health information - effectively making the data 'sing and dance' and to flow according to privacy and access rules.
Developed over more than 15 years through international research, community input and implementations, openEHR is purpose-designed as a non-proprietary universal health record: application independent, yet supporting accurate and safe health information exchange between software programs, consumers, health care providers, organisations and researchers; and across the diverse requirements of private/public providers and regional, national and international jurisdictions.
International momentum is building - current users noted on the openEHR website include commercial, government, academic, and non-profit organisations.
___________________
Current eHealth developments are progressing at a glacially slow rate because we are trying to develop interoperability by traditional and incremental methods. I'm increasingly sceptical that this is effective, economic or sustainable. And in fact, though direct experience I have become convinced that openEHR's orthogonal approach can make a significant difference. I now work with openEHR every day, including:
I'm not trying to sell you a software application like everyone else claiming an 'eHealth solution'; I'm trying to persuade you to take a look at an alternative approach to eHealth, to share a little of my vision and my passion!
Consider becoming part of an international open source community. Contribute and collaborate alongside other clinicians, informaticians and techies to build something bigger than all of us. Share a vision of how eHealth could work better and more effectively if we get the foundations for a universal health record consistent and solid.
It. is. all. about. standardizing. the. data.
