Preventing health data 'black holes'!

It really is not surprising that scientific data is disappearing all the time. But, oh, think of the value of this data - in terms of cost and knowledge. Irreplaceable. The original article from Smithsonian.com is here: The vast majority of raw data from old scientific studies may now be missing.

Some excerpts:

A new survey of 20-year-old studies shows that poor archives and inaccessible authors make 90 percent of raw data impossible to find.

...

When a group of researchers tried to email the authors of 516 biological studies published between 1991 and 2011 and ask for the raw data, they were dismayed to find that more 90 percent of the oldest data (from papers written more than 20 years ago) were inaccessible. In total, even including papers published as recently as 2011, they were only able to track down the data for 23 percent.

...

"Some of the time, for instance, it was saved on three-and-a-half inch floppy disks, so no one could access it, because they no longer had the proper drives," Vines says. Because the basic idea of keeping data is so that it can be used by others in future research, this sort of obsolescence essentially renders the data useless.

...

And preserving data is so important, it's worth remembering, because it's impossible to predict in which directions research will move in the future.

Seems to me that the openEHR approach to data definitions is an excellent candidate for preventing the health data 'black hole' too!

Non-proprietary, open data specifications are a key component for future-proofing irreplaceable clinical and research data.

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?

openEHR: interoperability or systems?

Thomas Beale (CTO of Ocean Informatics and chair of the Architecture Review Board of the openEHR Foundation) posted these two paragraphs as part of the background for his recent Woland's Cat post - The Null Flavour debate - part I. It is an important statement that I don't want to get lost amongst other discussion, so I've reposted it here:

An initial comment I will make is that there is a notion that openEHR is ‘about defining systems’ whereas HL7 ‘is about interoperability’. This is incorrect. openEHR is primarily about solving the information interoperability problem in health, and it addresses all information, regardless of whether it is inside a system or in a message. (It does define some reference model semantics specific to the notion of ‘storing information’, mainly around versioning and auditing, but this has nothing to do with the main interoperability emphasis.)

To see that openEHR is about generalised interoperability, all that is needed is to consider a lab archetype such as Lipid studies in the Clinical Knowledge Manager. This archetype defines a possible structure of a Lipids lab test result, in terms of basic information model primitives (Entry, History, Cluster, Element etc). In the openEHR approach, we use this same model as the formal definition of this kind of information is in a message travelling ‘between systems’, in a database or on the screen within a ‘system’. This is one of the great benefits of openEHR: messages are not done differently from everything else. Neither is interoperability of data in messages between systems different from that of data between applications or other parts of a ‘system’.

Records, the universe and everything

Here is a surprising gem that I found this morning - "Records, the universe and everything" is part of a presentation entitled "Where is THE medical record?" given by David Markwell to the Primary Health Care Specialist Group of the British Computer Society back in September 1996.  Enjoy...

Carrie Byte sifted through the envelopes on her desk. She had already searched the practice computer without finding anything of interest. Her face was a picture of tired resignation. She was about to see Arthur Dent. She had never met him before, but her senior partner had once told her something about him. She could not remember what it was, but she did recall it was unusual. Without the record she would be at a serious disadvantage.

She lifted the phone and dialled.

"Hello, George. Mr Dent's record doesn't seem to be here."

George apologised and said he would look for it. As Carrie hung up the phone, there was a knock at the door and, almost immediately, in walked a nondescript man.

"Hello, I'm Arthur. I expect that you are Dr Byte."

Carrie agreed that she was, asked what she could do for him, and apologised that his record was missing. He smiled and said that he had been away for a few years.

"Your record is probably with the FHSA", she suggested.

"Perhaps the Vogons mislaid it when they destroyed the planet", he countered.

"What do you mean?" she asked.

"I admit the FHSA is more likely, but never dismiss the improbable."

"Good advice for a doctor - but tell me what I can do for you today", Carrie said, trying to regain control.

The smell of coffee percolated through the door and she wanted to get this consultation finished. After another knock at the door George entered, carrying three thick Lloyd George envelopes.

"I found it, Doctor."

Arthur noticed that Carrie looked more downcast by the size of the records than she had been by their absence.

"Bit of a trilogy, isn't it, Doctor?" he quipped.

She smiled and he continued "Don't panic! I only want to know the results of my last hospital visit. Your partner, Morris Oxford, referred me for an opinion."

Ten minutes later she had waded through letters, printouts from other practice computers and reams of notes and established that the hospital letter was missing. It took ten more minutes for George to find it in Dr Oxford's in-tray.

As Author left the room he turned and said "Just one more thing, Doctor." Her heart dropped.

"I have a friend who has really good ideas about piles of paper. He'd help you find the right information more easily and have time for a coffee break."

"Oh yes", she replied sceptically.

"Yes", he said emphatically. "You must meet him. One o'clock in the Frog and Sparrow, and bring a towel."

He spoke with such authority that she felt obliged to join Arthur and his friend at the appointed time. Arthur introduced Mr Prefect who frowned as he greeted her and said "No towel. You've forgotten the towel. Oh well, I suppose it doesn't matter."

He took from his pocket a small box with the words "Don't panic!" written on it. "This", he said, "is what Arthur was telling you about."

By the end of lunch break she was convinced. A week later her practice had installed the Instant Transfer Computerised Heath Hyper Record. At the heart of this system, known as the ITCH-Hyper Record, was the concept of the improbably distributed record. Few people understood it, but that didn't seem to matter. It promised an end to 'missing record' misery and it really worked. Within three months, every practice, every hospital and every community unit in the country had installed the ITCH-Hyper Record. Clinical information entered anywhere was seamlessly shared by everyone, subject to necessary and appropriate security constraints. The age of information sharing had arrived, dreams of patients outshining paper became reality, the wood was seen, the trees were spared and crocks of gold appeared under every rainbow.

Six months later Carrie started to worry. She was looking at a record which showed a high blood sugar result two days previously. She switched screens to check the advice on her decision support system. She returned to the record and the blood sugar was normal. The first time it happened she assumed she had misread the screen. The next day it happened to another patient's record, and then another. She queried it with the lab. They said there had been some errors in a batch of tests but insisted they were corrected immediately. Then why, she wondered, had she seen the erroneous results nearly a week later? Soon the medical press were full of stories of similar incidents. Ford Prefect explained by saying "The old record is cached and not refreshed until it is re-accessed. It's just a glitch: we'll fix it."

The next problems Carrie noticed were intermittent gaps in records. These were accompanied by ubiquitous "Don't panic!" messages accompanied by icons depicting sporting events. Enquiries to the support desk were met with the patronising response and brief explanation that the tennis racket meant a 'service fault', the rugby ball a 'line out' and the golf club 'open links'. These errors became more common and it was inevitable that before long the system acquired the less flattering nickname "The Glitch".

Just over a year after Carrie's meeting in the Frog and Sparrow, she was the defendant in the first court case in which two incompatible versions of a patient's ITCH-Hyper Record were presented as evidence. Both carried all the marks of authentication as the genuine record for the same patient. The judge asked for explanations. Ford and Arthur attempted to explain about caches, probability, post-dating, modification, repudiation and the importance of towels for galactic hitchhikers. The judge was unimpressed and asked a simple question: "Where is THE medical record for this patient?"

Ford asked for clarification and the judge obliged. "Where are the original records of the clinical information recorded by each of the health care professionals involved in the care of this patient?"

Ford regarded the judge as a child who wanted to open a television to look for the people inside. He made a contemptuous remark and was silenced.

Arthur came to the rescue. "It's like this, I think. It's sort of everywhere. Well, everywhere in the cyberspace defined by thirty thousand clinical systems in the UK. That is, it could be anywhere, but nobody knows where, and of course, nobody really needs to." The judge was silent for half a minute. During those thirty seconds several dolphins spontaneously appeared, unnoticed, in the courtroom. Then the judge spoke very slowly and deliberately: "I need to know and I need to know now. Otherwise, how can I determine which of these pieces of so-called evidence is genuine?" He paused, waiting for a response. As the silence continued, Ford and Arthur vanished, having hitched a lift on a passing Dolphinian space trawler. The silence resumed. The dolphins smiled and vanished, still unnoticed.

Then the judge summed up. "It is claimed that the medical record is everywhere. That it is distributed across what has been called cyberspace. Yet, since we find that in two places it differs, from a legal perspective there are at least two versions. Neither of these can be located and nor can they be separated or distinguished from one another, except by the factual differences in the statements they contain. It follows that I am unable to determine the legal status of either. Therefore, for the purposes of this court, I rule that this patient's medical record is located nowhere. Since something that is nowhere does not exist, I further rule that it is inadmissible in this court. This being the case, can anyone present any evidence that will help this court to reach a judgment?" There was another pause while the judge and others noticed the absence of the expert witnesses. He smiled and added: "I presume that Messrs. Ford and Dent are now distributed in a manner similar to their records. Is there a shred of evidence to assist us with this case?"

Carrie passed forward a page torn from her diary on which she had made a few rough scribbles. Her counsel rose. "If it please your honour, I have here a piece of paper written on by Dr Byte at the time. It appears to corroborate her account." The judge, having studied the paper, passed it to the plaintiff's legal team and asked if they offered any further evidence. After a hasty conversation with their client, they indicated that no more evidence would be offered and the case was dropped.

The profession was not always the beneficiary of this legal precedent. Patients who made their own rough notes immediately after consultations won otherwise absurd cases against doctors unable to cite admissible medical records. Within a few weeks most GPs were reopening their filing cabinets, brushing the dust off their pens and relearning elaborate hieroglyphics. The ancient art of doctors' writing was reborn. Years later, when Carrie retired, she cleared out her desk and found a perfect glass replica of a 3.5" computer disk. She didn't know where it came from, but it reminded her of the heady days of her youth when she really believed paperless practice had arrived.

Interesting to see a summary of the conference agenda and links from the proceedings still online and active.

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

EHRs: the means, not the end

I remember hearing a story about a software demonstration for practice management and billing - a classic where the practice principal proudly stood up and gave testimony about the merits of his new system, including the news that he had to hire extra staff in order to run it, above those who had run the practice beforehand.  Apparently the audience's collective jaws 'hit the floor'.  This is not good eHealth.  Health IT should not add overheads, but make things smarter, quicker, more efficient, and more valuable - or it's probably not worth doing. There is something weird that appears to happen around computers and all things 'e' - sometimes we just seem to lose our analytical skills, or perspective, when sitting in front of a computer. Computers are just tools to support us in our practice of healthcare.

In KevinMD's excellent guest blog in August 2009, "How a wealth of information takes attention away from the patient", Abraham Verghese discusses the tension experienced - look at the data or the patient? With more information available at our fingertips and with only a limited amount of time per patient, how do we prioritize our focus for the best outcomes?  It's not easy as you might first think. We can be torn between the need or desire for (possibly) higher quality, detailed data, rather than the conducting a thorough patient history and exam - after all, time is limited.

When I was in medical school it was always drummed into me that you couldn't compromise a thorough medical history; that a history was possibly way and above more important than even the examination and the secret to good medical practice.  I have always considered that this is a good principle to work by.

If using an electronic health record (EHR) compromises those high standards, then it is time for a re-think.  An EHR should enhance, not hinder.  If it gets in the way of you talking or touching the patient, or causes you to spend more time or effort WITHOUT providing value back then there is something wrong. Note that the value may be direct and immediate (e.g. more efficient; data available at point of care) or indirect and delayed (e.g. better quality data; ability to do query/research, support recalls etc). The benefits should be obvious. Difficulties are usually multifactorial - the clinician; the application; the inability to touch type; or other factors - but they are an important trigger for stopping and investigating the current work processes so that the problems and barriers can be identified and tackled.

Anecdotally, it has surprised me to see some clinicians assume that data displayed on a computer screen has more authority than it warrants, because it is electronic format. They change the way they practice. However, just as in a paper record, because 'nil known' is noted on a computer screen next to 'Known allergies' does not necessarily mean that they don't have any - you still have to ask as the answer may have changed since last asked.  Whether a previous clinician has written in pen or electronically, there is no difference to how we should practise.

Are we compromising our practice? The good old doctor-patient interaction vs. the EHR?

An EHR should not change the way a clinician engages with the patient.

So, it's not rocket science, but don't EHR for EHR's sake. After all, let's face it; an EHR is only useful if it supports quality health care. It is a means to an end, the journey, but not THE end.

Yes, you might arrange the office differently and there might be more opportunity for collaboration once the patient can see their record - that's all good. But if use of an EHR compromises the doctor-patient communication, the recording of data, the use of time in a consultation, or making the history-taking and examination a priority, then the issue needs identification and quick resolution.

Don't lose those first principles that you learned in medical school - they are the foundation of the doctor-patient interaction. The EHR should just be a supportive framework to enable you to do a better job.  If it doesn't, stop and re-think as the EHR should enhance, not hinder.

