[table of contents] ---- [previous section]
See Section III for parties to the Trust Constituency.
The Committee and others have spent endless time and effort dealing with privacy, security, and confidentiality issues in health care records. Although these factors are not the specific focus of this meeting, they represent an important sub-context in any discussion of electronic health records standards. A key success factor for any EHR standard will be achieving the public and professional perception that safeguards are in place and will continue to emerge to keep pace with technology. It goes without saying that such safeguards must be robust and encompassing enough to protect individually identifiable information and broad-based health information sources and resources.
To the extent any national EHR standards approach is carefully devised, prudent and measured with evidence of good practice and record stewardship, broad acceptance should be achievable. There may be no more singularly important strategic objective than gaining the public trust in this regard. Although much of the unease in this area is manufactured by small special interest groups, the potential for damage is high if these issues are not properly resolved.
As EHR requirements that incorporate the Trust Factor are developed pursuant to the actions of this Committee and of others, the Federal government can serve an important role by promulgating such standards and compliant solutions as examples of the importance of the Trust Factor to:
.1 the public: as evidence of trusted stewardship of their personal health records;
.2 the assembled SDOs: as a validated example for standards development;
.3 the legislative and administrative branches of government: as a model of the fulfillment of statutory, regulatory and business objectives;
.4 the accreditation agencies: as a model for fulfillment of accreditation standards;
.5 the professional societies: as a model for fulfillment of best practices;
.6 the health plan: as a model for fulfillment of business objectives, best practices;
.7 the provider organization: as a model for fulfillment of business objectives, best practices;
.8 the individual practitioner, caregiver: as a model for best practices, for trusted stewardship of the individual patient/member health record and the practitioner service record.
Trust is a vital cornerstone that must be addressed head-on, without equivocation. No matter how otherwise compelling, no approach will prevail without a firm foundation of trust.
Ten years ago, as large systems began to shift significantly from the mainframe-based model, the importance of frameworks began to be recognized.
“Since the technology permits 'distributing' large amounts of computing facilities in small packages to remote locations, some kind of structure (or architecture) is imperative because decentralization without structure is chaos. Therefore, to keep the business from disintegrating, the concept of information systems architecture is becoming less an option and more a necessity for establishing some order and control in the investment of information systems resources. The cost involved and the success of the business depending increasingly on its information systems require a disciplined approach to the management of those systems.”
--- John A. Zachman, Creator of the Zachman FrameworkIBM Systems Journal, Volume 26, Number 3, 1987
With but a handful of notable exceptions, the quest for a trusted and complete electronic health record (EHR) has been a disappointment. Why has the promise and appeal been so grand and the achievement so wanting?
Looking at actual implementation examples, one prime impediment is obvious: the typical EHR systems design strategy has generally done everything BUT design a system. Instead, multitudes of disparate healthcare applications typically already serve niches and enclaves. The healthcare EHR infrastructure is overlaid on these applications after the fact: a piecemealed tapestry with many fragments, connected with odd bits of filament, yet far from interwoven. Unfortunately, each patient depends heavily on the connections between the fragments, and it has been shown to be difficult if not impossible to find a patient in the tapestry...with this design approach there are too many holes through which the patient might fall.
An analogy from another industry is illustrative. It would be absurd to approach the design of the Space Shuttle in a manner similar to our industry’s tack with the electronic health record. It would be the same as suggesting that each of several thousand teams be given an assignment, based on some general assumptions, and then allowed to proceed independently to design, develop and deploy each Shuttle component independent of all other design teams and without a coherent architecture to join them together as a unified whole. A crew cabin, a cargo bay, a propulsion system, a wing, a rudder, a strut, etc. - each devised in isolation from the other.
All teams may indeed produce superb components in their own right, the “best-of-breed” solution to each designated niche and role. Unfortunately, while viability as measured by the requirements of the niche may be outstanding, without an encompassing integration architecture, viability of the combined components as a unified, fully integrated and interoperable whole is virtually certain to be impaired beyond usefulness.
Unfortunately, this approach has been the standard in the health care information systems arena. Harking to the Shuttle analogy, one could never create enough standards to make the independently designed pieces fly safely into space. The mission is not to have the best seat…the mission is to get to space safely and back. Similarly, in health care the mission is to care for the patient, not the laboratory, pharmacy, or billing department. Until this problem is addressed on the standards front, the standards for each component are likely to not provide the expected value.
“Plug and play” has been a holy grail of the standards effort for years, in the mistaken notion that without a standard framework, it should be possible to randomly assort pieces and emerge with a result as complex as the Space Shuttle. An early HL7 advertisement (circa 1988) comes to mind. It showed a mosaic of puzzle pieces, each representing an application system, precisely interlocking one with the other. The intuitive message of this promotion was that of seamless application unity and ubiquitous “plug and play” interoperability, all the product of HL7 data interchange standards, of course.
Unfortunately, “plug and play” interoperability (as a function of industry standard interface specifications) has not come to fruition nearly as readily as the HL7 puzzle might seem to suggest. Ten years later, it remains an elusive objective. Unfortunately, the actual situation is we are typically taking five random pieces from a thousand or more different puzzle boxes and, after amassing them in a single pile, attempting to produce a cohesive and coherent whole.
Much standardization activity has focused on loose coupling schemes to effect data interchange between disparate application systems. The net effect of these schemes is to create a common domain of functions and data with each application engaged only to the extent allowed by its individual architecture and addressed in its interface implementation. The result is loosely coupled, minimally engaged applications interconnected by lowest common denominator (LCD) interfaces. While this approach has been perceived to bridge an immediate need, it offers little to address the objectives of a broad-based EHR solution, or to answer the implicit EHR Trust issues that are contained in any system combination.
The figure below graphically illustrates the problem.
This figure illustrates a typical interface solution, where an SDO Standard Specification is used as a base common denominator between disparate application architectures.. Adaptations and extensions are then applied to form a greater common denominator given the confluence of application architectures and local requirements.
Long absent on the agenda of key data interchange standards developers has been a specific focus on the requirements necessary to produce a viable EHR. (See HL7, Version 2.3, Section 1.7, April, 1997.) This key deficiency bears immediate attention. See Section III of this testimony for additional detail.
Mediators (i.e., interface engines) have become a popular method of interfacing multiple applications within an IDN or provider organization as they allow each application to interchange data with all other applications in that domain without the need for separate interfaces interconnecting each on a pair-wise basis.
Unfortunately the mediator is a decidedly mixed blessing, particularly in terms of robust EHR implementations.
.1 Disengagement = No Tight Coupling. With the interposition of a mediator, transmitting and receiving applications become effectively disengaged one from the other. With most mediator-based broadcast schemes (single transmitter, many receivers) the transmitter is intentionally designed without programmed knowledge of the ultimate receiver or its role. Such schemes by their very nature embody the loosest possible coupling.
Mediators inhibit any potential for the achievement of tightly-coupled interfaces between communicant applications. Blind transmission, disengagement of transmitter from recipient, and disengagement of originators/sources from stewards from ultimate recipients/consumers only serve to perpetuate the deficiencies inherent in loosely coupled, lowest common denominator approaches. Unfortunately, mediators do provide a low level of achievement that serves to foster minimal engagement when deep engagement is what is needed.
.2 No Merged Lists. An immediate consequence of the lack of tight coupling is the inability to effectuate merged lists across application boundaries. Specifically, it is virtually impossible to implement usable two-phase database commits (with bidding and locking services) after inserting a mediator between communicant applications. Thus is precluded shared, real-time multi-application ownership of merged lists, including:
.1 lists of patients/members (e.g., the Master Patient Index);
.2 lists of practitioners/caregivers;
.3 schedules for patients and practitioners;
.4 schedules for deployments and allocations of resources
.5 lists of patient encounters;
.6 lists of patient problem-oriented episodes;
.7 lists of current medications for a patient (i.e., the medication profile);
.8 etc.
Robust instantiations of merged lists are an imperative for robust, broad-based, highly scalable EHR solutions. Mediators from a barrier to this feature.
.3 No End to End Acknowledgment. The transmitting application sends its messages only so far as, and receives an acknowledgment from, the mediator. By design in most implementations, these are blind transmissions as the transmitter has no programmed knowledge of each ultimate receiver. It’s only known receiver is the mediator.
When the ultimate receiver captures the messages and acknowledges same to the mediator, such affirmative response is not then communicated back to the original transmitter. For example, this precludes an order entry application from ever knowing whether an order was received by an ancillary application. It can only affirm acknowledgment by the mediator not the ultimate message destination.
Although it is an anathema to mediator proponents, it is imperative that end to end acknowledgment be a trusted characteristic of any robust EHR solution.
.4 No End to End Message Sequencing. In a similar instance of blind transmission, the message stream is sequenced between the transmitting application and the mediator and the message stream is also sequenced from the mediator to the ultimate receiver but there is no end to end sequencing of messages from the transmitting application to each ultimate receiver.
Although it runs counter to the mediator culture, this discontinuity must also be superseded as a function of the trusted EHR.
A prevalent industry approach employs separate front and back-end applications. The back-end acts as a repository for data massing, collecting data forwarded by multiple front-end applications, typically via mediators. The front-ends serve particular niches, departments and/or functions. The back-end repository claims to offer an IDN or provider organization a functional EHR.
Even if a mediator is not in play and the front and back-end applications are directly connected, few implementations employ tight coupling sufficient to support two phase database commits (with bidding and locking services) and thus shared, real-time multi-application ownership of merged lists is infeasible.
To fully support a robust EHR, it is imperative that front and back-end applications engage tight coupling sufficient to ensure two phase database commits and key prospective views of information (see next section).
As described in the previous section, a trend has emerged to house the EHR in back-end data massing repositories. As a function of the relative disengagement (lack of tight coupling) of the front and back-end applications, these repositories typically capture the health delivery process in a retrospective mode (what has occurred).
Inherently lacking in these schemes is a real-time, enterprise-wide scheduling function that encompasses a prospective and concurrent aspect, in addition to the retrospective view. A true real-time prospective view is imperative to:
.1 actively engage immediate patient care events;
.2 proactively engage wellness and preventative care events;
.3 ensure assigned responsibility (of practitioners/caregivers) for immediate or upcoming health service events;
.4 optimally allocate and deploy critical organizational resources (i.e., practitioners/caregivers, facilities, locations, equipment, supplies, time).
Imagine successfully navigating a vehicle while strapped into a rear-facing seat. Imagine successfully navigating a provider organization, health plan, or IDN similarly encumbered.
Another critical requirement is the ability to ensure completeness of the health delivery process and correlative EHR content. Without knowing what is to be done (i.e., the prospective aspect) it is impossible to measure completeness. Specifically: Does the currently amassed data in the repository represent a complete record, a complete set of health delivery services? For a patient/member, for a problem oriented episode, for an encounter, for a health service event? Where are the gaps? Who is responsible for their completion?
Much recent attention has focused on transliteration schemes, which purport to automatically translate record content, attribute by attribute, from its original encoding to a common or standard encoding. Mediators are routinely promoted for their transliteration capabilities, transposing data encodings “in transit” from one application to another.
The NIH UMLS Meta Thesaurus is often cited as an authoritative cross-mapping of content encodings, from one standard classification/coding scheme to another. Unfortunately, this approach may not be as useful as it might first appear.
.1 The Repudiation Dilemma. If EHR content is transliterated after the point of origination and the new encoding does not produce a precisely identical term or phrase, the EHR is immediately (and correctly) subject to repudiation by its author, scribe or verifier.
.2 Change of Meaning. Transliteration that changes the encoding to produce a term that is presumably equivalent but not precisely identical to the original carries the imminent potential of change of meaning which may in some cases be crucial to decisions regarding patient care or treatment.
.3 Change of Specificity, Granularity of Content. Transliteration that increases or decreases clinical specificity also carries substantial risk factors in its subsequent use in patient care or treatment.
.4 Accountability. Accountability for EHR content is ascribed to individuals acting as practitioners, caregivers, authors, scribes and/or verifiers. When data is transliterated as an “automatic” function of interfacing schemes, including mediators, the accountability factor is lost. Who becomes the accountable party for the new encoding?
The integrity of EHR content is seriously jeopardized by transliteration schemes that purport to arbitrarily change information from its original encoding to something else. At minimum, the original encoding should be conveyed undisturbed with any transliteration attached as an addendum.
For a number of years, standardization activities have been flummoxed by the latest whiz-bang technologies. Proponents come forth with claims of transcendent solutions that seem irresistible but in almost all cases turn out too good to be true. Many of these have suggested seamless integration and “plug and play” interoperability, including mediators, back-end retrospective data massing repositories, ActiveX/DCOM, OMG CORBA, AWG ECF, CCOW, SGML/XML, etc. This is not to deny some inherent usefulness in each of these technologies; many of these are not only useful but have great potential. The plea here is for the clear up-front identification of the actual useful role each product plays.
In many cases, the industry has witnessed hordes of advocates stampeding off claiming victory only to produce constructs that offered marginal substance when compared to core EHR requirements. Unfortunately, this action-response sequence has repeatedly caused enough distraction to disrupt ongoing work.
Technologies alone will not achieve a robust EHR solution. The EHR problem space will not yield to the assertion of technologies ahead of core requirements and prudent design. Instead, fulfillment of EHR requirements must remain the primary design objective for standardization with technologies then applied as appropriate therefrom.