Thomas, Thank you for your comments. At the moment, the healthcare industry relies on a federated, duplicative system of paper and electronic records. The fragmentation of provider-resources and of healthcare tasks themselves, combined with the long life spans and great mobility of patients are probably the main causes for a person's health data to be spread around so much. I don't foresee any social or other changes that would ever drive the data to be more contiguous. In a particular instance of CARE, however, it can be vitally important to create an ad hoc, record or view of SOME of the patient's health data... just enough to support what the clinician or administrator needs to do at that moment.
Each user will want his local EHR system designed expressly to support his local needs... and he will want to maintain a local repository of all the data he has created or collected about his patients. I think that's a good idea. If agencies like CDC were to also create giant, global repositories for specific purposes... say, to collect data about all communicable disease events in the world... then each provider system might be required (perhaps by regulation, in the U.S.) to continuously update this disease registry with defined report-messages. The resulting CDC repository would, in addition to its utility in helping CDC control spread of disease, also become a useful historical record of a person's diseases over his lifetime... but not necessarily a record of all the patient's surgeries, dental procedures, eyeglass prescriptions, etc.. Presumably other repositories would be built by people who cared about those areas of public health. Each user of health information essentially maintains a repository. Large repositories, constructed for specific purposes, would have a secondary utility as points of synchronization for doctor's records. If 6 different doctors are treating Mrs. Jones over a 10 year period, but during the last year she has seen primarily her oncologist... each time the oncologist updates a cancer registry or other big data repository, that little part of her "federated, global health record" is essentially updated for all "interested providers" to see. As her other5 doctors connect to these registries (for reasons having nothing to do, necessarily, with Mrs. Jones) their systems will also "notice" the presence of an updated record for Mrs. Jones... downloading her latest cancer status info, what drugs she is taking now, new drug allergies discovered, etc.... what ever these 5 other provider systems have been programmed to "care about"... and her local records in those 5 other offices become [more] current. I'm not sure we are quite ready to think about the big "EHR-in-the-Sky" repository that exists ONLY for the purpose of keeping local user records in synchrony... although we seem to be drifting toward that model and it is probably an achievable model. The main repository for such a model could live nicely in India or anywhere. I am NOT a security expert, but I know that you would have at least a couple mirror sites and other redundancy built in. AND... perhaps of greatest comfort to providers... each provider's local EHR system remains always intact and always kept up-to-the-minute through record refreshes each time he connects to the [hopefully, small number of] global repositories. Step #1 still seems to be agreement on ONE standard information model... with only the constraints that are invariably required for each particular element of health data. Archetypes that express additional business rules about the information and relate it to other information elements will be much more difficult to agree on. I think we should try to standardize that layer eventually, but that will require a very efficient mechanism to be constructed for getting input from doctors without them having to attend standards meetings (because they won't attend!). In my view, the EHR effort... partly by virtue of the inclusion of the "record" concept... is starting at too complex a level... at a point where we are almost designing a particular business management system in the standard. A rule-free standard model for the INFORMATION should exist first. From what I understand, SNOMED CT is a very good start on that. Also as a standard, we should make an effort within each care domain to model the actors, places, and things in healthcare, the relationships between them that are always true, and the relationships among the information elements that are always true. This can serve as a useful framework or high-level model for the much more granular and often unique process and information models of each local user-enterprise. -Chris Christopher J. Feahr, O.D. Optiserv Consulting (Vision Industry) Office: (707) 579-4984 Cell: (707) 529-2268 http://Optiserv.com http://VisionDataStandard.org ----- Original Message ----- From: "Thomas Beale" <[email protected]> To: <openehr-technical at openehr.org> Sent: Sunday, August 03, 2003 5:01 PM Subject: Re: certification and verification of OpenEHR > > > 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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
