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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
