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" <[email protected]> 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
