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. 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. 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). 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. 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. 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. 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. 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.) 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 listening! Best regards, -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: Saturday, August 02, 2003 4:33 PM Subject: Re: certification and verification of OpenEHR > > Hi Thomas, > > lakewood at copper.net wrote: > > >Hi All, > > > >Been off looking at some operational considerations associated with > >supporting, maintaining and updating global EHRs. > > > What was your study to do with? Our analysis of possible EHR users is > that most people would use regional EHRs, i.e. EHRs which are embedded > in the healthcare network in which they normally live. Issues of > consent, privacy, security, as well as technical and clinical issues can > be determined in advance on a regional basis, and set up wiith > appropriate contracts. When such patients have a health problem outside > this jurisdiction, e.g on holiday overseas, and ad hoc requeest for > health data needs to be possible - where there will be no advance > contracts, security clearances etc. > > However, some patients are always on the move. Military, aid workers, > elite athletes, conference speakers, entertainers, airline staff and so > on. THey can routinely have a problem anywhere in the world. So their > EHR needs to be set up in a different way - probably served from a > secure webportal which the network of carers for that kind of person > will have secure access, also set up in advance. But these people can > also need medical help outside their routiine care network, and > communications of part of the EHR will again devolve to ad hoc requests > and replies, where security and privacy have to be worked out on the spot. > > >The following types of > >users were considered: > >1)CREATORS > >-individual, groups or organizations that must, or want to, generate new or > >updated EHRs > >2)REVIEWERS > >-overseers, peers and formal reviewers > > > can you define this role in more detail to do with EHRs? Do you mean > senior medical staff? > > >3)ADMINISTRATORS > >-Data management/processing > >4)CERTIFIERS > >-Handles tasks associated with correctness, e.g., prior to use or archiving > > > also this role > > >There has to be user toolkits, possibly with custom components, available > >for the EHRs, and perhaps many different implementations of EHRs. There must > >also be administrative (e.g., configuration management), > > > you will see that the basic of configuration management are in the > COmmon RM (http://www.openehr.org/Doc_html/Model/Reference/common_rm.htm) > > >QA (e.g., does it > >work), evaluation (e.g., workflow) > > > clinical workflow is a big area, and will most likely have its own > services, but very closely bound in with the EHR > > > and performance (e.g., does it take less > >time to perform a task using pen and paper?) tools to address related > >operations (note that the supporting networks and systems have been left > >out). > > > I think all of what you are saying relates to IT / software engineering > quality assurance measures? > > >What kind of tools? > >SUGGESTION: graphical, possibly remote access and possibly wireless enabled. > > > >WHY? Not everyone loves computers, scripting and software plus is willing to > >dedicate the time and energy to get some script to play right. > > > >OPINION: Would like to see a tool that can access/breakdown different types > >of EHRs, support information transfer and synthesis of additional records, > >even a modified EHR. > > > there are two approaches to this. One is where the source "EHR" systems > are legacy databases, and don't obey any models. THere are approaches to > getting data using archetypes to model it, but of course they are not > completely simple - most legacy databases have different, annoying > schemas....you have to extract the raw data, match columns and rows to > target structures, synthesis missing bits etc etc. > > The other approach is when we are talking about moving information > from/to EHR systems which obey openEHR or some other accepted standard > for which we can write interoperability software much more easily. Then > interoperability is largely a matter of archetypes. > > - thomas > > > - > 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
