On Mon, 2003-08-04 at 05:50, Thomas Clark wrote: > 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. >
That might be an accurate description of the US healthcare system, but thankfully the US system is restricted (more or less) to the US, despite attempts to export it and despite attempts by misguided politicians elsewhere to copy it. For example, in the UK the NHS provides an rather more unifying funding and governance body for the majority of healthcare activity. Sure, the NHS itself is a series of fifedoms and city-states, but there is still a sense that it is one organisation, and influence on the fifedoms via purse strings is strong. A similar situation for secondary and tertiary care obtains here in Australia, and even primary care is notonally covered by universal health insurance. Thus, although dreams of regional or national EHRs seem far-fetched in the US, they are achievable elsewhere, I think, and perhaps within a decade. Tim C > 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 -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030804/77feb4cf/attachment.asc>
