Tuesday, February 05, 2013

Why are we still using paper charts?

I suggested I may comment some more on some observations about the way basic clinical observations were taken and recorded during my stay in hospital.
"A large part of the nurses' work with with me was routine monitoring of vital signs. This was managed on a paper chart and my thoughts on this will be the subject another blog entry."
 The parameters being measured were:
  • Blood pressure
  • Pulse rate
  • O2 Saturation
  • Temperature
There were three digital machines used to do this, and they were able to work in parallel reducing the job of taking these observations (if done most efficiently) to about 15 seconds. In fact if the machines were provided I would have been able to do all this myself from very early in my post surgical recovery.

These digital machines produced numbers on their LED displays which were then transcribed into a paper chart - taking about another 30 seconds - or longer if a new chart needed to be started. The chart was referenced regularly by all clinicians who visited me - including surgeons, physiotherapists, dietitians, nurses at handover, etc. and was not particularly easy to use - compared to , say, a well designed tablet app.

If we are serious about moving to an EHR then it would seem obvious to me to start with frequent tasks like this that capture data that is regularly used.

Eventually I would expect the measuring machines for these fundamental measurements to be capable of wireless transfer of data to a simple online record.

Right now, I would expect that an inexpensive tablet with a simple application linked to a simple online backup system so that data is not lost with the tablet would make it easy for nurses to transcribe data and for the clinicians who want to view it. This is a simple and easy to take step towards an EHR. If the hospital decided to implement an EHR then this application would be trivial to integrate.

I am sure there are other use cases for other clinical processes (medications is an obvious candidate) that could be the target of another app.

After all, what is an EHR really if not a collection of data required to meet a set of identified use cases for well defined clinical work flows and processes?

This could be achieved using a set of apps on tablets tied together with simple and bullet proof foundational infrastructure for identity management, authentication and data retention. By the way, it is important that the infrastructure should be content agnostic - leave content management to the apps.

Why spend a fortune on an "integrated" clinical EHR system when a collection of apps that can cooperate with each other will fill the same need with a much lower entry cost while providing a flexible platform that will support innovative solutions and avoid vendor lock in?

Why can't this approach then be broadened to include use cases that cross the hospital-GP boundary, or GP - allied health? The same simple, bullet proof infrastructure extended beyond the hospital walls could support a variety of extremely interesting applications - but it is most important that we do not try and make it deal with clinical content. Leave that to the people developing the apps.

The current PCEHR has most of the attributes required to provide the supporting infrastructure here - the only thing wrong is that it is a PCEHR and defines mandatory clinical content for all documents. I think this is the single biggest flaw with the current PCEHR approach. The infrastructure would be far more useful and usable if it could be used to share information between apps. Leave decisions about the content of documents in the repository to the people developing the applications - including the current PCEHR application.

Regarding standardisation, I think it would pay to design a market for this ecosystem that will encourage developers to design, develop and eventually standardise methods for sharing data and coordinating work flows and user functionality.


No comments: