Know your data?

Recently I was reminded of some work we did a number of years ago. It involved a large research database, painstakingly collected over 20 years. The data was defined across a number of specialisations within a single clinical domain and represented in 83 data dictionaries stored in an Excel spreadsheet.

Data was collected based on a series of questionnaires, and we were told that successive data custodians had, true to human nature, made slight tweaks and updates to the questionnaires on multiple occasions. The data collected was actually evolving!

The only way to view the data was to open each of the 83 spreadsheets, painstakingly, one by one.

We were engaged to create archetypes to represent both the legacy data and the data that the research organisation wished to standardise to take forward.

So the activity of converting these data dictionaries - firstly to archetypes for each clinical concept, and then representing each data dictionary as a template - resulting in considerable insight into the quality and scope of the data that hadn't been available previously.

For example, the mind map below is an aggregation of the various ways that questions were asked about the topic of smoking.

Interestingly, what it showed was that no one individual in the organisation had full oversight of the detailed data in all of the data dictionaries.The development of the archetypes effectively provided a cross section of the data focusing on commonality at a clinical concept level and revealed insights into the whole data collection that was a major surprise to the research organisation. It triggered an internal review and major revision of their data.

Some of the issues apparent in this mind map are:

• A number of questions have been asked in slightly different ways, but with slight semantic variation, thus creating the old 'apples' vs 'pears' problem when all we wanted was a basket of apples;
• Often the data is abstracted and recorded in categories, rather than recording the actual, valuable raw data which could be used for multiple purposes, not just he purpose of the rigid categories;
• Some questions have 'munged' two questions together with a single True/False answer, resulting in somewhat ambiguous data; and
• Some questions are based on fixed intervals of time.

No doubt you will see other issues or have more variations of your own you could share in your systems.

And we have repeatedly seen a number of our clients undergo this same process, where archetypes help to reveal issues with enormously valuable data that had previously been obscured by spreadsheets and the like. The creation of archetypes and re-use of archetypes as consistent patterns for clinical content has an enormous positive impact on the quality of data that is subsequently collected.

And while harmonisation and pattern re-use within one organisation or project can be hard enough, standardisation between organisations or regions or national programs or even internationally has further challenges. It may take a while to achieve broader harmonisation but the benefits of interoperability will be palpable when we get there.

In the meantime the archetypes are a great way to trigger the necessary conversations between the clinicians, domain experts, organisations, vendors and other interested parties - getting a handle on our data is a human issue that needs dialogue and collaboration to solve.

Archetypes are a great way to get a handle on our data.

Technical/Wire...Human/Content

In a comment on one of my most recent posts, Lloyd McKenzie, one of the main authors of the new HL7 FHIR standard made a comment which I think is important in the discourse about whether openEHR archetypes could be utilised within FHIR resources. To ensure it does not remain buried in the rather lengthy comments, I've posted my reply here, with my emphasis added.

Hi Lloyd,

This is where we fundamentally differ: You said: "And we don’t care if the data being shared reflects best practice, worst practice or anything in between."

I do. I care a lot.

High quality EHR data content is a key component of interoperability that has NEVER been solved. It is predominantly a human issue, not a technical one - success will only be achieved with heaps of human interaction and collaboration. With the openEHR methodology we are making some inroads into solving it. But even if archetypes are not the final solution, the models that are publicly available are freely available for others to leverage towards 'the ultimate solution'.

Conversely, I don't particularly care what wire format is used to exchange the data. FHIR is the latest of a number of health data exchange mechanisms that have been developed. Hopefully it will be one that is easier to use, more widely implemented and will contribute significantly to improve health data exchange. But ultimately data exchange is a largely technical issue, needs a technical solution and is relatively easy to solve by comparison.

I'm not trying to solve the same problem you are. I have different focus. But I do think that FHIR (and including HL7 more broadly) working together with the openEHR approach to clinical modelling/EHRs could be a pretty powerful combo, if we choose to.

Heather

We need both - quality EHR content AND an excellent technical exchange format. And EHR platforms, CDRs, registries etc. With common clinical archetypes defining the patterns in all of these uses, data can potentially start to flow... and not be blocked and potentially degraded by the current need for transforms, mappings, etc.

To HIMSS12... or bust!

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:

• record and exchange health information;
• simplify aggregation of data and comparative analysis; and
• support knowledge-based activities.

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:

