switch with cables

We have discussed the importance of shared vocabularies in electronic health record  systems and interoperability, but this is not enough. In order to successfully build interfaces between EHR systems, we need to understand them in functional terms, and we need to understand how those requirements are realized in actual systems. Unfortunately, different products have been developed to meet different business goals, and often have different priorities.a

Fortunately, healthcare has a long history, and there are familiar procedures that are more or less standard. Examples include admitting a patient, writing a prescription or a lab order, entering progress notes, patient education, and so forth. To be successful, an EHR system will need to be as familiar and useable as possible. It can succeed best by remaining in the background and cause as little disruption as possible.

That’s all well and good, but real systems still need concrete requirements. One approach has been to for standards organizations to spell out formal, if non-exhaustive requirements. One such effort ISO 18308:2011(E) Health informatics – Requirements for an electronic health record architecture. Another is the HL7 EHR standard. It is probably best to view these documents as frameworks. Further elaboration will be required to develop requirements for a real system.

In this post, we focus our attention on ISO 18308. Following the usual practice in software development, it begins by  focusing on “business requirements”. Examples include:

HSO3 The EHR should enable authorized users to access health information seamlessly and as originally organized, independently of the EHR systems and of the physical formats in which it was originally stored.


HSO4 The EHR should enable the communication of all health information between care settings, subject to appropriate consent and access rights, to a sufficient quality to support safe shared clinical care.

These are very general requirements. HSO3 is another version of the concept that systems should stay close to traditional processes where possible. In effect, it’s the “principle of least surprise”. HSO4 is a related requirement that says, in effect, that moving from a paper system to the EHR must not involve a loss of fidelity. We must not take away from healthcare providers tools that they always had!

Moving on from these high level business drivers, we come to clinical practice objectives, which are a little more specific. For example,

CPO4 The EHR should enable the inclusion of health record entries about a subject of care, preserving the way in which they are originally organized as well as enabling re-organization and retrieval of information in a manner that is specific to different types of healthcare providers and care contexts.

This particular requirement continues with the theme of the principle of least surprise, but is a bit more concrete in that it focuses on how the information in the record actually appears, and how it can be organized. (By the way, if you think I’m being intentionally selective here, you are right. I really do think an important objective of any EHR system is not to get in the practitioner’s way.)

Another interesting requirement is that the EHR must not stand in the way of progress:

CPO8 The EHR and EHRA should be flexible enough to allow for future evolution in the understanding of health and for innovations in healthcare, such as new forms of clinical knowledge, new clinical disciplines, and new clinical practices and processes.

Healthcare is always evolving, and software must not hinder the incorporation of new knowledge, or the adoption of new technologies.

The standard then moves to a new level of concreteness by considering the kinds of information to be stored. For example,

 KIN3 The EHRA shall be able to represent reported, assessed and measured observations, including scales, measures and scores.


KIN8 The EHRA shall be able to represent preventative and wellness information such as health assessments, prophylaxis measures and lifestyle.

There are other sections of this standard, but this should be enough to provide a general idea of the approach. There is a lot of hard work that goes into turning these high level requirements into specifications for a real system. But perhaps that is the strength of this document. It keeps our eyes on the problem(s) we are trying to solve, when we can so easily become mired in the details of a particular approach to addressing them.