3. PCAST – What it means to me

PCAST – What it means to me

I have found amusing the “elevator” impressions of the PCAST report from people in the healthcare IT community.  It has been called  “Microsoft’s PCAST” and “Google’s search for healthcare.”   Other comments include:

• Just what we need a new language
• They don’t know about SNOMED
• It’s basically a CDA so we’re on the right track
• Interesting idea but we have too much data to think about changing
• Bunch of people who don’t know healthcare

In all likelihood my own “elevator” impressions will end up in someone else’s list but here it goes.

I read PCAST to be a simple elegant approach to healthcare information management;  dead center where information management in general is heading.  Is it incomplete?  Yes.  Are there devils in the details?  Yes.

Is it Microsoft’s?  No.  They clearly contributed but this is not a prescription to use Microsoft.  Will they propose using new or existing Microsoft products to follow this path forward?  Of course they will.  Healthcare is too big to ignore.

Are there influences of Google’s approach to locating and organizing distributed data?  Yes.  If you have a big hammer a lot of problems look like nails.  Will that hammer work for this problem?  My personal opinion is that it will not.  Will that experience be useful in this distributed world?  Yes.

I will not walk through all of the examples.  Instead, let me describe what I think this report  means.  The core concept is that we need architecture that is robust in the face of change at all levels.  Implicitly it acknowledges that change (progress) will occur and describes an architecture that can accommodate change with little or no change to the architecture itself.

To achieve this (and other benefits) the report essentially recommends the creation of a singular logical patient medical record.  It spends some time addressing how the data are stored in a distributed world; how the individual elements of that medical record might be linked to one another; and how searching for data might be different from how the individual elements might be retrieved.  But the big point is that at the end there is a singular logical patient medical record.

Stated another way, the report guides us to utilize a contributory model of a patient’s medical record rather than the old custodial model.  In the custodial model, a provider has his or her (hereafter her)  copy of a patient’s medical record and  acts as the custodian of her part /copy of the record.  Other providers can request a copy of the copy.  There never is a patient’s medical record and changes to the part held by one custodian are not implicitly shared.  In the contributory model, there is, external to the provider, a patient medical record.  When the provider has information to add (or modify) she contributes that change to the record.  The provider is  not responsible for the record.  Providers  are responsible for contributing their information to the record.  Lest the reader get distracted by a devil, this approach does beg the question of how/who/where that record is persisted but that detail can be addressed and will be a topic I will post ruminations about soon.

So the first big message of PCAST is transition to a distributed and linked logical medical record wherein providers contribute to that record.  This effectively decouples the application from the data persistence.  In PCAST this is the “Data Element Access Service”.  It is this approach that logically leads to the conclusion that we need to transition from EHR systems to this new path.  To my read that is really a call to transition to a contributory model of medical records wherein applications and data persistence are decoupled.

If that is the first big message of PCAST there must be a second.  Yes there is.  From my perspective they choose unfortunate wording for their “Universal Exchange Language”.  My simple minded interpretation of this is that we should create an electronic container that can be used to move data around in a distributed world.  That container should be generic enough to hold any kind of data.  But being generic is not enough.  It needs to be interpretable (yes, I just endorsed the idea of language) by a system that receives the data.  They have suggested a technology (XML) that allows us to put virtually anything in it and allows the system generating the message (does sound more and more like a language doesn’t it) to describe what the data are (tags).

PCAST did not attempt to tackle how the tags are established.  That will require the use of vocabularies and ontologies.  There are undoubtedly going to be several dialects and as with other languages used by people they will evolve.  There may be places for dictionaries and translators (where is my Stedman’s).  Some applications will be multilingual.  Just as the Brits and the Americans both started with a common language there will no doubt be divergences that lead to problems in communication.

So the second big message is that the structure of the message should be decoupled from the applications and the data persistence and that the contents of the message should allow for a “language” of exchange without prescribing the vocabulary or ontology of that language.

While there are lots of details and devils, these two powerful points characterize the path forward I see on the map that is PCAST.