Thomas, Thanks for the comments. My only caution about asking physicians to comment on the desirability of EHR-system proposals is that they may not understand [what we mean by] our questions... and we probably won't really understand [what they mean by] their responses.
When we ask for input from practicing physicians, I would rather pose very discrete questions, such as: "When you do this procedure, our committee believes that these information components are absolutely necessary... do you agree?" Anyway... this has been a busy few days with all the activity in the HL7 EHR SIG, and I guess I was in a particularly verbose mode... even for me... yesterday! (I saw several "please remove me! messages posted today... I hope I didn't drive away any of your "regulars customers"!) Take care, -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: <lakew...@copper.net> To: "Christopher Feahr" <chris at optiserv.com>; "Thomas Beale" <thomas at deepthought.com.au>; <openehr-technical at openehr.org> Sent: Tuesday, August 05, 2003 9:24 AM Subject: Re: certification and verification of OpenEHR > Hi Chris, > > Great response! > > Would like to learn what the US Providers want and need from a system > like the proposed OpenEHR project. Contributors to the project are at > liberty to publish; but the remaining, quite numerous, Providers may well > be unaware of the existence of such projects and unable to respond. > > 'Pass the baton to the healthcare associations' seems appropriate. Why not > have them poll their members? > > Nothing like designing a system that a majority of the users reject. > > -Thomas Clark > > ----- Original Message ----- > From: "Christopher Feahr" <chris at optiserv.com> > To: "Thomas Clark" <tclark at hcsystems.com>; "Thomas Beale" > <thomas at deepthought.com.au>; <openehr-technical at openehr.org> > Sent: Monday, August 04, 2003 10:20 AM > Subject: Re: certification and verification of OpenEHR > > > > Thomas, > > Thanks! And I hardly know where to begin responding... but I do like > > all of your comments. The thing about providers being considered "a > > homogeneous group of individuals working for the common good" is really > > a matter of philosophical and, perhaps, spiritual orientation. I agree > > that we (providers) do not always behave this admirably! But you are > > also DEAD ON with your comments suggesting that single-minded user-focus > > (on the user's OWN needs, as opposed to the needs of the greater > > healthcare community) is related to most users being permanently stuck > > in "survival mode". > > > > Businesses are struggling to survive... more and more BECAUSE of the > > escalating costs of driving the health care bus through the information > > quagmire. Insurance interests ARE taking more control over who does > > what in healthcare... but not [always!] out of a megalomaniacal interest > > in controlling providers... but mostly to get control of the COSTS that > > providers seem to be powerless to control themselves.... again, because > > providers have pathetic software... because no one can build the > > software they need... because we lack sufficient standards to give > > application developers sufficient confidence that doctors would actually > > buy the software if they did build it! > > > > We are not trying to decide whether breaking out of this death-spiral is > > a good idea. Our only task now is to decide HOW to break out of it. > > It's not sufficient to say that providers have what they deserve because > > they've refused to agree on something better (for their patients)... > > unless we first imagine and then create for them a mechanism whereby > > they CAN agree. Ideally, we should have one geo-politically neutral SDO > > maintaining robust communications with a solid, global network of > > medical subject matter experts. Then we build "straw man" > > model-components and run them through our expert vetting pool until no > > one has substantial objection. Eventually, these converge into a > > generally accepted model of the persons, places, things, actions, > > relationships, and data elements of healthcare... the aspects of these > > things that our distributed panel of experts agree are or should be > > "always true". > > > > There is much (about the process of CARE) that the industry can and will > > agree on. (much of this agreement already exists as "evidence based > > practice guidelines" or "standard of care"). We need a way to further > > formalize that agreement into a technical model of *core* healthcare > > processes and information. Then we can build on it. As > > healthcare-paradigms shift, we will have to absorb the shift into the > > model, just as practitioners will have to implement the shift in real > > care processes. Obviously, we require a model-technology that is > > flexible enough to be changed... but remember, this is a MODEL... of a > > REAL process. If the process can be changed (and society agree that is > > SHOULD change)... and that change impacts information management... then > > the world has no choice. We must change both the model and the real > > processes and the information structures and record architectures... to > > accommodate the better way of caring for people. > > > > We never want to change... yet we always do. The proponents of change > > always want it to go faster, but I am learning that rapid change ALWAYS > > causes unnecessary suffering within a system as brittle, fragmented, and > > interdependent as healthcare. The minute we stop kicking at it, > > however, it STOPS changing! So the collective "government" role is NOT > > to write regulations like HIPAA that foist a particular IT-paradigm onto > > 500,000 providers by a "deadline". The proper government role is to > > FUND the mechanism whereby provider (and other user) needs can be > > abstracted into a standard. Then... with a robust and RELIABLE > > standards floor beneath our feet, we let COMMON SENSE be the driver to > > build, purchase, and implement interoperable software. > > > > 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 Clark" <tclark at hcsystems.com> > > To: "Christopher Feahr" <chris at optiserv.com>; "Thomas Beale" > > <thomas at deepthought.com.au>; <openehr-technical at openehr.org> > > Sent: Sunday, August 03, 2003 12:50 PM > > Subject: Re: certification and verification of OpenEHR > > > > > > > Hi All, > > > > > > I would like to add a big 'RIGHT-ON' to Christopher's contribution! > > > > > > >From the operations viewpoint cost is a major factor and when > > significant > > > precludes > > > participation by parties and organizations that should be involved. > > Also, > > > the healthcare > > > industry cannot be described as a homogeneous group of individuals > > working > > > for the > > > common good, and perhaps the Patient's health. > > > > > > What is noticeable is that different groups/disciplines rarely > > communicate > > > effectively > > > and are often at odds over even small matters with 'turf control' a > > common > > > factor. > > > > > > I recently attempted to get a handle on how county operations handle > > > everything from > > > budgets to HIPAA. Unfortunately even volunteers have a difficult time > > being > > > accepted > > > and integrated. What is noticeable is that they jealously guard their > > > current processes, > > > procedures and suppliers to the extent that modifications, upgrades > > and new > > > methods > > > and technologies are rejected. My suspicion is that they have learned > > this > > > behavior > > > simply because budget constraints and consecutive budget cuts have > > placed > > > them in a > > > primarily survival mode. > > > > > > Administrators are less friendly and politicians are notable for their > > lack > > > of commitment. > > > > > > The healthcare system is already 'locked' in a mode where even small > > > sections are > > > unable to modify and/or improve current operations. An expanding > > population > > > will > > > render this state of affairs defunct. > > > > > > My characterization of the healthcare industry is a group of > > > not-necessarily-connected > > > small universes within which specialties withdraw into semi-permeable > > > spheres in an > > > attempt to create another small universe. Imposing order in a > > > cost-efficient/effective > > > manor is likely to be rejected soon or very soon after introduction, > > i.e., > > > failure is a > > > sure bet. > > > > > > Occasionally bright stars appear but too often are teaching/research > > > personnel and > > > organizations. En masse the deficiency in Patient-centric care is > > having > > > major impacts > > > on public sentiment which in turn has a dark side. Patient-centered > > > healthcare is the > > > main target. > > > > > > HOW DOES OpenEHR FIT INTO THIS? > > > > > > It is a global healthcare industry that is of interest with regional > > and > > > local industries > > > playing major roles. Important are major factors covering healthcare > > > disciplines and > > > Patient specifics, e.g., cultural, ethnic, language, social, age, > > medical, > > > dental, mental > > > and work (certainly not an all-inclusive list). Within the five > > minutes > > > allocated per > > > Patient by an HMO try resolving some of these issues during an office > > visit > > > or, > > > perhaps, a visit to an Emergency Room. > > > > > > Before IT can approach and render a local design for a significant > > number of > > > these > > > issues there are important criteria, requirements, objectives, goals > > and > > > administrative > > > issues that need to be resolved positively. OpenEHR must be > > accommodating to > > > the > > > extent that global regions and a global industry can use it as a > > bridge and > > > transport. > > > It must be more than a simple record-keeping system; it must include > > content > > > management and communications capabilities. > > > > > > As a tourist with a medical condition from Chicago, traveling in Paris > > and > > > requiring > > > immediate medical attention my preference would be for a system that > > > supports > > > language translations and common record sub-formats that allow the > > attending > > > physician to diagnose the problem, attend to it and update Paris and > > Chicago > > > records. > > > > > > >From an IT viewpoint it is a pipeline that supports applications > > requiring > > > access, > > > filtering, data translation, communications (perhaps with another > > > Practitioner), > > > auditing, backup, anticipatory storage and all in real-time. > > > > > > An adaptable 'standard *information* model' with 'granular sub-models' > > is > > > necessary and can incorporate Practitioner, Patient and Administrator > > > components. Interoperability with existing and 'planned' systems is > > > necessary > > > as well. Merging one or more foreign data sources into a single data > > source > > > would be desirable in an integration effort. > > > > > > Quote (Chris): > > > 'We need to encourage providers to shift their focus from the > > *records* to > > > the elements of health care information' > > > > > > Practitioners need to look at how they use current records systems and > > how > > > multiple Practitioners interface on healthcare processes, procedure > > and > > > issues. > > > Medical errors occur too frequently when Patients are passed from one > > > group/Practitioner to another, e.g., a trip to the operating room > > involving > > > insufficient or incorrect information. > > > > > > GLOBAL SUPPORT SYSTEM > > > > > > This remain a tough nut to crack, a major problem involving different > > > social/ > > > economic/ethnic/political/insurance/access boundaries. It is not an > > > impossible > > > task since other industries function well today across the same > > boundaries. > > > > > > KNOWLEDGE-BASED SUPPORT > > > > > > Many repetitions of a process/procedure may be necessary/required > > (e.g., > > > policy/regulations). Many may not so constrained. Automatic > > Knowledge-based > > > processes and procedures can alleviate workloads and bottlenecks. > > > > > > When properly identified, processes and procedures included within an > > > OpenEHR record can significantly contribute to data mining and > > processing > > > that will support future evaluations and performance studies that > > could lead > > > to > > > further enhancements and modifications. > > > > > > Decision-support and feedback on past, current and planned processes > > and > > > procedures can support Practitioners as well evaluate them. It can > > also > > > benefit > > > Patients. > > > > > > RECORD ARCHITECTURE > > > > > > Chris's comments about: > > > 'centralized or distributed record architecture' > > > > > > are significant because: > > > 1)Patients are unique > > > 2)Patient healthcare is unique and may be affected in different ways > > by > > > applied > > > processes, procedures, medications, Practitioners > > > 3)There are considerably more Patients than models and exceptions are > > bound > > > to > > > kill the model quickly > > > 4)Healthcare evolves through research, application, experience and > > learning. > > > Such evolutionary processes should not be burdened with model > > modifications. > > > > > > My preference is for viewing a Patient's healthcare as an adaptable > > object > > > that > > > can inherit from ancestors and healthcare-related objects (e.g., > > disease, > > > ethnic, > > > cultural, social, mental, work, environmental). Embedded in this is > > OpenEHR > > > as much more than a record-based system. > > > > > > Regards! > > > > > > -Thomas Clark > > > > > > > > > ----- Original Message ----- > > > From: "Christopher Feahr" <chris at optiserv.com> > > > To: "Thomas Beale" <thomas at deepthought.com.au>; > > > <openehr-technical at openehr.org> > > > Sent: Sunday, August 03, 2003 7:09 AM > > > Subject: Re: certification and verification of OpenEHR > > > > > > > > > > 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" <thomas at deepthought.com.au> > > > > 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 > > > > > > > - > > 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
