A Centralised EHR?
Over-the-coffee-cup conversations that attempt to solve all the worlds problems (or at least the ones worth solving) are not uncommon. Recently the theme of the centralised EHR has resulted in much caffeine intake. A number of us have worked on large centralised EHRs and almost universally the feeling is one of "I wouldn't do it that way again". Very few jurisdictions can afford to spend significantly on EHR programs and centralisation is a significant driver to cost bloat. Furthermore, practical experience shows that centralisation drives complexity, and leads to less that successful implementations. I've started to capture some of the ideas on other approaches in my blog (at http://wildfauve.blogspot.com/2010/02/what-centralised-ehr.html). Grab a coffee and join the discussion.




What is 'Centralised' EHR?
Hi, I think we must first define what it is really. I think the scope of EHR is all that matters here. So it is obvious that it is not a good idea to have 'one' repository which will hold ALL health information - including X-Rays and details of Lab results etc. But on the other hand if you don't centrally manage an optimum (NOT minimum) level of information you can not manage distributed systems either. So the discussion should be around 'what should go into centralised EHR' in the first place. I'd be interested in your and others' thoughts on this.
Koray Atalag
What should go into a Centralised EHR?
This is probably the $60,000 (or in some countries, $5bn) question. After being involved in architecting a centralised EHR for the NHS, my first tendency would be to say nothing needs to go in the centre. I'm going to ignore secondary use--which is typcially more difficult to solve in a distributed architecture. I think the idea to centralise or distribute is a architectural pattern/mechanism, rather than something you would see driven from requirements. If we accept that, then we need to look for non-functional, rather than functional, requirements for centralisation. These tend to cluster around performance, scaleability, ease of processing cross-record inferences, security. So, if the networks are slow, the care setting systems unreliable. the architectural approach can lead towards centralisation. That is, centralisation is a constraint-driven architectural approach.
I also think that, due to patterns extant in the industry established by data warehousing (maybe the EHR is a warehouse of distributed EHRs) that centralisation is simply a commonly agreed mechanism amongst EHR planners (you wouldn't get fire if....etc). Additionally governments tend to like having information where they can see it (distribution is the enemy of a properly administred democracy!!).
We do see PACS moving towards centralisation (well, centralised within a federation of care setting systems, rather than nationally). I think this is a good example of non-functional requirements (in this case performance, cost of storage, etc) driving centralisation rather than the functional requirements.
There is no real use case on the web that drives for centralisation (accepting, of course, that some sites will be more successful than others and therefore might seem to be a move towards the centre). Distribution is the base premise of the web architecture. We also see that distribution drives federation (such as OpenId, RDF, API integration [such as Tweetdeck]).
When we were building the central EHR for the NHS one of the main drivers was the processing of "rules and workflows" across patient information. The end result was that nothing was implemented because of the many functional and safety concerns related to machine-independent processing of health information (the e-Patient Dave saga probably indicates that these concerns were valid). Architecturally this could have been done using a distributed approach as well. For example, graphs of patient information (from across the health web) represented as RDF can be developed that can execute inferences resulting in changes to the patient's resources (such as creating an iCal appointment for a check-up). This approach could even be used for secondary use. Perhaps here we have a need for centralisation--the inference engines that act on health data.
Perhaps we need to explore the functional scenarios that might lead to the architectural need for centralisation. Perhaps we will find that in reality there may be very few needs that drive centralisation.
centralised EHR
As a health professional - what would i want access to about a patient, regardless of the setting i am working. This determines for me what I would want in a centralised EHR
On first thoughts - Results, summary of health events, alerts and allergies, other health professionals involved in care. Medication history, what has been prescribed, used and effectiveness / outcome and a Health promotion plan.
As a patient what would i want shared - this would be what works for me, my medical and health history, therefore health professional know may health history and how it might related to a current event, and also know what works and what doesn't. That would save time and help me get the best use of consultation time.
simple really
Louise Miller
Post new comment