But you all know that already - this is just a reminder for when we lose a little focus in the excitement...

Standardized, data-driven eHealth

What is an EHR? Most currently working within eHealth circles will have a ready answer, and the classic response will be something like "an EHR is a software application that is used by clinicians for provision of patient care". But think about it for a second...

What do we want from an electronic health record? It's not actually the application or the user interface or the workflow, but a record of health information in an electronic format.

And so what of the health information itself? What is it? What do we want? What should we want?

Let's work with these definitions: Data are the computable facts; while health information is the data after it is processed, organized, structured or presented in a given context so as to make it useful.

We definitely want health information that...

• Is available at the right time and the right place to the right person.
• Is accurate, detailed and of high quality.

I don't think there is much disagreement on these two points. How about these next suggestions?

We should also want health information that...

• Is a lifetime health record - cradle to grave. Health information that can be accumulated over time, aggregated from many sources to inform better care for ourselves, our patients and loved ones.
• Can be created in one place or by one provider and shared with others so that the meaning of the data is preserved and accurate.
• Can be dynamically and actively used - consisting of structured, atomized data that we can re-use and combine in different ways to improve our health and wellness. Documents or PDF's of our health information are useful as part of a passive record, but they are effectively a dead end - we can't do anything useful with big blobs of text except read them.
• Is not locked in to a proprietary vendor database; data should be in an open, non-proprietary format.
• Is a continuum of our health information across all aspects of healthcare and related activities, not fragmented silos of data artificially segmented for personal, clinical or secondary use purposes.
• Can be accessed via an EHR, EMR or PHR, SEHR or ICEHR - pick an acronym, any acronym!
• Can be accessed independent of any specific organizations, providers and geographical locations.
• Has had minimal transformation or manipulation. Keep in mind the Chinese Whispers effect! There is significant risk that important data can be lost or lose integrity with each data migration to a new software application or transformation between disparate systems.

It is a commercial reality that we continue to develop EHR applications in the traditional manner, building the greatest and 'best of breed' clinical software applications, with each EHR vendor doing it in their own proprietary way, as 'rugged individuals'! The resulting software usually has a rich functionality and a great user interface. It is likely that it does a fine job locally in the clinic, hospital or network on which it is installed. But what about regionally, nationally, internationally? Is it still working well if we take the big picture view? Sure, our EHR applications are full of data, but the data is isolated, fragmented, and limited in its use.

There is no doubt that all over the world, the health IT community are finding it unexpectedly hard to exchange health information between different applications - the effort and resources that are being poured into policy, research and pilots for health information exchange is enormous. Progress is glacially slow. If we want to exchange PDFs and documents, then we are doing well, but if we want our software to be able to do more than display text, to do clever things with our health information, then our data requirements are much more complex. If we want that data to be able to be shared, used in multiple applications then the current approach requiring data transformations and messaging paradigms won't be sustainable

Interestingly, the further we go down these paths many are realizing the need to change our emphasis away from the EHR application and towards the data. Back in November 2009, Clay Shirky wrote:

"This ability to separate data from transport and applications from data is the essential pre-condition for innovation — a group that has a valuable new idea for presentation of data for clinical use should not also be forced to think about the data encoding or the way the data are transported. Groups working on new data encodings should not be tied to a pre-existing suite of potential applications, nor should they have to change anything in the transport layer to send the new data out, and so on."

The bolded text, above, reflects my emphasis on an important statement. Confirming this approach, as recently as this week, Kibbe & Klepper also called for separation of the data from the applications and from the transport layer.

Change the focus to standardized, data-driven eHealth

So, innovation requires a new approach to data; a changing emphasis from application- or message-driven to data-driven eHealth. If we also insist on an open and standardized approach to health data specifications then we will be able to realize many additional advantages:

• A strong foundation of shareable and re-usable computable clinical content definitions on which to build coordinated and cohesive applications, messages, clinical decision support programs, and research activities. If we use common, standardized data definitions then the tasks of eHealth become orders of magnitude easier. Content definitions are created and agreed as the content is already specified and the processes become more generic
• An unambiguous and detailed understanding of what each piece of data means so we can do 'stuff' with it - a tight semantic 'handle'.
• A powerful enabler for managing the complex requirements involved in health data capture, integration, aggregation, inferencing and sharing.
• A continuum of our health information, independent of vendor, provider or organization - the real potential for lifelong health records, for the first time.

