Electronic Health Records

This blog is the first of a series of extracts from a long paper on Electronic Health Records that I have been maintaining and revising since 2008. It’s been shared on a limited basis and has benefit from review and input by a number of individuals,  particularly fellow members of the BCS Primary Health Care Specailists Group www.phcsg.org

I have been prompted to share this ahead of the NHS #CCIO Tweetchat 7-8 pm BST on 8th May

This first extract deals with the purpose and content of EHR’s and I hope will help inform the debate.

1      Purpose of Health Records

Health Records need to support a wide range or purposes, which can be divided into three broad areas these are described below.

1.1   Directly supporting the delivery of care to individuals

This category includes both clinical and administrative activities that are necessary for the delivery of care to identifiable individuals including:

  • The provision of an aide-memoire for those responsible for the delivery care.
  • As a means of communication within teams responsibly for the delivery of an aspects of care.
  • As a means of communication between teams responsible for the delivery of different aspects of care.
  • The provision of the data need by decision support tools design to facilitate the delivery of quality care.
  • The provision of data to support workflows and clinical processes required for the delivery of care.

The record has to support the needs of all those involved in the delivery of care which includes healthcare professionals, administrative personnel, family and informal carers and patients themselves.

1.2   Supporting the Health of Populations

The category includes all those uses that are concerned with the health of populations and the development of health knowledge. These uses don’t offer a direct and immediate benefit to individuals, often don’t require identifiable personal information and are often referred to as secondary uses. These uses include:

  • Healthcare planning and commissioning
  • Public health and epidemiology
  • Risk stratification and risk scoring
  • Predictive modelling
  • Drug safety surveillance and pharmacovigilance
  • Clinical audit and outcome measurement
  • Population based healthcare research
  • Identification of subjects for clinical trials

1.3   Providing a Medico-Legal Record

Those providing care need to be able to demonstrate that they did so with due professional care, recording relevant information appropriately and acting reasonably on the basis of the information available to them. The medical legal record needs to meet the requirements laid down by statue and common law for the admissibility of evidence in both civil and criminal proceedings (principally the “Civil Evidence Act 1995” and “Police and Criminal Evidence Act 1984”. A medico-legal record needs to:

  • Be able to reliable represent the record as it would have been at any particular point in time
  • Securely represent the provenance of information recorded
  • Ensure that information once recorded cannot be repudiated
  • Provide an audit trail of additions, changes and access to the record

2     Content of EHRs

The electronic health record is probably the most complex entity that anyone has sought to computerise (it is certainly the most complex entity with wide applicability) and is much more complex than records found in the financial sector, eCommerce or aerospace.

Health records contain all data types and much of the information is implied by the context and relationship of data items within the record.

Health records also have a much greater working life than most records in other domains with some information recorded early in life remaining highly significant in old age.

Health Records include information about the patient including:

  • Demographics
  • Reasons for encounter
  • Presenting problems
  • Symptoms
  • Diagnoses
  • Physiological measurements and vital signs
  • Results of tests and investigations
  • Allergies, adverse reactions and intolerances (to drugs, foodstuff, and other substances)
  • Family history, genealogy, genetics  and relationships
  • Social circumstances
  • Health beliefs and preferences
  • Employment and occupational exposures

In addition, it may be appropriate to record some items of history that were not recorded contemporaneously in the record (i.e. history of surgical procedures.)

Records will also contain data about the process of care including:

  • Encounters and episodes of care
  • Tests and investigations ordered
  • Treatments order, prescribed and or administered
  • Procedures ordered and carried out
  • Preventative
  • Advice given
  • Appointments scheduled
  • Goals and care plans
  • Outcomes
  • Details of entitlements to care
  • Cost of care

Data types include:

  • Narrative text, typical sections of 10 to 300 words, but sometimes longer
  • Items represented using controlled terminologies sometimes using multiple terms in combination (the leading terminology SNOMED contains three hundred thousand concepts and over one million term)
  • Quantitative information ranging from items with a single value to items with 10 or more associated numeric values.
  • Images ranging from simple (but important) sketches, through standard resolution photographs, video, still and moving x-ray and ultrasound images to very large high resolution, 3D images from body scanners.
  • Sounds including speech and clinical body sounds.
  • Analogue and digital signal data from diagnostic and monitoring equipment

Time for Zero-Tolerance

I heard the blindingly obvious statement at the recent Intellect stream of BCS HC2013 Conference in Birmingham that “If you give people software that makes their life easier then adoption is not a problem” Given the clear truth of this statement, I wonder why so many “designing” and procuring NHS IT Systems manage to deliver systems that make life more difficult for frontline staff undermining the quality and service they are able to offer patients.

If we are to get the benefits proposed by those promoting a paperless NHS this has to end and we have to introduce a regime of Zero-Tolerance for systems that make life more difficult for frontline staff.

How do we do this? I have some suggestions:

  • Transparency – Let’s encourage NHS Staff to name and shame systems that make their life more difficult, with reviews and rankings published with maybe some new categories in the EHI Awards for good design and something akin to the “Golden Bull Awards” for the worst examples. Let’s be honest, when the Emperor has no clothes, too often I hear positive comments about NHS IT systems in front of senior management which evaporate when you talk to frontline staff in private. Both sides are to blame here, management can’t be expected to recognise the problem when they are continually told that the “heap of crap” they ask staff to use is “powerful fertiliser” and senior managers need to reward those who bring them bad news.

The work of Psychiatrist Dr Joe McDonald, who is one of the most insightful observers of UK Health IT, with www.comparethesoftware.co.uk could provide a good start as could ideas from NHS Hack Day about a broader NHS Bugs reporting system.

  • Participation – We need to engage in agile user centred design that allows developers to truly understand and deliver against frontline end-user needs. This means embedding domain experts and end-users and their customers/patients in development teams through the entire product life-cycle (but not for so long that they “go native”) and careful testing of software in real situations with realistic data.

We also need to involve frontline staff in procurement decisions, but not in the tokenistic way that often happens, at the very least they need a veto and ideally it should be they not IT departments or senior management making the final choice.

  • Design – Design, design and more design. Good design ensures form-fit-for-function and should create software that is lusciously desirable, highly functional and which adapts to and remembers users’ needs and preferences. Design needs to be all pervasive. Software code should be finely wrought, poetically beautiful and lovingly commented adhering to clear and consistent coding standards. Workflows should careful designed to provide efficient process flows and be capable of adapting to real-world variation in process. Information presentation should apply the science of information design and excellent graphic design. User-interface design should similarly apply both science and art, to create interfaces that are beautiful, intuitive, accessible and safe. Good design requires input in the development process from technical, creative and human-factors designers. There is a wealth of literature and experience to help system designers if they just go and look for it.
  • End the dataset mentality – Except in exceptional circumstances only the information that is necessary and appropriate to the delivery of optimal care of the individual patient should be collected. This includes information to support both clinical and supporting business processes and the measurement of outcomes, but not data for purposes which can’t directly contribute to good outcomes for the individual patient. This information varies from patient to patient and encounter to encounter and can’t be useful expressed as a mandatory minimum data set. Data sets are never minimal but inevitably fail to include information that will be critical in some cases. The quality of data collected under duress which has no value to those collecting it, will be poor as users will guess it or make it up if it is not immediately to hand making it worse than useless for the purposes for which it was included in the dataset in the first place. Users have a natural investment in quality of data that affects the ease with which they can do a good job and typically such data is information rich and secondary uses can in general be better satisfied by using only such data. However, in exceptional cases where there is a strong downstream benefit from the collection of additional data this need must be “sold” to users who should also be provided with regular feedback that demonstrates that efforts are worthwhile.

While there is massive potential in using data collected routinely for secondary purposes, those doing so must always be aware of the risks of using data for purposes other than those for which it was collected. If those entering data don’t know about the other ways data they are entering will be used they can’t help ensure that it is also fit for these purposes. I would not go as far as the eponymous Dutch health informatician who coined Van de Lei’s law, “Data should not be used other than for the purposes for which it was collected”. However, it is important to understand the many data quality issues associated with health data  and the risks of using data beyond the “Hawking Horizon

One way of mitigating these risks is to inform those who collect data how it will be used and to feed back to them the results of its use. This will not only encourage them to consider how they can make fit for these secondary purposes, but will also mean you are more likely to be alerted when you draw conclusion that those close to the data know they do not support.

  • Finally of course Zero Tolerance – Zero tolerance for systems that make life harder for frontline staff, zero tolerance for those who fail to involve frontline users in design and procurement decisions and zero tolerance for the dataset mentality and most of all zero tolerance for poor design.

Healthcare and Banking

NHS leaders often make comparisons between the use of IT and digital service in banking and health. While we have much to learn from other sectors I feel this comparison means that those who make it don’t fully understand the challenge.

What banking systems do is fundamentally very simple – They move money (unambiguously and simply represented by a number and a currency) from one account to another. There are some challenges around identity assurance and security, because people don’t like to lose their money and some would quite like to steal it if they could, but basically a banking record is very simple, just look at you bank statement.

Compare this with a medical record which contains every data type known to man. Structured and coded data (based on large and complex terminologies and models of use and meaning), rich unstructured narrative text, complex numeric data, images (from a GPs sketch through photos and videos to complex imaging studies) signal data (from monitors and measuring devices) and sounds. Add to this that much of the important information is not it the data itself but in the links between them and the effect that provenance and attribution has on meaning and you have what is certainly the most complex data entity in widespread use.

Finally, consider how much the banks spend on their IT compared to the NHS and also the quality of some of the online service many of which have nothing to teach anyone about good user centred design.

So while there are things to be learnt from banking and other sectors. There are serious dangers if we don’t challenge the unfounded comparison that NHS leaders keep making between health and banking I . They are not comparable problems.