• The usual on-site marketing approach:
  • a booth - 13342
  • company and product-related material on the HIMSS Online Buyers Guide; and
  • marketing material – we have some plans for a simple flyer, with a mildly Australian flavour;
• Leverage our website, of course;
• Developing a Twitter plan for @oceaninfo specifically with activity in my @omowizard account to support it, and anticipating for some support from @openEHR – this will be a new strategy for me;
• And I’m working on development of a vaguely ‘secret weapon’ – well, hopefully my idea will add a little ‘viral’ something to the mix.

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?

Why the buzz about CIMI?

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 DCM environment - a crowdsourcing initiative

There are a number of detailed clinical models available to choose from, from diverse backgrounds, for many differing purposes and with varying degrees of success and penetration. More are arriving on the scene as time goes on – only this week the Clinical Information Models from ONC in the US have been released for their first 2 week period of public comment, and I'd never heard of them before. I haven’t been able to find a single document pointing to an overview on available models – current or past. So, given the current activity development of a quality standard around detailed clinical models in ISO TC 215 and the number of models under development, I thought it timely to try to co-ordinate sourcing a picture of the detailed clinical model landscape.

Well aware that my understanding is limited to the openEHR archetypes I work with, I thought I’d take this opportunity to draw together some of my research and request some assistance from others to crowdsource a picture of the detailed clinical model environment that we operate within.

I have published my initial attempt as a Google doc, see below. The existing information needs to be verified; there are clearly many gaps that need to be filled in; and there are probably other DCMs to be added.

EDIT the DCM environment document...

Anyone can participate, and if you edit, please add your name/org/email to the Contributor list, so that attribution can be made.

Please feel free to edit; to add new DCMs; to correct and verify the facts. Add a column, suggest changes to structure where you see a need... Just make a comment, if you like.

You can clearly see all the gaps in our collective knowledge at present…

Let’s see if we can actually pull together a useful resource. The intent is collaboration to achieve a goal that is possibly greater than most of us can achieve by ourselves.

All contributions are gratefully received and can be freely shared with anyone who is interested.

The latest crowdsourced version of the document appears below. You will need to scroll to seen the entire content.

[googleapps domain="docs" dir="document/pub" query="id=11xGZs4drfwb7TY15Iwpk52UIxZcFhqMcMp1i3yV4To8&embedded=true" /]

________________________________________

Further Comment: 11 August 2011

I've been asked where this work is going and what is planned...

The answer is that I haven’t a specific plan.

To my knowledge there has been no environmental scan to explore what the range of models is, to my knowledge, so thought I’d try myself. I spent a day to develop the initial framework, sparse though it was. Googling was a very frustrating experience and finding out the information that we’re interested in from available websites was not easy.

Hence I thought I’d experiment with the crowd sourcing approach. I know there is a rising tide of interest in the generic concept of detailed clinical models and a lot of confusion about the work in ISO and HL7.

I hoped it might contribute to clarifying the situation and providing a concrete anchor on which to base discussions on detailed clinical models.

Worst case scenario, the final result may be little more than a brainstorming, however it will at least form the basis for anyone interested to launch a more rigorous research program, including potentially feeding into the ISO work. Best case scenario, we may have a significant resource. Final outcome will probably be somewhere in between.

I’m happy to leave it online as a general resource – it seems to have generated a lot of interest. I'm hopeful that it will keep evolving.

Engaging Clinicians in Clinical Content (in Sarajevo)

Just browsing and found the link to our presentation for a paper the CKM team gave at the Medical Informatics Europe conference in Bosnia, 2009. Thought I'd share it here, in memory of an amazing conference and location:

MIE09: Engaging Clinicians in Clinical Content [PDF]

Our presentation:

[slideshare id=1958920&doc=engagingcliniciansinclinicalcontent-090906091020-phpapp02]

And the reference to Herding Cats is explained (a little) in the embedded video - actually an advertisement for EDS:

