Structured Mess Medical Records

Medical records are distributed and will not be centralised, applications and file formats will not be standardised. A system that recognises this is desirable.

What Sort of Bucket?

While a single file per patient is an interesting concept, and defines the difference between EMR based on a single database, and a document EMR, in practice the container is likely to be a directory or an object repository. What is essential is that objects can be cleanly copied out of and into such containers.

Some of the fragments in the container will point to parts of the record on other servers, for instance images in the diagnostic imaging department.

As a simple model, consider the arrangement which appears to underly the Exeter GP System's handling of patient letters.

For each patient there is a directory, and the software knows that it should look in that directory for any loose files relating to that patient. Each directory has a name derived from the patient - their practice identity number, which must be the most sensible way of doing things. This could be cumbersome in a large practice, and there is some merit to following the model I applied to my letters outward viewer, when the number of letters became large, and using a hierarchical tree with subdirectories named for the initial digit of the patient number, and then directories or documents per patient below these.

However one arrives at it and arranges it, giving each patient a folder in which their notes are stored seems an uncontroversial idea. The resulting arrangement is of course highly suitable for an intranet approach to managing the files.

File-Types Ad-Lib and the Rules

There is no significant likelihood of the two conditions for a satisfactory single central solution being satisfied - that a standard is adopted uniformly by everyone, and that that standard is in fact the best achievable and remains so. Therefore we need a set of rules which will work in the way the Web has, rough concensus and running code.

The most obvious rules are that any file-type may be dropped into the patient's folder, subject only to being identifiable and to their being a viewer of some sort which can be distributed with it and can take it's cue as to which patient file to show from another program - the medical record master viewer.

Thus we recreate the "structured mess" of the existing paper-based medical record. The gains of doing this are noticeable, the merits of the electronic record, that much of it is liable to be legible by being typed rather than handwritten (many doctors should be obliged to distribute a viewer capable of interpreting their handwriting with every document they produce) that it can be made available at places and times widely separated and simultaneous, and that when it needs to be moved it can be moved very rapidly. Right from the start we have defined a system capable of holding images, or links to images held elsewhere, which moves beyond most existing medical record systems.

Further gains can be made in an incremental fashion, with the structure of individual documents, and the cleverness of the viewer programs for them increasing steadily over time.

How do we manage this mess? The Thin Controller

Using XML browsers and XML documents for much of this is the likely end. Starting with simpler browsers and somewhat marked-up text is the beginning.

The master medical record viewer should start off as a very simple program able to keep track of the users who are allowed access, and to maintain an index of patients or find them in some other way, and fire off other programs or applets to show the records. As time goes on this thin controller may become a rather fatter controller, but the temptation to build much into it should be resisted. Free-standing medical logic modules from various sources could be applied alongside it, but in many ways it's most important interfaces are likely to be those with the word-processor and the e-mail and web-server applications in the organisation.

Access Control

One class of document in the bucket may be a prepared (or virtual, prepared on the fly) summary for out-of-hours doctors, or for specialists to whom the patient has been referred. If the NHS was running in real time then the details in a semi-automated referral letter might still be current when the patient reached the clinic, but in the current state this is unlikely. A link to produce the details up-to-date would serve us well.

Similar documents could be defined for dental history sharing, for Physiotherapy referrals, and any other category of sharing of care.