There is no doubt that this approach is orthogonal to the status quo and it will be challenging to many for logistical, financial and political reasons, but can we really afford to ignore this?

According to the European Commission's seminal 2009 report entitled "Semantic Interoperability for Better Health and Safer Healthcare: Research and Deployment Roadmap For Europe" (PDF, p16), standardizing the capture, representation and communication of clinical data requires three components to represent meaning: a generic reference model for representing clinical data, agreed clinical data structure definitions and clinical terminology systems. Potential standardized data definitions proposed are openEHR archetypes, ISO/EN 13606 Part 2 (which are simpler archetype structures), HL7 templates, generic templates and data sets.  Standardization of data is not 'pie in the sky' but an approach that has had significant research and implementation experience, particularly in Europe.

So, to consumers, clinicians, organizations, researchers and governments, the call should not only be "Gimme my damn data!" but give me standardized data that is application- and message-independent. Then we can actually start to use and re-use our data, not only as a detailed record of current and past health conditions, events and activities, but dynamically and pro-actively to inform and promote our future health and well-being.

Why Is The Shared EHR So Hard?

'Provision of the right data to the right provider at the right time' is the mantra we commonly hear in eHealth. It sounds deceptively simple! Some promise it; some hope for it; but pretty much no-one has it. The collective desire for a seamless and efficient shared electronic health record (EHR) which actually provides that data to the provider at a particular time is widespread and yet the EHR remains elusive. If we know what we want, why is the shared EHR so hard to achieve? Why is it taking so long? And what's more, if the financial sector can do it, why not health?

The progress that we have made in the past 10-20 years of eHealth development has been glacially slow compared to other industries and domains. The approach to health IT, and in particular the shared EHR, has been primarily linear in nature with modest incremental successes achieved. Sure, progress has definitely been made, but despite investing enormous amounts of money and resources, the solution has been more difficult than most ever anticipated. Healthcare doesn't appear to fit the same data interoperability model that has been successful in other domains such as banking or financial services. In a world where connectivity reigns and personal data can flow freely, it is not yet the norm for our health information to be connected nor to flow!

In trying to understand the problem more fully, there are 3 broad headings we need to explore:

1. Technical
2. Human interaction and activities
3. Information exchange

Let's explore some of these issues:

1. Technical

There is little doubt that traditional EHR development has been driven by technology requirements and engineering processes, so many of the typical aspects we consider when thinking of the EHR are actually quite manageable, if not solved - consider storage and retrieval of data, security, role-based access, audit trails, repository storage etc. It is not the technology holding us back here. Some even suggest that the technical aspects of the standalone EHR are the (relatively) easy part, and they may well be right!

With over 7000 EHR vendors in the United States alone, we have proof that building a standalone EHR is undoubtedly achievable. Our EHRs that are in use are traditionally rugged individuals, each created in splendid isolation with the finest data structure, processes and user interfaces! Unfortunately, building proprietary silos of health information is the almost universal approach to EHR development adopted by vendors and does not make it easy for health data to be shared.

I have seen and heard some say that we already have all the standards that we need for eHealth. This is still somewhat controversial and perhaps depends on what part of eHealth that you are trying to make work. For a coordinated eHealth system the desire is for each standards to not only achieve its purpose and goal, but to harmonize with all the others in existence to create a unified whole. Can this vision be achieved? There are certainly some examples of very successful standards.  There are also some examples of tweaking of standards for local use... which makes them non-standard again. There are also some examples of standards that have never yet been implemented... what? Let me refer you to the blog post from my colleague - The Crisis in eHealth Standards, by software engineer, Thomas Beale - for an erudite discourse on the strengths and weakness of standards and the standards processes.

2. Human interaction and activities

There is no doubt that some EHR technological achievements have been delayed or even diverted by the human, political and regulatory issues arising from practical implementation - and in most instances, rightly so.  We can develop a technological solution, the 'what', but in many jurisdictions the 'how' still has everyone tied up in knots.  For example we have technical solutions for unique patient identifiers, data security, and role-based access to data - but 'how' to apply these in practice is more elusive, often crossing into moral and ethical arguments (including confidentiality and privacy), requiring broad social and political agreement and sometimes supportive legislation. These issues have received a disproportionate amount of attention, particularly in the media, and perhaps at the expense of issues that follow which are not so well understood, yet!