[youtube http://www.youtube.com/watch?v=Pk7yqlTMvp8&w=425&h=349]

I arrived after a 37 hour flight - Melbourne - London - Vienna - Sarajevo to join my Ocean CKM team - Ian McNicoll and Sebastian Garde. We presented our paper and also ran an openEHR workshop.

The conference was held at the Holiday Inn in Sarajevo - the hotel in which all the international journalists were holed up during the war, on 'Sniper Alley'.

Despite it being 14 years after the war had ended, raw emotions were palpable many times during the conference. That a pan-European conference was being held in his beloved Sarajevo under his auspice was a very overwhelming event for the Professor of Informatics and he was often seen in tears!

From my hotel room window in the centre of the city I could see 6 cemeteries.

Walking through the inner city we came across many cemeteries, thousands of marble gravestones with the majority representing the young men aged between 18 & 26.

Bullet holes were still very obvious on the walls of buildings.

Yet the city was vibrant, alive and welcoming.

I won't ever forget this visit.

Some photos of the experience:

Making sense of 'Severity'

'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:

• Pain – expressed as intensity, often including a visual analogue scale as a means to record it ie rate from 0-10
• Burns – describing percentage of body involved e.g. >80% burns
• Burns – describing the depth of burn by degree e.g. first degree
• Perineal tears – describe the extent and damage by degree – e.g. second degree tear
• Facial tic – expressed in using frequency e.g. occasional through to unrelenting
• Cancer – expressed as a grade, clinical or pathological
• Rash – extent or percentage of a limb or torso covered.
• Minor or major
• Mild, disabling life-threatening
• Relative severity – better, worse etc
• Functional impact – ordinary activity, slight limitation, marked limitation, inability to perform any physical activity
• Short or long term persistence
• Acute or chronic

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 (or significance);
• Clinical treatment required; and
• Outcomes.

Clinical impact/significance might include:

• None - No clinical effect observed
• Insignificant - Little noticeable clinical effect observed.
• Significant - Obvious clinical effect observed
• Life-threatening - Life-threatening effect observed
• Death – Individual died.

Immediate clinical treatment required might include:

• No treatment
• Required clinician consultation
• Required hospitalisation
• Required Intensive Care Unit

Outcomes might include:

• Recovered/resolved
• Recovering/resolving
• Not recovered/resolved
• Fatal

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.

Don’t re-invent the (clinical content) wheel...

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:

• the HL7 standards organisation - where my UK colleague, Charlie McKay, informs me that there are more than 20 different approaches to clinical content development. Keith Boone (@motorcycle_guy) has posted his response to the PCAST report from a HL7 point of view - The Language of HealthIT;

• Stan Huff's group at Intermountain Health in Utah have had extensive experience in defining standardised clinical content across all of Intermountain's systems – they are leading experts in this domain; and
• I understand Don Mon and his team from AHIMA have also been working in this area.

2. In Europe, and Australia:

• The Australian National eHealth Transition Authority (NEHTA) has just launched a national clinician-led CKM approach to grassroots clinical content standardisation creating NEHTA's Detailed Clinical Models (DCMs).
• The Swedish national eHealth program has been actively working to integrate openEHR archetypes with its' VTIM architecture.

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!

Can clinicians agree?

There have been a number of robust discussions in recent weeks around the claim that clinicians achieve consensus around computable definitions for clinical content. All discussions have been with MDs, some with substantial experience in various international standards organisations. All have been extremely sceptical...

The first challenge: "—What is a heart attack?” - and the response, —“5 clinicians, 6 answers” – and they are probably very accurate!

The second: —“What is an issue vs problem vs diagnosis?” - I'm told that this has been an unresolved issue in HL7 for 5 years+!

—And the third, from an obstetrician: “The midwives want all this rubbish that we don’t” - perhaps an unfortunate way of expressing the absolutely correct need for different clinicians to have screens presented that are relevant to the patient and the immediate clinical task at hand. —Different clinicians have different needs.

—However these are all essentially HUMAN PROBLEMS! Issues about communications, synonyms, value sets, screen display/layout. IT will not solve these issues - as always, the clinicians need to work out the issues amongst themselves. So where CAN we achieve consensus?

Within the openEHR Clinical Knowledge Manager environment we are gaining some traction in achieving clinician agreement to the structure required to define clinical concepts as archetypes – the ‘first principles’ of clinical concepts, if you like. The approach is inclusive of everyone's needs and requirements, rather than requiring an arbitrary decision on the minimum data set or a priority data set - so we aim, as best we can, for a maximum data set.

For example, the framework to express a Diagnosis is largely not contentious:

• Diagnosis name
• Status
• Date of initial onset
• Age at initial onset
• Severity
• Clinical description
• Anatomical location
• Aetiology
• Occurrences
• Exacerbations
• Related problems
• Date of Resolution
• Age at resolution
• Diagnostic criteria

And for a Symptom:

• Symptom name
• Description
• Character
• Duration
• Variation
• Severity
• Current intensity
• Precipitating factors
• Modifying factors
• Course
• Aetiology
• Occurrences
• Previous episodes
• Associated symptoms

This notion of achieving clinician (and other domain expert) consensus and standardisation of clinical concepts is a major focus of the openEHR archetype work.

Bear in mind that while agreement can be achieved on the clinical content structure, this is only the first step in ensuring that clinicians are able to enter, retrieve and exchange meaningful clinical data.

So if we can achieve consensus around these archetypes, do clinicians then have to agree on a standard Discharge Summary or Antenatal Record or Report? The answer: only if is useful to do so. Clinical diversity can be allowed if the archetype pool is stable & governed/managed. By tightly governing the archetypes at international or national level, these are effectively the common 'lingua franca' that enables sharing of health information.

Template creation is the next openEHR layer - these aggregate the archetypes together to represent the requirements for a specific clinical activity and then constrain them down from their fully inclusive state to something that is 'fit for use' for a given clinician in a given clinical situation. Terminology subsets are also integrated in appropriate places into the archetypes (sometimes) and templates (usually) to round out the expressiveness needed by computable clinical models in clinical care - neither the structure nor the terminology can do this in isolation.

Once a critical mass of these archetypes are published we will be able to support a breadth clinical diversity across eHealth projects - the need for rigid, inflexible messages and documents to support any health information exchange has been largely overcome. Clinicians will only need to agree these types of messages or documents where there is a measurable benefit for doing so, and at all other times they can focus on ensuring that they express their archetype-based clinical records as flexibly as they need to for patient care. Sure, the human factors remain unresolved - but not even the most perfect EHR will solve these issues!

So can clinicians agree? Yes! It is happening in many areas related to data structure, creating a solid framework for our electronic health records. Archetypes are the tightly managed building blocks; templates enable safe and flexible expression of clinical and patient records - allowing the best of both worlds, both governance AND clinical diversity to flourish... and the clinicians are finally able to actively participate in shaping their EHRs.

Archetypes: the ‘glide path’ to knowledge-enabled interoperability

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.

Why is the health information domain different?

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.

Information-driven EHRs

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.

The openEHR paradigm

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:

• Display of artefacts including structured views, technical representations and mind maps to make it easy for clinicians and others to review;
• Uploading of new knowledge artefacts – archetypes, templates and terminology subsets – for review and publication;
• Archetype metadata supporting classification, ontological relationships and repository-wide searches;
• Digital asset management including provenance and artefact audit trail;
• Integration with openEHR tools supporting quality assessment & technical validation checks;
• Review and publication process for clinical content – draft, team review, published and reassess states
• Terminology binding and terminology subset reviews;
• Online archetype translation with review;
• Community engagement via threaded discussions, repository downloads, attached resources, watch lists, email notifications, user dashboards and release sets;,
• Editorial support via To Do lists, user and team administration, review management, artefact modification, classification management, broadcast emails etc;
• Subscriber auto-notification including Twitter and email
• Reports – Archetypes, Templates and Registered users

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.

Benefits of a collaborative, data-driven approach

A collaborative and domain expert-led approach to our health information provides many benefits which include the following.

Benefits for stakeholders

• Active involvement of domain experts to ensure the safety and quality of health information.
• Development of a coherent set of health information definitions:
  • Improved data quality – shared core clinical content plus specialised domain-specific content will be agreed and ratified by the domain expert community; health information created will need to conform to the agreed archetype specifications.
  • Improved data ‘liquidity’ – specifications to support exchange, flow and re-use of health information - from direct patient care through to secondary use of data. Improved data longevity – shared non-proprietary health information definitions minimise need for data transformations or system migration and the inherent risk of data loss; will support the cumulative, lifelong health records and longitudinal data repositories;
  • Improved data availability – easier integration of health information from disparate sources when based on common archetype definitions;
  • Re-use, integrate and aggregate data for supporting quality processes such as clinical audit, reporting and research; and
  • Break down the existing ‘silos’ of health information based on proprietary and varied definitions.

• Online collaboration maximises the potential for a breadth of grassroots stakeholder engagement in ensuring correctness of the health information definitions.
• Active participation by clinical domain experts to shape and influence their EHRs, ensuring that EHR content is ‘fit for clinical purpose’.
• Online participation in clinical content review will be of short duration and at times of convenience to the clinician, avoiding the significant time and opportunity cost of attendance at face-to-face meetings.

Benefits for patients

• Data created and stored in a shared, standardised and non-proprietary representation supports the potential for application-independent data records that can persist for the life of the patient.
• Improved data ‘liquidity’ – so that data can flow between healthcare providers and systems to where the patient needs it.

Benefits for national programs and other jurisdictions

• Development of a coherent national set of clinical content specifications to support the shared EHR programs, health information exchange and secondary use.
• Enables national governance of foundation clinical content while at the same time facilitates flexible expression of local domain requirements
• Efficient use of sparse clinical, informatics and stakeholder resources:
  • Design & create an archetype once; re-use many times;
  • Leveraging existing clinical specification work done internationally to improve local national pool of archetypes;
  • Online collaboration maximise the potential for stakeholder engagement at the same time as minimising the requirement for expensive face-to-face meetings; and
  • Review and publication of agreed clinical specification definitions within weeks to months;
  • Review and standardisation of clinical documents containing agreed archetypes will be relatively short.
• • Clinical knowledge management ecosystem:
  • Single national repository of clinical knowledge artefacts, including archetypes and terminology subsets.
  • Focussed and coordinated knowledge management environment where all stakeholders can observe, participate and benefit; the opposite of the current fragmented, isolated and proprietary approach to defining health information content.
  • Digital knowledge asset management:
    • Manages authoring, reviewing, publication and update lifecycle of all knowledge assets;
    • Provenance and asset audit trails;
    • Ensures asset compliance to quality criteria;
    • Ensures technical validation of assets; and
    • Development of coherent release sets for implementers;
  • Governance of knowledge assets.
  • Distribution of knowledge assets via coherent release sets.
• Removes the need for per message or per document negotiation between application developers, organisations and jurisdictions each time information needs to be integrated or exchanged by use of the standardised content within more generic message wrappers or document structures.
• Transparency of editorial and publishing processes; accountability to the domain expert community itself.
• Precludes the need for ratification of clinical or reporting documents through a traditional standards process when they consist of subsets of the nationally agreed archetypes.

Benefits for application developers

• Download coherent sets of clinical content definitions from a published and agreed national repository – not re-inventing the wheel by defining each piece of health information over and over.
• Software development remains focused within the expert technical domain – user interface; workflow processes; security, data capture, storage, retrieval and querying; etc.
• Removes the need for per message or per document negotiation between vendors, organisations and jurisdictions each time information needs to be integrated or exchanged by use of the standardised content within more generic message wrappers or document structures.

Benefits for secondary users of data

• Existing data can be mapped to archetypes once only, and transformed into a validated and consistent format; new data can be captured and aggregated according to the same national archetype definitions.
• Data stored in a common representation can be more easily aggregated and integrated.
• Access to valuable legacy data that would otherwise be unavailable.

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 if... grassroots professional clinical colleges were driving EHRs?

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?

1. Promote the establishment of a universal health record - a long-term, data-driven health record platform based upon open source specifications, a standardised health data structure, and application-independence. If we place the patient's universal health record at the focus, applications can effectively 'plug & play' with an open, standardised patient data repository, instead of struggling/battling to move/transform/migrate/map/message bits of health information between proprietary application silos.
2. Develop clinical quality-related eHealth standards:
   • Knowledge artefacts specifications The clinical knowledge expertise of colleges can be used not only to develop principles of best practice and clinical guidelines etc but also the structured clinical content specifications that underpin the universal health record and ensure that the health record is able to capture all the data that their clinicians need to provide quality clinical care, to share with other healthcare professionals and for research. These specifications need to be defined both at the clinical concept level, such as the specification for blood pressure, but also expressing how many clinical concepts can be aggregated together and constrained to specify the requirements for a computable discharge summary or an anaesthetic record. Ideally this would be work done in collaboration with other clinicians, colleges and informaticians to make sure that the agreed concept specifications are applicable for all colleges and clinical domains, so that there is one common concept in use for all. Colleges as domain experts are also best placed to determine the terminology subsets that are appropriate for use by their clinicians.
   • EHR best practice: Develop principles around the best practice use of electronic health records, including:
     • Data quality principles and activities. As health records become electronic, the previous remit of Colleges to make sure that clinical practices are accredited and that paper records are kept to a documented standard can be transformed to the eHealth paradigm. There are similar principles that can be developed and applied when clinicians are capturing and using data. Programs such as Primus Plus in the UK have worked directly with primary care clinicians to educate and support about best practice data management.
     • EHR safety - User interfaces,clinical processes, decision support etc

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...

So I'll ask you a question. Is the tail wagging the dog? Should vendors be deciding what clinicians need? OR Should the colleges be driving vendors to develop the EHRs that members need to provide quality healthcare to their patients? From a quality point of view, one could strongly suggest that professional colleges should be the experts driving this new paradigm of clinical care.

Web2.0 Clinicians – building clinical knowledge resources

After 5 collaborative review rounds by 18 clinicians and informaticians from 9 countries, today I have published the Clinical Synopsis archetype on the openEHR Clinical Knowledge Manager. The Clinical Knowledge Manager (CKM) is an online community putting the Web2.0 paradigm into practice for EHR development. From the CKM wiki...

"The openEHR Clinical Knowledge Manager is an international, online clinical knowledge resource – www.openEHR.org/knowledge. It has gathered an active Web 2.0 community of interested and motivated individuals focused on furthering an open and international approach to clinical informatics – an application- and message-independent lingua franca for sharing health information between individuals, clinicians and organisations; between applications, and across regional and national borders. All contributions to CKM is on a voluntary basis, and all CKM content is open source and freely available under a Creative Commons licence.

The core openEHR building block/knowledge artefact is known as an archetype. To a clinician an archetype is a computable definition of single, discrete clinical concept; yet to a software engineer it is a computable expression of a domain content model in the form of structured constraint statements, and based on a reference model. Both definitions are describing the same computable knowledge artefact and in practice, clinicians drive the development of the archetype and the engineers implement them in software."

CKM status

At time of writing the registered CKM community numbers 433 individuals from 53 countries, with 184 volunteering to participate in archetype reviews and 50 volunteering to translate archetypes once the content is published. (Current user stats are here). It comprises a range of clinicians, health informaticians, software engineers, terminologists, researchers, students, policy makers, and administrators – and is open to anyone to join and participate. No consumers yet, although the models are designed to be used in PHRs as well. You can self-register by clicking on the link in the top right of the CKM screen.

There are over 250 archetypes currently available - most are still draft; some that are currently within the Team Review process; and a small number that have achieved consensus during Team Review of the clinical content and have been published. Others are in development in various projects and national programs from around the world and many will gradually be submitted into the CKM for international review and publication.

The priorities and focus of the current openEHR CKM archetype reviews are on achieving agreement and consensus on the 10 key archetypes that would support healthcare provision in a typical crisis situation.  Effectively these archetypes would contain clinical content that the openEHR community regard as the most important components of any Emergency Summary – the '10 archetypes that could save a life'!

Not surprisingly progress has been steady but a little slower than anticipated. Remember, all participants volunteer, including the editors and this is a relatively new activity. As such we are continually learning and refining the CKM tool and our processes. Most importantly, we are seeking to align the identified critical archetypes with the work that is being done in isolation by many standards groups and national bodies. Under review at the moment are probably the two hardest on which to achieve consensus – Adverse Reactions and the Problem/Diagnosis family. Medication orders is about to commence the review process.

Interestingly, the Adverse Reaction review is currently paused because following it's first review round, where it became clear that Adverse Reaction needs to be considered as part of a larger picture related to the modeling of all safety-related concepts. At present I am endeavoring to tease out the differences and overlap in theory and practice related to Adverse Events; Adverse Reactions; Adverse Drug Reactions; Warnings; Alerts; and Risk plus Adverse Event reporting to statutory authorities – it's complex and I can't see where this has been done previously. In practice, most current EHRs try to mimic the way we record these concepts in paper records, but this is not easy. How we should replicate that critical 'ALLERGIC TO PENICILLIN' scrawled in red felt pen across the front of a paper record, so no-one misses it? To take our EHRs into the future we need a cohesive suite of concept definitions that will support data capture, viewing, querying and inferencing to support clinical decision support. So watch this space, and please let me know if you'd like to join in!

Modeling an entire EHR – is it achievable?

Many will consider that creating and agreeing all the clinical content for an EHR is an impossible task. However let's consider a couple of key things about openEHR:

1. The openEHR archetype is created as 'a maximal data set for a universal use case'. So in other words, everything we can think of about a single clinical concept for use in every possible clinical scenario. In the past we have struggled and fought about the inclusions in minimum data sets, however with a maximum data set everyone's priorities can be included. The innovation of openEHR is in achieving consensus on the data specifications through use of the maximum data set but allowing for clinical diversity and relevance by constraining the maximum data set down to a useful one for each clinical scenario through use of templates. I like to think of this as a little bit of 'magic – a bit like having your cake and eating it too!
2. While there are 350,000+ SNOMED terms, we do not anticipate 350,000 archetypes. In fact 10-20 will comprise most emergency or discharge summaries and as few as 50-100 archetypes could cover most of a typical primary care EHR. Most people are surprised that we need so few archetypes, and the key reason is that each archetype is about a concept, not an archetype per symptom or diagnosis. In fact there is a single symptom archetype and a single diagnosis archetype that will likely cover more than 90% of symptoms and diagnoses, by using a terminology such as SNOMED CT to identify the actual symptom or diagnosis itself. The power of structured content definitions (the archetypes) plus a terminology is a very powerful semantic combination.
3. We have started with the hardest archetypes – those in which nearly every stakeholder and jurisdiction will have an opinion. Once these key 10 archetypes are published, we anticipate that the momentum will increase.

Tim O'Reilly spoke of the Web2.0 being a 'harnessing the collective intelligence' and while in it's early days still, CKM is starting to do just that – to bring together experts from many profession domains, areas of expertise and geographical regions with a common goal. Grassroots clinicians are contributing alongside the technical experts – all contributions are gratefully received and are incorporated into the final published content models.

Please regard this as an open invitation to all to become involved. Self-register, and if you want to become involved in archetype review then 'adopt' the archetype/s of your choice!

All Blood Pressures are not created equal! (Part II)

Following on from the previous post... If we want to compare and review blood pressure (BP) over time from all sources and clinical situations, then they need to be recorded in a consistent manner. We also need a common structure to facilitate accurate data exchange without manipulation.

Most systems have a proprietary database comprising a home-grown data structure – so if there are 'n' thousands of clinical vendors in existence, there are probably way more than 'n' thousands of technical approaches to specifying the clinical documentation and process that are so familiar to you. HealthVault is one that publishes its data specifications publicly but most private companies are not so open.

There are also a number of approaches that are proposing use of common data structures to support health information sharing. You can see some of my thoughts on this in previous posts – and in my opinion this is definitely the way to go if you want/need to do smart and active things with health data. Some examples are HL7 templates and openEHR archetypes.

Let's take a look at some publicly available representations of Blood Pressure...

On the right is the Microsoft HealthVault Blood Pressure specification (click image to enlarge):

It's largely in 'techspeak', although if you examine the specification itself you will find only three clinical elements:

• Systolic
• Diastolic and...
• Pulse!

Ouch... Pulse is usually independent of BP measurement for most clinicians, even if it may commonly be measured simultaneously. This model cannot currently capture event the basice clinical requirements identified in the previous post - not even recording that a large cuff was used for an obese patient, to indicate whether the measurement is accurate and able to be interpreted confidently. This model is really not rich enough to cater with our clinical recording requirements for Blood Pressure.

At right is a HL7 model for Blood Pressure (click image to enlarge):

Umm... maybe a little difficult to understand. It's hard to see the scope of the content, and almost impossible for clinicians to have input into, which is a significant issue in terms of achieving accessible and high quality data definitions.

Finally, openEHR has a number of ways of representing the data model for Blood Pressure. It is a maximal data set intending to capture all information about Blood Pressure measurements for all the clinical and research situations described previously, and more.

On the right is the simplest representation of the openEHR blood pressure archetype – displaying the content in a non-technical way so that all clinicians can focus and comment on the  clinical content itself.

At right is another way that the same BP archetype is displayed to clinicians and informaticians - specifically used when seeking detailed comments about the clinical content on a per element basis during collaborative online archetype reviews. While it may help to have an understanding of data types eg Text or Quantity or Date, no deep understanding of openEHR is required of participants.

In the interests of full disclosure, I have been intimately involved in the development of the openEHR Blood Pressure archetype which has been developed and agreed with a lot of clinical input, and places a lot of emphasis on being approachable by clinicians and incorporating their feedback.  The representations you see here are not perfect, but grassroots clinicians are participating actively in online reviews of archetypes.  The blood pressure archetype was published after consensus was reached on the content by 30 clinicians, informaticians and engineers from 13 countries.

There is no doubt that at first glance the archetype may appear too rich. One of the key differentiators in openEHR is the capability to take this maximum data set and activate/display only the parts that are relevant to the clinical scenario requirements eg for primary care or a paediatric patient. This detailed discussion is out of the scope of this post, and will be left until a later date.

The focus of the health IT domain has largely been technical. Involvement of clinicians has often been token or as a secondary process.  It is critical for successful development of EHR systems that clinicians are able to be actively involved in development and quality control of the clinical content that underpins these systems - clinicians need to request involvement. At the same time, the health IT domain needs to 'un-technify' eHealth - clinicians need support to participate, so that more than just a few elite informaticians can view these data structures and contribute to their development and quality review.

In these two posts we have explored a little about the scope of clinical models and their representation. Yet again, this is still only the tip of the iceberg re health data. The list goes on, including the use of terminology and the non-trivial technical requirements that are required to underpin these clinical models so that we have know exactly what this data means - far more complex than can be supplied by a simple XML model. Now that really starts to open a can of worms... for later!

All Blood Pressures are not created equal! (Part I)

Clinicians, have you ever had a look at the data structures underpinning your EHR - the models of clinical content? If you don't understand the principles of what your data structure is then your EHR may not do, or ever be able to do, all the things you need it to do to record your clinical notes. You need a sense of what is 'under the bonnet' and what its capabilities are. Take Blood Pressure as an example. It is probably the most easily understood clinical concept to both clinicians and patients. We clinicians tend to think of it as a very simple measurement to record on paper, and we expect our EHR applications to do it in a similar way.

So let's brainstorm about what we need to record blood pressure. The typical primary care provider such as a General Practitioner or Nurse will record the Systolic and Diastolic pressures, plus maybe a blood pressure cuff size if it is different to the 'normal' cuff, and position of the patient if recording a postural drop. This is straightforward, 'bread and butter' stuff for clinicians.

So the base data requirements are:

• Systolic – a quantity that is a pressure, measured in millimeters of mercury (mmHg)
• Diastolic – ditto
• Cuff size – most will measure using a 'normal' adult cuff, recording a size only if they use a larger or smaller cuff.
• Position – most patients in primary care will be sitting; most in hospital will be reclining

While this may cater for the large majority of our BP measurements, there are other less common situations where it is critical that BP be recorded appropriately and in context. So we need a data specification that also caters for the following situations where BP is measured, such as:

• The cardiologist or exercise physiologist may need additional data about the level of exertion for use in stress testing or research. A BP measured at rest needs to be interpreted differently to that recorded after jogging for 10 minutes.
• Recording a series of BP readings over a 24 hour period to determine the 24 hour average, plus knowing the patient's concurrent sleep status – this is now regarded as key diagnostic criteria for diagnosis of hypertension in Europe.
• Measuring data from home BP machines – many of these actually record the Mean Arterial Pressure and use an algorithm to determine the Systolic/Diastolic readings displayed.
• Automatic BP measuring every 5 minutes during surgery or an admission to Intensive Care by 'the machine that goes beep'.
• Paramedics taking a measurement of a trapped patient at the scene of an car accident.

Other questions might be clinically significant in some circumstances include:

• What Korotkoff sound was used?
• What about the implications for paediatric measurement?
• Where was the measurement taken? Which limb? Finger vs upper arm?
• How was it taken – auscultation; palpation, machine; or invasive?
• What about pregnant women who need to have their BP measured with lateral tilt to get a true reading – do we need to record that detail?

It may be very important to have this information recorded in some situations.

Maybe blood pressure is maybe not so simple, after all.

Clinicians understand clinical nuances well, recording the contextual variations appropriately in paper records – in fact it is so ingrained that it is almost done on autopilot. The problem arises in trying to get computers to do the same thing – to record simply in the usual circumstances but be able to cope with the complex and detailed where it is critically needed.

So, we need to have some understanding about the capabilities of our EHR systems.  Most systems only cater for little beyond the basic four requirements. Yet most of these additional requirements that we have identified are useful or necessary at other times to ensure unambiguous BP recording.

The mind map at left captures the basic versus the 'ideal' requirements. The 'ideal list may seem excessive to some. Yet if our EHR system could cater for this, then we could record all nuances of BP accurately and share them unambiguously if they share the same underlying structure - primary care to secondary care; PHR to EHR to research; patient to clinicians. So then, the 'art of the EHR' is to present the right amount of information and the right context to the clinician to let them record what they need - not too much for the common simple BP reading, but more when necessary.

Here we have started to explore the tip of the iceberg – the content scope of one common clinical measurement. The essential message here is that we clinicians need to have some understanding of what is 'under the bonnet' of our EHR systems. What may be adequate for the commonest situation is not necessarily enough for recording the complexities of clinical care.

Part II starts to explore clinician engagement in content models...