|
PERSPECTIVEThe Making And Adoption Of Health Data Standards
Health data standards are key to the U.S. quest to create an aggregated, patient-centric electronic health record; to build regional health information networks; to interchange data among independent sites involved in a person’s care; to create a population database for health surveillance and for bioterrorism defense; and to create a personal health record. This paper discusses why health data standards are required, the process of creating those standards, the groups creating those standards, and some of the problems and issues that are affecting the progress and acceptance of standards. It makes a recommendation for dealing with those issues.
Imagine reading a book in which the author creates her own words, defines her own sentence structure or uses no structure, and randomly organizes the order of the material. That is the situation in much of today’s health care documentation. Creating a better-functioning health care system requires, among other things, a complete, comprehensive electronic health record (EHR), available at the point and time of care. That EHR is created by aggregating and sharing data among all sites at which a patient receives care as well as data from the patient. To share and use data from multiple institutions, data must be built upon common words (data elements and terminology), structures, and organization. In the world of information technology (IT), this requirement is called interoperability. Functional interoperability means that the participating groups support common functions and procedures, much as the components of an automobile must fit and work together. Semantic interoperability means that the language of communication must be understandable by a computer at the receiving end of a communication. Interoperability requires standards. The Institute of Medicine (IOM) identified some of the data standards necessary for patient safety in Patient Safety: Achieving a New Standard for Care.1 Connecting for Health, a joint project of the Markle Foundation, Robert Wood Johnson Foundation, and eHealth Initiative, defined the state of appropriate health data standards and identified additional required standards.2 This paper discusses what standards are required to enable interoperability for data sharing in health care, the organizations that produce those standards, the processes they use, and key issues that determine the effectiveness of standards production and use. An online supplemental exhibit summarizes the key players—organizations that are discussed throughout this paper.3
In the same way that we use common words, with definitions, to fill the role of parts of speech in defined sentence structures; structures such as paragraphs and chapters; and a table of contents and an index for content identification, we need the same kinds of standards for interoperability. Interoperability starts with the smallest component of data interchange: the data element. A data element is a unit of data for which a code, a name, a definition, and a set of permissible values are specified by means of a set of attributes. These attributes also include data type, unit, and category (such as lab test, medication, and so on). All concepts used in health care are represented as data elements. From these basic building blocks, various data structures, such as templates and documents and ultimately the EHR itself, can be defined.
Many types of standards are required to support interoperability in health information management. Exhibit 1
Interest in standards in health care grew very slowly. In the early days of health IT development, most IT systems were developed as stand-alone applications, serving a specific purpose. Most were for the inpatient setting because these were the only sites that could afford the early systems. Hardware constituted the largest portion of these costs. The costs went down when the minicomputer appeared; departmental systems and a few ambulatory IT systems then were developed. Departmental systems were stand-alone applications. For example, a laboratory system served only the lab directly, which meant that the results from lab tests had to be printed out and distributed to the appropriate external clinical units. At Duke Medical Center, we developed an ambulatory EHR system, called The Medical Record (TMR), in the early 1970s.4 Initially, lab results came back in paper form and were entered manually into TMR. Increasing volumes of data, excessive use of human resources, and high error rates led us to develop an electronic interface between the lab system and TMR. Lack of standards in terminology and data types and data form still created major problems in merging the data from the lab into the EHR. IT vendors, developing more complete systems, proposed then, as they do even now, that the best solution was a single integrated product that eliminated the need for standards. If different systems were used, then expensive, custom-made interfaces were required. These interface costs occurred with each interface, and any change in either of the systems involved required those costs to recur. It was this cost to the users of IT systems that led to the introduction of standards into health care.
The steps required to make a standard begin with awareness of both the need for a standard and the fact that a business case could be made for removing trade barriers and expanding some markets with the introduction of a set of common procedures or a common protocol that would benefit a specific community. Next, a critical mass of technical expertise must be gathered to produce the standard. This expertise is likely to come from the vendors rather than the users; however, the ideal standard is vendor-neutral. An acceptance process—usually an open process—is required to get widespread buy-in. Finally, the standard must be marketed for adoption and implementation. Any part of data sharing that requires communication between two or more independent parties requires a standard. Standards may be created by several methods: (1) A group of interested parties can come together to create an ad hoc standard; (2) the government can mandate a standard; (3) marketplace competition and technology adoption can introduce a de facto standard; or (4) a formal consensus process, such as that used by the American National Standards Institute (ANSI), can be followed. Some standards may not go through a formal balloting process but may result from a harmonization process or a procedure in which experts determine the appropriateness of content of the standard. For example, the Health Level Seven (HL7) Reference Information Model, terminologies such as the Systematized Nomenclature of Medicine (SNOMED) and Logical Observation Identifiers, Names, and Codes (LOINC), and data element sets are created by a controlled or harmonization process rather than an open ballot. In the United States, most SDOs use the formal balloting process defined by the American National Standards Institute (ANSI). Balloting occurs within the SDO, but the ANSI requirement for an open process requires the ballot to be open to anyone. The International Organization for Standardization (ISO) and the European Committee for Standardization (CEN) also have formal balloting processes similar to ANSI; the actual voting is at a country level, not by individual members.
Standards-development organizations.
Interest in developing health data standards began in the mid-1980s. In the United States, several SDOs were established for different purposes. In Europe, the CEN, a single committee with twenty-eight national member bodies, is responsible for health data standards. It is funded by national member fees and by the European Union. In 1998 ISO created Technical Committee 215–Health Informatics. Exhibit 2
ANSI is a private, nonprofit organization that administers and coordinates the U.S. voluntary standards activities. Most U.S. SDOs are ANSI-approved bodies, and standards produced by those organizations become American National Standards. ANSI defines the balloting process that ANSI-approved SDOs must follow. ANSI has also set up the Healthcare Information Standards Board (HISB), which coordinates efforts among SDOs.
In addition to the formal SDOs identified above, several other organizations have defined controlled terminologies. Exhibit 3
Standards today. Interoperability requires that all of the necessary standards be defined, adopted, and implemented. This requires conformity by vendor products and certification of applications using the standards. Manuals explaining how standards are to be implemented are essential to the easy and timely implementation of standards. Although most of the required standards exist in some form, they have not been adopted and implemented widely. As a result, there is the impression that required data standards do not exist.
There is no roadmap for health data standards, nor is there any effort to create such a map. No one has defined all of the standards that will be required to support inter-operability for a national health information network (NHIN). No one has identified the gaps. It is likely that these needs will be identified only as we make progress toward the realization of a NHIN. Like many other evolving concepts, we need "just-in-time" standards with the ability to produce effective and acceptable standards quickly. "Just-in-time" means that implementers may discover the need for a new standard as systems implement existing standards and make progress toward interoperability. This concept is in contrast to trying to define in advance all standards that will be needed in the management and exchange of health information. Competition. There is competition among the SDOs, which is complicated now by the fact that other groups, including HIMSS, the National Alliance for Health Information Technology (NAHIT), the Office of the National Coordinator for Health Information Technology (ONCHIT), the Working Group for Electronic Data Interchange (WEDI), and others are becoming involved in the standard-development process. Much of the competition among the SDOs is unintentional but results from the natural evolution and expanding scope of the work. This competition forces implementers to choose among multiple options and requires an additional step of mapping between standards using an interface engine for interoperability. One example is the overlap between the scripting standard created by the National Council for Prescription Drug Programs (NCPDP) and the medication messaging standards defined by HL7. The National Committee for Vital and Health Statistics (NCVHS) has recommended that the NCPDP SCRIPT standard be used for e-prescribing. As e-prescribing evolves into EHR systems, thus requiring additional clinical and other data, a conflict arises. Does the NCPDP develop the required clinical standards, or do the vendors switch, at a cost to the HL7 standard? HL7 and the Accredited Standards Committee X12 (actually, the subcommittee X12N–Insurance, which created the HIPAA-required transaction standards) have some duplication in standards used for the reporting of clinical data associated with the claims process (claims attachment). A major confusion exists between the ASTM Continuity of Care Record (CCR) standard and the HL7 Clinical Data Architecture (CDA) standard supporting a Clinical Record Summary. Both of the standards are intended for the same purpose and are incompatible. Users and vendors will use this conflict as a reason not to implement any standard, waiting for the situation to resolve. Tension exists between these groups about copyright issues that can be solved only by a harmonization process. The balloting process. In the United States, ANSI itself does not make standards but defines a process, including balloting rules, that supports the creation of American National Standards. The recognition of ANSI increases the value of a U.S. standard and therefore is very desirable. ANSI also represents U.S. interests in ISO. ANSI’s purview extends into many areas beyond health. The ANSI process is governed by a set of rules and procedures for reaching consensus on technical decisions. These rules ensure that no one group of stakeholders can dominate the balloting process. Ninety percent of those voting must approve a ballot for it to advance to the level of a national standard. Each negative vote must include an explanatory comment, and each negative vote must be explicitly resolved. With an increasingly larger number of voters, the process has become an administrative nightmare. In addition, the ballot resolution process takes longer, and frequently the changes for addressing the negative vote are substantial and require a repeated ballot. These changes come at the end of the development process rather than at the beginning, so they are much more difficult to accommodate. Engagement of the technical expertise needs to focus on the beginning of the development stage, when agreed-upon changes can be easily made, rather than at the conclusion, when changes must be made to finished products. Perhaps a solution is to require all of those in the ballot pool to be heavily involved in creating the standard. The ANSI balloting process can be accelerated by initial ballots for a Draft Standard for Trial Use (DSTU). This process requires only 60 percent approval and makes the standard available for early adopters more quickly. ANSI requires a DSTU to progress to full standard status within two years. Increasing proprietary interests. Standards have become important to the health IT industry. With pressures from the federal government to use standards, vendors are concerned that their products might not conform with standards. Consequently, vendors want a standard that is favorable to their products. Almost all vendor participants in the standard-making process take part to protect their proprietary interest. As work on EHR standards continues to expand in scope and content, the EHR vendor community has formed a trade alliance (the Electronic Health Record Vendors’ Association, or EHRVA) under the auspices of HIMSS. This group exerts considerable influence through bloc voting. Unfortunately, the advancement of standards within health information management is constantly moving and changing. New versions of standards are coming out even before older versions reach the final ballot stage. This process results in confusion and instability and creates a moving target for standardization. We clearly need to revaluate the balloting rules. We need to reduce the administrative overhead and shorten the balloting process while maintaining its open and balanced nature. If those with a proprietary and vested interest in the standard are engaged at the beginning, and issues are ironed out at that point, the standard-making process could be greatly shortened. That such a system might work was proved by the original Digital Imaging and Communicating in Medicine (DICOM) process, in which six vendors produced, in a relatively short period of time, a standard that was immediately accepted and implemented. HIPAA. The Health Insurance Portability and Accountability Act (HIPAA) of 1996 was the first large-scale mandate of standards related to health IT. The expense of processing claims, the lack of data standards and identifiers, and the frequent changes in reimbursement rules were major problems for the industry. HIPAA was to solve these problems. The NCVHS was given the role of advising the HHS secretary on the adoption of standards and monitoring their implementation. If required standards existed, they were to be identified and adopted. If standards did not exist, they were to be created. To standards for business transactions and the participant identifiers, HIPAA added standards to protect the privacy of health information and to provide security for health IT processes. The initial recommendations came as a result of hearings involving the SDO groups previously mentioned and other appropriate groups with interests and expertise in these areas. For the business processes for health care, the ASC X12N suite of transaction standards was selected, and the terminologies already in use for this purpose were identified and required. Large organizations had two years after adoption to comply, and smaller organizations had three years to comply. The NCPDP appropriately pointed out that it should be included in the transaction standards for prescription drug reimbursement, since they already had more than 60 percent of the transactions. With the exception of concerns of what this would cost the payer industry in terms of new software development and required changes, the IT community supported these rules. Even so, the acceptance of these rules and progress toward meeting the deadlines was very slow. When the penalties were initially interpreted as a single penalty for all violations (rather than for each violation), several vendors stated that it would be cheaper to pay the fine than to adopt the new changes. This position is interesting, given that most agreed that these standards were realistic and would ultimately end up saving a considerable amount of money. The penalties were reinterpreted to apply to each violation—a much larger sum of money. These rules were an important market lever for clearinghouses that would accept claims in the traditional format and translate the claims to meet HIPAA requirements. The actual deadlines were delayed for two years beyond the original deadline. Claim attachments are still awaiting final approval, with the solution being provided jointly by X12N and HL7. Certification for standards. At the urging of David J. Brailer, the national coordinator of health information technology, three organizations—the American Health Information Management Association (AHIMA), HIMSS, and NAHIT—founded the Certification Commission for Healthcare Information Technology (CCHIT), initially intended to certify EHR products for use in ambulatory care settings. Increasing involvement of stakeholders. As EHR content standards and data structures are defined, the requirement for clinical expertise means that more clinical specialists must become involved. These clinical experts create scenarios that define potential use and subsequently requirements for the content standards. From these scenarios, described in something called a story board, clinical data models and required functionalities are defined. From the story boards, the actors or entities, their roles, the acts that are performed, the participation of entities in those acts, and interactions between entities drive the required data structures and data exchanges. This method permits a standardized way in which an appropriate set of messages can be defined, along with trigger events that cause the messages to be sent. A process in which the clinical experts can effectively interface with the technology experts in creating standards needs to be refined. Work has been under way for a number of years on standards for knowledge management, including decision support and clinical guidelines.
There is the sense today that the current process of creating the required data standards to support a patient-centric NHII is not working. A number of problems and issues must be considered and resolved. The issues. (1) As long as multiple SDOs exist, there will be competition, and overlapping and competing standards will exist. Even a harmonized process with different groups and different standards will not eliminate the duplication. (2) Efforts to identify and create required standards either do not exist or are poorly coordinated. (3) Involvement and effective integration of clinical expertise into the process of making standards is crucial. We need to create a balance between the technology required to make standards and the clinical domain expertise of defining data and knowledge content of those standards. (4) A more effective process of getting standards through an approval process that shortens the time and reduces the administrative burden but still maintains the openness and balance among stakeholders is desirable. (5) A method to fill in the required gaps in current standards but still supporting voluntary standards is essential. (6) Government should provide funds to supplement those contributed through membership dues and expenses of participants to influence the creation of "gap standards" and of tool sets, to accelerate the technical work required for standards, and generally to fill in funding gaps. This funding would also support disparate efforts to bring SDOs together to create a single standard. One example is the current existence of multiple decision-support models that need to be resolved into a single model and standard. (7) Balanced involvement of vendors is required, to define the line between open standards and proprietary interests. (8) An agreed-upon method of evolving standards in a timely fashion, permitting vendors to get a return on software investments for implementing standards but taking advantage of new technologies and meeting new needs, is desirable (the backward compatibility issue). We need to establish a defined life cycle for standards. (9) An acceptable, meaningful certification process that defines the minimum requirements for certification and permits declaration of enhancements that are still part of the standard is needed. Certification should be issued by a neutral organization. (10) The United States needs to accept a single Reference Information Model (RIM) upon which all standards work will be based. The HL7 RIM is a predominant choice for this model, because it has already been accepted by the international community and is an ISO standard. The standards-making community also needs a methodology process such that standards created by different groups will exhibit a "sameness" and compatibility among standards. (11) A registry of a master set of data elements along with a single, integrated set of terminologies derived from existing controlled terminologies must be established as a fundamental requirement for interoperability. These terminologies should include both data elements and value sets. Other registries should include a registration of value sets, structured data sets (templates), and clinical documents. Each item in the registry must have a single permanent identifier code. A process for continuous update and maintenance must be established. (12) A distribution method for registries (probably international) and other resources such as tool sets is desirable. All of these materials should be available at no charge. (13) The process of creating standards must allow for the proprietary interests for those involved in the production of standards but prevent these interests from delaying or derailing the process. (14) Adequate and appropriate implementation manuals and tool sets to support the implementation and use of standards is highly desirable. Recommendation for progress. When automatic teller machines (ATMs) were first introduced, ATM cards would only work in certain machines. The banking industry quickly discovered that expenses were reduced, customer satisfaction increased, and the market expanded when they compromised on a solution in which all ATMs would accept any card. The grocery market had little problem in agreeing on a single barcode for labeling the products they sold, and the grocery industry quickly convinced suppliers to use that barcode on all of their products. We need to make similar decisions in creating standards for health IT. My recommendation is for the creation of a neutral, nonprofit organization in the private sector with the authority to manage all aspects of health data standards. The work on standards would be coordinated at that level, and standards would be developed as single integrated efforts governed by process rules. Governance could be provided through a permanent staff with the top levels of leadership (director and codirector, for example) appointed by ONCHIT. Other staff would be hired, and the costs of this component would be paid for, by government. An elected board would provide the overall guidance, direction, operating rules, and policies. This elected board would be structured to include all existing SDOs as well as to represent all stakeholders. The operating budget would be a combination of membership dues, revenue from services, and government funding. The permanent staff would be responsible for moving the work forward, for identifying required standards, for setting priorities, for providing services, for managing resources including registries, and for creating an optimal environment for producing standards. Standards would be developed by volunteers working in various technical committees or special-interest groups. Clinical expertise would be managed within the clinical groups and content assimilated into the appropriate technical standards. The technical aspects of standard making would be open; the policy setting would be done by the directors, with the concurrence of the board. There are clearly other ways in which this standards-making body could be set up. The key, in my opinion, is to create an environment in which interested parties work together as one to produce a single set of standards.
Ed Hammond (hammo001{at}mc.duke.edu) is professor emeritus in the Department of Community and Family Medicine and in the Department of Biomedical Engineering, and an adjunct professor in the Fuqua School of Business, at Duke University in Durham, North Carolina. The author acknowledges the contributions of the reviewers and editors to this Perspective.
This article has been cited by other articles:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Top
What Standards Are Required?
How Standards Are Made