Healthcare is not primarily a technical business - it is about people. Yet in our rush towards EHR development we seem to have focused on the EHR being a technical solution rather than merely a tool or medium to support the practical application of health knowledge and provision of healthcare to real people.  Some of the most underestimated and misunderstood problems in EHR development are related to:

• the scope and dynamic nature of our health knowledge domain;
• the nature of the human-human interaction that underpins quality health care;
• the approach to capturing and storing the essence of a clinical encounter; and
• the changing clinical requirements, processes and approaches to healthcare provision.

None of these are trivial concepts.  They are in the metaphorical 'EHR too hard basket', but we need to address them...

Health is possibly (more likely, probably) the most complex knowledge domain.  The extent and scope of health-related knowledge that needs to be represented in an EHR is enormous - it has huge breadth and depth, plus a fine web of complex relationships.  Most commonly underestimated is that health knowledge is dynamic - requirements distilled from a clinician and built into an EHR application by a software engineer today can be out-of-date by the time the product is launched.

An encounter between a clinician and a patient is a very complex pas de deux, an intricate communication dance between two parties.  Interestingly we clinicians have developed surprisingly effective written methods to capture the information exchange from these encounters, with all the required subtleties and nuances. Capturing the essence of this encounter into a format that can be stored, re-used, queried and shared on a computer is a daunting task and more complex than first appears. Attempting to represent both the data and our clinical processes via the user interface on a computer screen is definitely also an advanced task.

The nature of healthcare provision is also in flux. Consumers/patients/clients/citizens/individuals are increasingly mobile, more now than ever before, demanding healthcare from a range of providers in varying geographical locations.  Gone is the old-fashioned notion of the local family physician providing all our needs for all generations of the family; the local physicians are morphing into our health coordinators and facilitators in a world of collaborative and distributed models of care. Our ability to diagnose, treat and prevent conditions are moving with the assistance of new technological advances - in particular, watch out for the potential tsunami-like impact of personalized medicine/genomics on healthcare in the next few years.

3. Information exchange

There are many differing approaches to sharing health information. Why? The plain answer is that it is hard and there is no clear way forward; there are also many differing requirements and starting points:

• Logically, the technical task of sharing health information would be easier if the data was in a common format. Conversely sharing seems to become more difficult by orders of magnitude if our collective data structure is in chaos.
• Practically, some require only the simple exchange of a readable document such as a PDF or semi-structured documents. At the opposite end of the scale, there is need for EHR systems to share detailed and structured health information, so that not only can clinicians and patients read it but the meaning of each piece of data is clearly understood and it can be directly integrated into the computer and utilized in clinical decision-making - this is known as semantic interoperability.

In many places, national eHealth programs and the myriad of 'ruggedly individual' EHR vendors are pursuing technical approaches to data exchange through the set-up of information exchange hubs, message mapping and data transformations.  In this instance the focus is on exchange of complete or semi-structured documents as readable health information. Europe and some other parts of the world are taking a different approach, focusing on the exchange of standardized, atomic data  and reflected in the European decision to adopt ISO/EN 13606 as its standard for EHR extract exchange.

Exchange of unstructured health-related documents as 'blobs' of data is a great starting point, but in the long term it is a dead end. In reality it is not a sound basis for a shared EHR, nor interoperability, as we can only read them and then store them passively within the EHR. Personally, I want a dynamic, lifelong EHR for myself and my patients - one that can actively create, receive, integrate and re-use my atomic health information and put it to work for me to improve my current health and to provide the basis for future health decisions.

'Provision of the right data to the right provider at the right time' - can this actually be achieved? Clearly the relatively safe, comfortable and incremental technical innovation that has underpinned our EHR development to date hasn't provided the shared EHR solution we hoped for. So at this point let us draw from the wisdom of Einstein: “We can't solve problems by using the same kind of thinking we used when we created them." Indeed, perhaps it is time for a different approach to the shared EHR; one in which we divert our focus and are encouraged to push boundaries; to seek transformational change in our approach to eHealth.

In future posts, I hope to explore some of these issues in more depth and, in turn, some opportunities that arise...

Acknowledgments: Dr Sam Heard and Dr Hugh Leslie

Waving in eHealth

I’m excited and optimistic about Google Wave. In my mind, its key strength is as a brilliant hybrid medium for complex, small group conversations:

