Christopher Feahr wrote:
Dear Group,
I have just recently joined your listserve, and have been actively
participating in the HL7 EHR ballot discussion for only a few weeks.
During the four years prior to that, I had been swimming in the
HIPAA-EDI ocean, trying to figure out how the operational costs for
450,000 smaller providers would ever be lowered under our transaction
rule. The answer is, "they won't... costs will increase". While HIPAA
is arguably "another story", but I believe that the failure of the
transaction rule to be embraced by our fragmented US provider community
is closely related to the elusive success of the "standard EHR" effort.
I have the distinct sense that our global EHR conversation is much
closer to the heart of The Beast for small providers than the HIPAA
slugfest will ever be... and much more likely to bring sanity to
providers lives. Hence, my keen interest in it. Nevertheless, I
sense an implied constraint throughout most of the discussions I have
listened to... caused I think, by the almost single-minded focus on the
attributes of the information *container*, rather than on the health
information, itself.
Containers and container systems were certainly a major constraint in
the days of paper, and most providers still seem to cling to that
"primary repository" or "medical chart" model even after "going
paperless"... as doctors like to say in the US. "EHR" discussions seem
to presume that we are still constrained by an overwhelming need for a
monolithic, physical record system that has to "live" somewhere... all
in one piece. Constraining every enterprise system to the same physical
record architecture is always denied as an ultimate objective of
"EHR"... although that *would* be a path to a fairly high level of
user-system interoperability... it's just that no one would agree to do
it.
I see the state of thinking as follows:
- existing providers, including hospitals, labs, GPs, will in many cases keep their existing EMR systems (all different etc)
- the shared-care health record is likely to be installed as a new system on a regional or even national basis in some places.
- what is standardised is the shared-care EHR and its interfaces. EMR systems have to send some percentage of their innformation to the EHR
- most likely, GPs will start using the EHR directly
- providers that decide to adopt the same technology as the shared care EHR will obviously have an easier time of shipping information in and out
Our analysis so far is that these EHRs will have to be "consolidated" rather than purely federated (i.e. pieces integrated in real time for display), since there are many problems with relying on feeder EMR systems to be responsive for real-time queries. These include different querying languages, different security models, differing latencies, network unavailability etc. Another major reason for consolidation is that soure systems may have all kinds of detail which is of no long term interest to the shared care, longitudinal EHR - hence some kind of filtering between feeder systems and the EHR has to occur. (Defining the filter functions will not necessarily be that simple.) A third major reason is that doing writes to the EHR can only be realistically be done to one place with a defined architecture. Doing distributed writes to a multitude of different back-ends has been proven many times to be nearly impossible to do reliably; to make it reliable would cost exorbitantly. The kind of communication needed to enable EMR <-> local shared care EHR communication can be based on contractual agreements set up in advance.
Regional EHRs would take care of most people, most of the time. However, there stil needs to be a way of enabing ad hoc requests and replies for situations in which patients have health problems in unexpected places. There also need to be communication mechanisms for patients who are always mobile, such as military, aid workers etc. These mechanisms will be virtual federation, supported by resource location/indexing systems.
So in the end, I believe a distributed system of consolidated EHRs, with will be the way to go.
EHR Dream #2 seems to be a Big-EMR-in-the-sky, with which all user
systems could remain synchronized. Again, that would certainly lead us
toward a useful level of interoperability, assuming that the most
trustworthy entity (the U.S. govt.? United Nations?) agreed to maintain
the repository-in-the-sky, to which over one million enterprise systems
would have to be rigorously mapped. But even if that were reasonably
implementable, it makes providers uncomfortable... the idea of their
records being "stored" with millions of "foreign" records in some far
off place (like India), rather than in the safety of their back rooms...
or just down the street... or at least in the same state or county.
Have we asked providers to sit down and *really* articulate these
fears?? These are paper-tiger issues.
firstly, anyone who thinks it is a good idea to put EHR data for e.g. US citizens living in Idaho, in India, has not studied the problem. Secondly, the issues of fear are not necessarily "paper tigers" - one fear that occurs is that providers who currently have total local control over patient information think they will lost control, or become irrelevant when shared EHRs come into being. This has to be addressed, and mechanisms for identifying who is managing the patient's health have to be thought about, to allow clinicians to continue to operate with confidence, even when their information is now part of a shared database.
Attempting to standardize PMS applications on a generic record format
for each major care domain/setting is obviously pointless. Doctors and
PMS vendors simply will not agree.. mainly because neither will even
bother attending the standards meetings. (note how enthusiastically this
community is embracing EDI under the federal mandate of HIPAA... and
how compelling small provider demand currently is for EDI-enabled
products. Lack of perceived demand is the main reason that small PMS
vendors don't bother attending SDO meetings to learn how to build them).
well... this situation is probably different around the world. In the UK, France, Netherlands, Germany, Australia...GPs are very interested in standardisation, and in the UK it has the greatest foothold in GP systems.
On the other hand, I believe that a standard *information* model for the
entire industry, with granular sub-models developed for each care
domain/setting... would not only be possible to create, but would pave
the most direct road toward useful interoperability. I believe that PMS
vendors would voluntarily respect such a standard... and would hugely
appreciate the freedom to design whatever record architectures they
wanted.
this is the work of openEHR, as you may have guessed by now....the key to understanding what is going on here is that it is a "two-level modelling" approach. THis is a new paradigm of modelling in which relatively simple, generic information models are developed (you can see them all documented at http://www.openehr.org/cgi-bin/document_list) and domain and business definitions are created in the form of archetypes, which is part of the "knowledge space", or second level of modelling. (See http://www.oceaninformatics.biz/adl.html for a primer on archetypes. THere are already two prototype tools that edit archetypes based on information models prior to openEHR; openEHR tools are now starting to emerge)
Step #1 would be to develop a universal *process* model, by
painstakingly abstracting the non-controversial requirements of
published, evidence-based practice guidelines. That will be the "heavy
lifting" and the part requiring documented and extensive vetting by
practicing physicians and other stakeholders. From the process model,
however, we should be able to spin off a universal information model for
Healthcare. Who would choose not to conform to such a model? Providers
will happily agree to execute care processes in almost exactly the same
way... according to standard-of-care guidelines.
well, I don't know if this is true. And in any case, process models are one way of seeing things, but not all clinical information is an instance of a process model. Our approach so far has been to provide _very_ generic models of record management and information recording (including version control, auditing, attestation, linking, etc), and enable almost all domain level concepts to be expressed in the second level of models, whose job at runtime is to configure data defined by the information models.
And all
machine-to-machine messaging would have to be concerned with is the use
of standard information elements, defined by a standard XML schema,
driven by the standard model.
It seems to me that the thing most in need of standardizing across the
healthcare industry, is the information that goes INTO [an almost
uncountable # of] user-specific record formats. We need to encourage
providers to shift their focus from the *records* to the elements of
health care information. The goal is to have the right information
elements in front of the right eyes just in time to support the
execution of the right healthcare process.
that's certainly the goal we see - "the right information in the right place, at the right time", and it's one of the reasons why pure federation systems will probably never work as EHRs. But to standardise the information that goes into records, you need to standardise:
- the logical information model(s) in which it is expressed (how it ends up in databases is local business)
- the knowledge models that defiine its validity
It should not matter what sort of centralized or distributed record
architecture the information either came from or is headed toward. All
you need is a *standard* registry connected to the user system that
knows where to look for the information that the user is demanding.
here you are getting back to pure federated systems, which I think are probably a nice fantasy for EHRs, but won't work well in practice, for reasons I mentioned above. However, it will be needed for the ad hoc category of queries between systems where no previous contractual arrangement was set up, as will occur with patients outside of their normal healthcare environment (e.g. overseas or interstate on holidays).
If that registry doesn't point directly to a repository containing the
desired patient information, it could poll the other registries. We
could have millions of fragmented/distributed and even duplicative
repositories of health information, but only one registry is required...
although a handful of standard registry services could also be supported
without significant degradation in service. (Consider, for example, our
DNS system and how smoothly the internet functions, despite the number
of domain name registrars and DNS services that exist.)
yes, this is what is required to support global EHR communication. Some aspect of registry may be needed for regional shared care EHRs as well, if it is thought that there needs to be an index of every item in every EMR available inthe shared care environment, but I have doubts about the cost-benefit of this one. A talk I gave in mexico recently about this whole subject is here (http://www.oceaninformatics.biz/publications/EHR_vision.zip - sorry it's in PPT, but contains a lot of animation, so might serve as a useful illustration of the ideas).
Has the group discussed this general approach? For a longer and,
perhaps more organized dissertation, please see my article at
http://visiondatastandard.org/draftstandard.html , along with a draft
ISO report, providing some additional background.
thanks for a very interesting post.
- thomas beale