Hospital systems are overcomplicated

That’s quite a bold statement. It is designed to make people think. Is it one that I agree with? Unfortunately the answer is yes and no. They are complicated, the question really is do they need to be so?

One thing that is pretty clear is that the information in a hospital system can be presented in a way that is clear and simple and all system designers and developers should endeavour to do this. Some people believe that this should be different depending on who is seeing the information but I disagree, clarity and simplicity is as useful to a clinician as it is to an end patient. Can this simplicity be designed in – absolutely.

I will concentrate this piece on patient data. That is, after all the most important data in any hospital system and the part currently in the headlines here in the UK, the USA and indeed worldwide. The concept of an Electronic Health Record (EHR) for a patient that holds all of their data is a powerful thing. Traditionally most of a patient’s data has been in their medical ‘notes’. Large files of paper that have to be physically transported around the hospital, or indeed between hospitals. For this information to be available, at any time, to the clinicians and indeed to the patients themselves is the target for all systems.

This target was met, many years ago, for clinician access, by hospitals using the open-source Vista system which is why it has become the focus of attention for the NHS in recent times. To be fair, other (mainly proprietary systems) have also gradually approached this state.

The structure to hold all of a patient’s data look pretty straight forward. Indeed there are many agreed, some simple, some not so, frameworks for this. One which is gaining popularity is the Royal College of Physicians Core Clinical Headings but unfortunately (as is often the case) the detail of this is very UK focused. That doesn’t stop the core headings being a good place to start when designing a system though.

In a simple form these include: (there are others but this will do for the purpose of this document)

  • Demographics
  • Procedures
  • Diagnoses
  • Problems and Issues
  • Investigations and Results
  • Medications
  • Allergies

So a simplistic model is

Patient has

  • one set of Demographics,
  • none or many sets of Medication
  • none or many sets of Allergies
  • etc

That design is easy for everyone to understand and very easy to reproduce into a user interface. It also fits very easily into a Json, hierarchical, or even a relational structure

e.g. (very simplified)

patient:{
         Demographics:{
                       name: Fred Bloggs,
                       Identifier:12345
                       }
         ,[{medication1:{
                        name: ibuprofen,
                        dose: 200mg,
                        frequency: hourly
                        }
           },
           {medication2:{
                        name: aspirin,
                        dose: 500mg,
                        frequency: daily
                        }
           },
          ]
         ,[{Allergy1:{}}]
         }

One of the beauties of the JSON form is that it is sparse. This means that not all definitions need to be present. This would allow a set of standards to be developed that could encompass different internationalization options.

So why would you not simply design a database this way? Picking up a patient record set would be simplicity itself and the front end designer could then just lay out the data in the most natural form.

Actually for once (and you won’t hear me say this often) the relational form makes the most sense in terms of overall usability and maintenance if it were as simple as this. Having different tables for the patients medications, procedures, allergies etc make it much easier to maintain and expand, especially as it is likely that different hospital departments will be dealing with each. Unfortunately medical records are never that simple and the structures of the underlying data tend to change between locations and types. Relational forms just cannot handle this so the more flexible json definitions work much better.

One of the major arguments for using a relational structure used to be space saving. By reducing everything down to third normal form you save space by not duplicating anything. This was at the cost of simplicity. These days with the power of computers and the abundance of cheap storage a data form that is readable and understandable by anyone is far more important. Data these days is to be shared and distributed not locked away in a database that only programmers could access.

So back to the original concept. Why would you not design a system totally around the patient in this way? The answer is that while this might be the best way to store data for simple retrieval it may not be the best for updating or analysis. The first, and most obvious, reason is access to the data by anything other than patient. Yes it is easy to get everything for one patient but what if it was necessary to determine how many patients have a specific drug subscribed?  The simple answer is to define indices but the types of database that support saving JSON data structures each have their own way of doing this and it requires careful analysis and design (the same as in more traditional databases). To retrieve this data you will also need to use the database specific query languages. This takes us away from the original concept of a universal and simple approach.

Another issue is aggregation of the information. Each layer of people in the organisation needs to see the information in a different way and at a different level. This is exemplified in the ClinUIP application that I wrote for Tony Shannon as it shows the high level views that would be required by executives and managers and allows them to drill down the the fine grained information required by doctors and nurses.

This also does not answer the most important question. Unless this is a very simplistic system then what is needed are controls over the data. For example what about checking allergies and potential cross-drug interactions when prescribing a new drug for a patient? The first could be done by retrieving the full patient record but the second requires somewhat more careful thinking. Whilst this is not necessarily related to the underlying structures it does highlight just one of the very complex rules that need to be checked as part of an application storing this data.

One of the main reasons why the VistA system is so well regarded is that all the data integrity and the clinical decision controls are built in and have been tested and enhanced over 30 years. If all that is needed is to simply dump patient data into an easily retrievable form and assume that the application programmer has designed all the rules and constraints then the structure itself is fine. Unfortunately this is not the world that we live in and very rarely is a greenfield system designed from scratch. Unfortunately the VistA system is anything but JSON structured however work being done by Rob Tweed, myself and others is beginning to allow the VistA system to be viewed as JSON structures. There is also work being done by the VA themselves with their Virtual Patient record (VPR).

Indeed JSON seems to be becoming the de facto lingua franca for modern medical systems, gradually overtaking XML simply because it is so simple to use and read. This was the original promise of XML but it gradually got more and more complex and bogged down in definitions. Work going on in the standards committees is moving towards JSON being available for HL7 (the standard for all exchange, integration, sharing, and retrieval of electronic health information), Josh Mandel is also leading enhancements to the smart platform to make it JSON compatible.

So is this the solution? Don’t try to start from scratch with nice simple structures but instead enable existing systems to make them look like this? It certainly is one answer. Another might be to have an intermediate database that is structured this way and retrieves and updates simple structures from the core hospital system as and when needed. This allows the controls and logic to remain in the core but provides a simple and straightforward way for user facing designers to present the patient information.

So yes, hospital systems are over-complicated but there are now ways that mean retrieving the data hidden within them no longer needs to be. The key conclusion for me is that JSON data structures are the future, these should be available in an internationally standard form. and this is what UI developers should be using for applications.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: