Download complete document in Microsoft Word format
Section I: Responses to Questions
Section II: Electronic Health Record Impediment Issues
Section III: Electronic Health Record Requirement Issues
Exhibit A: End-to-End Data Flows – HL7 SIG on AQP
Exhibit B: The Business Case for Comprehensive EHR Standards
I am Ralph A. Korpman, M.D., Chairman and Chief Executive Officer of Health Data Sciences Corporation (HDS), Chief Scientist of Medaphis Corporation and Per-Se Technologies, and Professor at the Loma Linda University School of Medicine. I am speaking today on behalf of HDS, Medaphis, and Per-Se. We have previously testified before this Committee with regard to HIPAA, but we believe that the issues now under discussion are those that are perhaps the most critical to the future of health care in this country.
This document is comprised of an introduction, three body sections, and two appendices. This introductory section provides the basic background of the speaker, the testifying organizations, and the problem space. (Immediately following the introductory section is a listing of terms and references used in this paper.) Section I responds to the questions posed by the Committee. Section II delineates the impediments to achieving success in the standards area in electronic health record systems. Section III provides an experience-based list of the factors to be considered for successful implementation of a standards-based electronic health record. Appendix A shows the end-to-end data flow diagram of HL7 that must conceptually be considered in any electronic health record standard. Appendix B provides general information on the business case for electronic health records and electronic health record standards.
Medaphis/Per-Se/HDS serves almost 2,000 hospitals and 20,000 physicians and groups with a broad variety of products and services. These products and services are delivered around the world, but are predominantly delivered in the US, where both products and services are delivered in all 50 states.
Among our products is a comprehensive health care electronic information tool set known as UltiCare®, also sold in a more structured form as a comprehensive enterprise- wide electronic health record system called Patient1™. This extensive health care information system represents one of the few installed and fully validated operations- optimizing systems for health care in which all care venues (inpatient, home patient, outpatient, call center, physician office, long term care, etc.) are integrated in a single systems domain. The UltiCare/Patient1 systems environment constitutes the primary clinical record and operations support mechanism for over 20,000,000 patients, for whom it maintains lifetime medical records. Ulticare/Patient1 is the information system for several hundred acute and long-term care facilities in the US, including: New York City Health and Hospitals Corporation, the nation’s second largest non-Federal health care system and its largest municipal health care system; the William Beaumont Hospitals, a major integrated delivery system in metropolitan Detroit; Foundation Health, the country’s fourth largest for-profit HMO; and Genesis Health, one of the country’s largest eldercare providers. UltiCare/Patient1 also supports the third largest health care call center operation in the U.S., as well as extensive home care operations.
The first UltiCare systems were installed in the late 1980’s. Although the technology used in the system has changed radically since that time, no patient data has ever been expunged or rendered obsolete; the UltiCare record is the patient’s record. With 20,000,000 such records in use and over 200,000 health professional users, we believe we have a unique perspective on the pros and cons of the electronic health record.
HDS has also been involved in standards efforts for over 15 years. We have always approached our work in this area as an eleemosynary component of our corporate responsibility, and have repeatedly (and often unpopularly) worked to steer standards efforts towards results that can be “done once, done right, and used internationally”. Standards efforts has often periodically trended towards expediency or have been overtaken by small groups seeking commercial advantage; history has shown that such efforts are doomed to deliver so much less than promised that they are generally not worth the trouble. Efforts with broader vision and greater reliance upon usability and field verifications have been far more successful. In fact, the checkered history of standards efforts is, in part, the basis of this hearing. If successes were many and uniform, a hearing would not be necessary.
HIPAA is providing a vital rallying point for U.S. standardization efforts in the field of healthcare informatics. To date, the administrative simplification requirements that are a major part of HIPAA have caused substantial focus on the engagement of trusted electronic data interchange (EDI) (and interfaces) between health care providers, health plans and payers. Importantly for the current clinical standards effort, from a data flow perspective the HIPAA-focused EDI is functionally downstream from the clinical electronic health record (EHR) it references and from which it is (or should be) derived. Indeed the clinical EHR is the potential source for all of the clinical content in the proposed HIPAA transaction set, especially the claims attachment.
This derivative nature of the HIPAA administrative transactions makes the upstream stewardship of the clinical EHR crucial to the ultimate viability of the HIPAA administrative simplification mandate. Without establishing trusted data at the source, all information will continue to be suspect, perpetuating the well-understood “garbage in, garbage out” data situation we find today. This HIPAA clinical standards effort is the best opportunity we have seen in quite a while that might lead to infrastructure guidelines that could go far to achieve the necessary level of data trust. In addition, myriad other benefits, as set forth below, will eventuate if properly implemented.
The Health Insurance Portability and Accountability Act (HIPAA) of 1996 (U.S. Public Law 104-191) charges the Secretary with adopting standards for specified administrative transactions, data elements for such transactions, and supporting standards to enable health information to be exchanged electronically. The purpose is to improve the "efficiency and effectiveness of the health care system, by encouraging the development of a health information system through the establishment of standards and requirements for the electronic transmission of certain health information ..." [HIPAA, Section 261]
HIPAA directs the National Committee on Vital and Health Statistics (NCVHS) to assist and advise the Secretary and to "study the issues related to the adoption of uniform data standards for patient medical record information and the electronic exchange of such information" and to "report to the Secretary not later than 4 years after the date of the enactment of the Health Insurance Portability and Accountability Act of 1996 recommendations and legislative proposals for such standards and electronic exchange…” [HIPAA Section 263]
There are four areas of interest that have been identified for the NCVHS report:
The NCVHS committee has posed five questions:
A. Add the most value for improving the quality and efficiency of the health care for the nation?
B. Be most important to the business or goals of your organization? Why?
C. What is the business case for more rapid standards development and implementation?
Throughout this paper, the following acronyms are used, and the following sources are quoted:
Terms |
|
| ANSI | American National Standards Institute |
| ASTM | American Society for Testing Materials, Committee E31 on Healthcare Informatics, an ANSI accredited SDO |
| AWG | Andover Working Group, a consortia formed by Hewlett Packard |
| CCOW | Clinical Context Object Working Group |
| CORBA | OMG Common Object Request Broker Architecture |
| DHHS | U.S. Department of Health and Human Services |
| ECF | AWG Enterprise Communications Framework |
| EHR | Electronic Health Record (also the Computer-Based Patient Record) |
| HL7 | Health Level Seven, an ANSI accredited SDO |
| HIPAA | Health Insurance Portability and Accountability Act of 1996, U.S. Public Law 104-191 |
| IOM | U.S. Institute of Medicine |
| IT | Information technology |
| JCAHO | Joint Commission for the Accreditation of Healthcare Organizations |
| LCD | Lowest common denominator |
| OMG | Object Management Group |
| NCQA | National Council for Quality Assurance |
| NCVHS | U.S. National Council on Vital and Health Statistics |
| NHS | U.K. National Health Service |
| NIH | U.S. National Institutes of Health |
| SDO | Standards Developing Organization, typically as accredited by ANSI |
| UMLS | NIH Unified Meta Language System |
1.1 Enumeration of Key Issues
The Congressional instruction requests the NCVHS to “study the issues related to the adoption of uniform data standards for patient medical record information and the electronic exchange of such information”. This suggests a wide-ranging discourse dealing with both requirements and impediments. Section III of this paper offers an enumeration of key issues in the context of requirements; Section II addresses the various impediments and distractions that have plagued this process over the years.
1.2 A Trusted Information Source, Downstream Data Flow
It is clear that HIPAA EDI transaction sets set forth by Congress, especially in the context of clinical data in the claims attachment, will contain information only as good (and thus only as trustworthy) as its primary source – typically the provider-based clinical EHR. It seems self-evident that Congress intended that HIPAA transaction sets downstream (in terms of data flow) from the clinical EHR should be able to rely on trusted information origination, stewardship and communication services from the point and moment of origination up to and including the point of triggering the transaction itself.
1.3 Applicability of Standards to the Electronic Health Record
The Congressional instruction infers that the various “administrative simplification” standards mandated by HIPAA (identifiers, classifications, code sets, EDI transaction sets, privacy and confidentiality protections, security and access control, electronic signature) are also crucial design considerations for electronic health records and EHR systems.
1.4 Uniform Data Standards
Although the Congressional instruction specifies the “adoption of uniform data standards”, it is clear that the most restricted reading of the words “data standards” will fail to provide the necessary solutions. To solve the extant problems, applicable standards must exceed the obvious baseline of uniform data content, extending to issues of trust, of stewardship, of accountability, of data integrity (e.g., accuracy, consistency, continuity, completeness, context, comparability), of robust architectures, etc.
A variety of technical and political factors have plagued the standards efforts over the past decade and while progress has been made, it has been slow. These issues are addressed in some detail in Section II of this document.
The answer to this question is, of course, dependent on how one defines the problems and on how one defines satisfaction. Certain constrained areas of standards have made significant progress over the last decade. SNOMED RT is felt by many, including us, to be on the way to becoming the definitive vocabulary standard. HL7 has eventuated into a credible messaging standard. DICOM 3 has addressed many of the issues specific to image management.
However, as set forth in Section III of this paper, broad clinical scope, validation and scalability are key factors in addressing the larger problem. The issue is not just standards for messages, vocabularies, or images, although those may all be components. What is needed are the healthcare-wide models that will allow the more focused standards (such as vocabularies) to be properly contextualized to the care of a patient by a provider. This has always been the putative mission of the EHR, yet lack of standards at this level has generally hampered its adoption.
A limited number of extant architectures in the private sector do offer the clinical scope, validation and scalability necessary to produce a broad-based, trusted EHR. (It should be noted that for all such compliant architectures a robust EHR was a paramount initial design objective, not a lagging afterthought. Application components and interfaces were specifically designed to be proper subsets of the EHR architecture and thus are fully interoperable therein.) It is these few architectures that, perhaps, offer the greatest immediate potential as patterns for standardization and industry practice.
As a general rule, we are not advocates of government “meddling” with private sector activities; often the down side outweighs the up side. However, in this environment, we believe the government does have a constructive role to play. This role is not to mandate standards that the industry would likely find overly limiting or problematic. Rather, the role should be to establish the criteria for enabling standards frameworks that will:
3.1. Identify key points of authority and reference for robust EHR architectures:
.1 Statutes and regulations;
.2 Accreditation standards, as applicable;
.3 Professional standards, as applicable;
.4 Best practice incorporation, based on national, regional and local guidelines.
3.2. Identify vital requirements for robust EHR architectures and establish corresponding EHR requirements statements (leaving implementations to the private sector). [See Section III.]
3.3. Have a mechanism, based on EHR requirements statements developed under 3.2 to identify (and accredit if necessary) robust, validated solutions:
.1 evidencing compliance with the requirements;
.2 with broad clinical scope;
.3 with substantial validation, proof in practice;
.4 broadly scalable;
.5 in the private and public sectors;
.6 in the U.S. and internationally;
.7 from vendors and others.
3.4. Identify such validated EHR solutions as patterns for the industry and for the government, including uniform use across government programs.
3.5. Seek to introduce and/or promote such validated EHR solutions as patterns for standards development in SDOs and other open venues. Seek to fast track adoption of same.
3.6. Seek appropriate incentives and inducements for the proprietors of such validated solutions to offer their architectures directly as open, public standards, perhaps in some kind of public/private partnership.
As suggested in the previous response, the government can make a difference. It can strongly influence the direction the standards process takes, and the quality of the end product, as well as the speed with which such end product is reached. To date, the standards process has focused almost entirely on loosely coupled, lowest common denominator schemes; these have been the easiest things on which to work, and at least a decade has been spent refining these kinds of standards. Although these efforts have resulted in some useful inter-system communications tools, most in the industry do not believe that they have solved the patient data standards problem or that they provide a comprehensive enough approach to reaching the desired wide-ranging solution within our lifetimes.
What the government can do is move the focus of the standards effort to a comprehensive EHR architecture founded on broad-based, fully validated solutions. This opens the substantial potential for the ever sought but never achieved “plug and play” interoperability that is key to optimal patient care and to the public health. At a minimum, the government should advance formal EHR requirements statements (see Section III) to spur attention and direct focus to the vital need for robust, comprehensive solutions incorporating as necessary important work that has gone before.
4.1. Standards for broad-based, comprehensive, fully validated EHR architectures as the basis for standardization of application roles, relationships, boundaries, functions and interfaces. (Section III offers a perspective on key requirements.)
4.2. Standards for end-to-end data flows, managing information from source to consumer, front-end to back-end to thirty party, and including:
.1 protections for individually identifiable information;
.2 accountability: of individuals, of organizations, of business units;
.3 authentication, non-repudiation;
.4 assigned responsibility;
.5 completeness: of record content; of the health delivery process;
.6 data integrity: accuracy, consistency, completeness, context, and comparability;
.7 non-alterability, revisions by amendment only of record content;
.8 preservation of data states: initial and through each amendment;
.9 chain of custody;
.10 auditability, audit trails.
See Appendix A for a conceptual view of end-to-end data flows. Source: HL7 Special Interest Group on Accountability, Quality and Performance
Standards as described in response to Question 4A and based on the requirements outlined in Section III. Standards focused in these areas offer the greatest potential for true “plug and play” interoperability and trusted EHR origination, stewardship and interchange that will provide the impetus the health care industry needs for adoption of these key technologies.
The business case for comprehensive standards is set forth in Appendix B -- it is compelling. Given that fact, more rapid standards development would, one presumes, more rapidly deliver the long list of benefits. On the other hand, more rapid standards development of the typical lowest common denominator kinds of interface standards stands to deliver much less. Using today’s common approach of extant limited standards, mediated interchange, and retrospective data massing, it is increasingly clear that a robust EHR is not the likely end result; the question then becomes how much good money to throw after the bad.
Standards development is an arduous and time-consuming process at best. We believe the best use of everyone’s time, and the best business case can be made for the acceleration of robust key EHR requirements statements recommendations/standards and the examination of extant solutions (achieving a high level of compliance therewith) as a pattern for ensuing standards work.
The four areas of emphasis are reasonable - as far as they go. In fact they represent the traditional focus of health informatics standards. In Section III, a more extensive exposition of the EHR problem space, upon which we believe future work should be based, is presented.
After 10+ years, it has become clearly evident that narrowly focused campaigns emphasizing standardization primarily at the point of interface have produced only limited gains. More churning in these areas is likely to be of continued marginal benefit in the search for broad-based, validated, highly scalable EHR solutions. As considerable work continues to be done in vocabulary, classifications, and code sets, it becomes increasingly clear that in operation such standardization must occur at the point of origin of HER content, not via downstream translation at an interface or via a mediator, when all of the facts and circumstances regarding a data element are not known and the sourcing provider for the information no longer available.