• allowing tightly focused, tree-like threads, through contextual inline replies;
• synchronous & asynchronous collaboration, wherever useful or most appropriate; and
• inclusion of shared resource files.

So, Google Wave in eHealth - how could it be used?

A few thoughts...

1. Health Conversations

• For private use...

For Patient to Patient or Clinician to Clinician conversations, Wave is a great way for individuals to share thoughts and information on any topic, health included, and no matter what the personal or professional purpose. However if the topic IS health, then there also should be a caveat that the Wave doesn’t contain any private health information. It is not unreasonable to assume that sharing health information in Wave is similar to that of using insecure emails – so just don’t do it!

• For use in healthcare provision...

As a vehicle for a dialogue between Clinician and Patient, Wave is great but it is important to keep in mind that this is not just your average chat, but another format of an online consultation, and all the complications that this brings. If Wave is embedded in an appropriately secure environment, such as an existing EHR/PHR platform with appropriate privacy provisions/authorizations etc. and where versioning of the Wave could be recorded to support the medico-legal record, then Wave could be a great tool in eHealth.  Remember that this is a preview and it is a new technology, so there will be hiccups as we all learn to use Wave - there is a significant overhead to using Wave effectively.

One of my first thoughts re the potential clinical use of Wave was how it could have enhanced a Personal Health Record (PHR) that was developed for use by older children and teenagers with Insulin Dependent Diabetes at Royal Children’s Hospital, Melbourne – BetterDiabetes. There is a component within this PHR where the teens can request online assistance and advice from their Diabetes Nurse Educators (DNEs) for management of their diabetes. Armed with appropriate authorization and access permissions, the DNEs can view selected parts of the BetterDiabetes record, including glucose measurements uploaded only minutes beforehand, making informed and making real-time responses back to the teens regarding proposed changes to their care. In the online version of BetterDiabetes the secure messages flowing back and forth are similar to email, but embedded in the PHR – asynchronous, fragmented and clunky. If this was able to be transcended by a Wave-like tool for communication it could be a very useful vehicle for collaborative healthcare provision. The provision of timely information flow in both directions, and including addition of external files to the ‘Wave’ could be extremely valuable.

2. EHRs & EMRs

Wave is NOT appropriate for an EHR/EMR platform. Formal health records should be based on standards such as ISO 18308 – ‘Requirements for an Electronic Health Record Reference Architecture’ and ISO/DTR 20514 – ‘Electronic Health Record Definition, Scope and Context’. Now Wave may be very useful as an interface for communications within that EHR framework, form or structure, but it is definitely not the basis for "…a set of clinical and technical requirements for a record architecture that supports using, sharing, and exchanging electronic health records across different health sectors, different countries, and different models of healthcare delivery." Of some concern, there are some public Waves that are promoting Google Wave as the newest medium for EMRs. One public Wave as an example is: Electronic Medical Records (EMR) and Medical Information Systems: Is Wave the future of electronic medical records? which includes an EMR example.

By all means let's embed the innovative Wave interface for use within a formal EHR/EMR but we need to be careful if we are expecting more from it.

3. Clinical Decision Support

Phil Baumann’s ‘A Clinical Infusion of Google Wave’ blog, featuring Clinybot, is a fascinating, futuristic view of Clinical Decision Support provided for clinicians. Phil states that he assumes all privacy and security aspects are OK when proposing Clinybot - agreed. However, the missing ingredient in Phil’s proposal is not unique to Clinybot but the reason why we have so little Clinical Decision Support in practice. In order for Clinybot to function as described it would have to have a clear semantic handle on the data structure underlying it. Clinical Decision Support can be and is developed on a per EHR/EMR basis, however standardization of clinical content would enable universal applicability of Clinybot across all EHRs and EMRs. The combination of Clinybot and standardised content could be a very powerful potential partnership.

_____

I’m a pragmatist; definitely not a futurist. I’ve seen some predictions and anticipated uses for Wave that I think are very optimistic, maybe even a little far-fetched. Perhaps these things might happen... probably not.

And of course there are issues and drawbacks to Wave. Tech Crunch's Why Google Wave Sucks, And Why You Will Use It Anyway is a pretty good heads up to the reality of Wave at present.

For the moment I'm more than happy to explore how the benefits of the complex, small group conversations can be leveraged in healthcare, and particularly my clinical modeling work with openEHR. I will keep an open mind to see how Waving in health develops.