PDF File: 

HCT2_wp_quinn.pdf

Accenture

In countries other than the United States, collaboration is employed to create a seamless set ofinteractions between patients and all entities that contribute to a patient’s health.

Using IT systems to automate – and improve – clinical and business practices requires, at a minimum, an efficient exchange of information, or collaboration, among IT systems. Health care IT standards are fundamental to making this collaboration work efficiently and smoothly.

Marked differences between the way the United States and the rest of the world use health care IT standards to enable collaboration are beginning to emerge. These differences reveal the ways in which U.S. standards and their applications must change to make collaboration more successful. Interestingly, some of these differences derive from the public policies governing the way health care is organized and delivered in the United States and abroad.

Standards in the U.S. – HIPAA

In October 2003, the largest single set of transaction and data standards associated with the HIPAA were implemented. These standard transactions enable routine communications among employers, providers, and payers about final payment for insured patient services. They include:

• Enrolling a member into a health plan (Standard 834); • Paying for a member’s premium (Standard 820); • Verifying a member’s eligibility for a service (Standards 270 and 271); • Authorizing a referral (Standard 278); • Submitting claims for payment (Standard 837); • Checking the status of claims (Standards 276 and 277); and • Obtaining advice on the details of the payment (or remittance) of claims (Standard 275).

These routine transactions are specific instances of Accredited Standards Committee X12 transactions backed up by implementation guidelines and developed specifically for HIPAA by X12 under the direction of the U.S. Department of Health and Human Services (DHHS). Within these implementation guidelines are code sets or data standards for many fields present in the transactions. In order for process stakeholders to communicate effectively, three things must occur.

First, senders and receivers must act predictably. That is, their processes and resulting messages must be mutually aligned. For instance, it makes no sense for a payer to receive a claim for payment from anyone other than a provider. If a provider is sending a claim, it must have a completed claim ready and must send the claim transaction to a payer who is expecting the transaction in the name of a patient who is a member of one of its health plans.

Second, the syntax of the messages must align. All of the required fields must be filled in, and conditional items must be entered if the conditions have been met. For instance, if a provider is requesting payment for a service that requires a pre-authorization number, the authorization number must accompany the claim.

Third, the communicating systems must agree on the meaning of the data (the semantics of the data) in the context of the supported process. HIPAA transactions just scratch the surface of standard code sets. As mentioned above, many of these code sets are peculiar to HIPAA X12 transactions. For example, HIPAA requires the use of ICD-9 code sets to describe a diagnosis. In the future, DHHS may upgrade this standard requirement to ICD-10. Regardless of the standard, both senders and receivers must use the same “dictionary” to fill in fields that are dependent on an external code standard.

HIPAA’s Future

While no one can predict how payer-provider collaboration will affect HIPAA in the distant future, DHHS’s rule-making process makes short-term predictions possible. DHHS develops and specifies HIPAA standards according to predictable rule-making processes. In general, rules are first the subject of public hearings held before the National Council for Vital and Health Statistics (NCVHS) and are publicized through a notice of proposed rule making (NPRM). An NPRM is usually issued for a period of public comment lasting several weeks. After an indeterminate period of internal rule writing and debate, DHHS issues its intended set of rules. Rules become effective two months after they are published in the Federal Register, and affected parties are given 24 months to implement the new rules.

This extended comment and rule-making period eliminates the possibility of big surprises in the short term. In February 2004, DHHS issued new rules for national provider identification numbers (NPI). The NPI is a new data standard that will affect most existing HIPAA transactions. All covered entities that use HIPAA transactions describing providers (e.g., doctors, hospitals, and clinics) will have until May 23, 2007 (longer than usual) to comply with these new rules. Small health plans will have one additional year.

Other HIPAA rules have not yet reached NPRM status. For instance, one transaction, used by providers to transmit to payers information supplemental to a claim (attachments), has not yet been defined. This transaction was deemed much more complex than the others. DHHS asked X12 and the health level seven (HL7) standards organizations to develop the technical components of an NPRM in 1999. Interested parties from HL7 and X12 started meeting as a group known as the HL7 attachments special interest group (SIG). As of this writing, this SIG has both rewritten and reballoted the proposed transaction no fewer than three times, and DHHS has not yet issued an NPRM for it. Nevertheless, the time spent rewriting the attachments transaction (also referred to as “275”) has not been a waste. Both the technology and our understanding of the underlying processes and outcomes have progressed during this time: The attachments transaction has a new look and feel and is now sitting as a proposed XML (eXtendable markup language)- encoded transaction.

Another significant first occurred during the balloting for the attachments transaction. Over the last several years, DHHS has negotiated a licensing agreement for the use of the College of American of Pathologists’ (CAP) Systemized Nomenclature of Medicine (SNOMED) coding system. Developed by the National Library of Medicine, CAP, Hopkins, Kaiser, and Mayo, SNOMED is widely recognized as a significant leap forward in the science of holding, mapping, and maintaining an almost unlimited number of complex clinical code sets. These codes go far beyond the intended capabilities of international statistical classification of diseases (ICD) and related health problems for diagnosis and current procedural terminology (CPT) for procedures. SNOMED was developed to hold and maintain the codes required to accurately reflect the contents of an electronic medical record. The attachments transaction must contain clinical documents, such as physician discharge summaries, clinical notes, and laboratory observations. The standards NCVHS recommended to the Secretary of DHHS include codes such as ICD, CPT, logical observations identifiers names and codes and SNOMED, so that HIPAA and future electronic health records will contain reliable and meaningful information that meets broadly accepted standards.

XML

XML is one of the most significant advances in the science of packaging data. Almost all higher-level messaging standards have adopted XML over the last five years. However, because the existing nine HIPAA transactions are based on work done from 1997 to 1999, they were implemented without the benefits of XML. It is likely that DHHS will reissue them later using XML syntax, instead of the electronic data interchange syntax currently used.

There are advantages and disadvantages to switching to XML. The most significant advantage is that one can package a message so that the data’s definition (“metadata”) is contained within the message. As a result, messages are, to a large extent, selfdescribing. When properly used, XML syntax messages can be displayed in common browsers, and programmers and data integration specialists can find powerful, off-the-shelf tools to construct, parse, and de-bug messages. When combined with the eXtendable stylesheet language (XSL) and XSL transformations standards, XML data can be displayed as graphically rich, interactive documents that preserve the compositional integrity created by their designers (e.g., a blood test report, a structured discharge summary).

On the negative side, adopting XML means change, and change, in the world of computer programming, takes time and money. Changing working messages also violates the axiom that says: “If it ain’t broke, don’t fix it.” Adding fuel to this argument, XML messages tend to be far more verbose than older messages, consuming greater amounts of network bandwidth.

The last ballot of the attachment transaction in the HL7 and X12 organizations included XML-encoded messages. Both organizations are now firmly marching down the path toward XML-based standards. HIPAA will be too … some day.

Collaboration Beyond HIPAA

Beyond HIPAA, we see embryonic efforts to increase computerassisted collaboration among all parties providing patients with health care. In the United States, collaboration has largely been restricted to interactions among organizations that provide, or pay for, care. Outside the United States, however, one sees standards- based collaboration taking place among all entities that produce or consume data about patients and their health care. This group of entities encompasses much more than providers, patients, and employers. It includes any entity that needs to view or use patient data anytime and anywhere.

The United Kingdom, Canada, Australia, and Finland have well-developed and funded national efforts to create IT infrastructures for a patient’s shared electronic medical record (EMR). The concept is intuitively appealing. For the last two decades, even the United States has applied a scaled-down, but similar, approach to using computers to track the repair history of items, such as automobiles and airplanes. However, the application of standards to facilitate the collaboration inherent in an EMR is far more demanding and ambitious and will require far greater adherence to standards than we have seen in the past – especially in the United States.

It is easy to see why the concept of a ubiquitous EMR first took hold outside the United States. In countries such as the United Kingdom and Canada, health care is provided, to varying degrees, through government-owned and -operated organizations (e.g., the U.K.’s National Health Service, NHS). These national entities have dictated the standards for processes, messages, and data and have funded or built the infrastructures that connect all possible users. They enforce required privacy and security measures and hold or facilitate the movement of data among the participating entities.

In contrast to these examples, the federal government directly and indirectly pays for only about one-third of the health care in the United States. Most of this funded health care is delivered through the private sector (e.g., Medicare for qualified individuals and their dependents) and, in varying ways, through the states (e.g., Medicaid services). With the exception of the Department of Defense, the Veteran’s Administration, and a few smaller entities, the federal government is not in the business of delivering health care. Health care delivery is largely in private hands, and payment is handled by government, insurance, and personal sources. No single entity is in an obvious position to organize, fund, and maintain a national EMR. If the United States is to develop an EMR on a par with those of these other countries, some other mechanism will have to be developed to manage these considerable requirements.

At this time, the largest EMR project in the United States is the one under way at Kaiser Permanente. This project will create a Kaiser domain-specific EMR just for Kaiser members. When it is completed, about 12 million members will be supported through a network of about 20 instances of a commercially available EMR product (EPIC) enhanced to support record sharing and integrity management across Kaiser. As big as this project is, it is about one-fifth the size of the initial Englandonly U.K. project. The projected cost of the NHS project is approximately £11 billion – in equivalent U.S. terms, more than $120 billion (assuming a $1.82 exchange rate and a U.S.:U.K. population ratio of 6:1).

Is the United States prepared to meet a challenge of this magnitude? In his January 2004 State of the Union message, President Bush stated that the nation’s health care system is in “a time of change.” He went on to say, “By computerizing health records, we can avoid dangerous medical mistakes, reduce costs, and improve care.” But while the official rhetoric is encouraging, action lags far behind the words.

The need for well-defined and strictly enforced standards covering process, syntax, and data semantics cannot be understated. The current direction for adopting an EMR in the United States – with the exception of the requirements for standard transactions for HIPAA – ignores collaboration beyond the walls of provider organizations. Without standards, this direction will create, at best, somewhere in excess of 20,000 silos of information for each patient. Thus, even with the complete adoption of EMR, patients will find that their electronic medical records won’t move with them from one provider to the next (e.g., from the general practitioner [GP], to the specialist, to the hospital, and back to the GP). Vital medical information, such as information about allergies and medications, won’t be available to an ambulance team or the emergency room staff, unless a patient is conscious and can accurately inform the provider himself.

Other countries are showing the United States the infrastructure and standards required to implement a robust EMR. Since the United States doesn’t have a national health care organization, we won’t be able to follow these examples exactly. Nevertheless, as stated before, we can get some ideas about the scope and funding that will be associated with such a project. The DHHS’s National Health Information Infrastructure (NHII) is investigating requirements and setting the tone for a U.S. initiative.

In 2003, the NHII encouraged HL7 to begin defining a standard for the electronic health record (EHR). A SIG was formed, and ballots are now in process to create an EHR American National Standards Institute (ANSI) draft standard for trial use. DHHS approached HL7 because HL7 is an ANSI-accredited standards organization. If properly formed, a final ANSI standard may be submitted for approval by the U.N.’s International Standards Organization (ISO). To win approval, the HL7 EHR standard will have to be flexible enough to enable each participating U.N. country to adapt the standard to its own organizational approach to health care.

HL7 as a Basis for Collaboration

Using the HL7 format to communicate data is a common approach, but not nearly as simple as it seems. HL7 first appeared as a usable standard in 1990, as HL7 version 2.1. Most health care applications vendors quickly created interfaces for their applications based on it. Over the years, HL7 evolved into the current version 2.5. A new version of HL7, based on a formal data modeling and development methodology, is emerging as HL7 version 3.0. Version 3.0’s strength is that it allows the user to define a standard set of interactions (processes), data message formats, and data usages in data code sets that, taken together, carry both a message’s syntax and the semantic meaning of the context in which it was created and will be used. Version 3 of HL7 is more than just a messaging standard. It is a methodology for developing standard messages that enables two or more systems to employ the same usage case definitions (process) and the same reference information model (data) to create messages that have the same meaning to the sender and receiver(s). HL7 version 3.0, although not yet complete, has already been adopted as the required messaging standard by most international EMR initiatives today

At first, HL7 was only a U.S. standard. Later, it gained ANSI accreditation and is now advancing toward ISO certification. Many other countries (21 at this writing) have created HL7 affiliates, and several foreign governments have mandated the use of HL7 in their countries. These evolutionary developments now strain the credibility of vendors who claim HL7 compliance, but have not significantly updated the work they did in the early 1990s.

HL7 2.x was designed as a permissive, rather than a prescriptive standard. Instead of prescribing certain processes or subsets of data for a given process (e.g., data to be sent when a patient is admitted to an acute care facility), it accommodates all proposed processes requiring data transfer between systems. This permissiveness, along with the wide variety of process and data needs within health care organizations, means that almost all interfaces implemented today use HL7, not as a true standard, but as a common design framework for enabling (with some on-site work) data message transfer between vendors’ systems.

Thus, HL7 2.x, as commonly used, doesn’t enable a plugand- play capability, as a true standard would. The vendor, the organization, a third-party consultant – or a combination of all three – must use the common framework to create interface specifications unique to the health care organization. The specifications must then be turned into interface code or mappings and thoroughly tested before production.

Standards as the Basis for Integration

Integration through message-based standards is a prerequisite for enabling disparate IT systems to communicate at the database level, or back end. Integration is also key to enabling users to work with multiple IT systems simultaneously at the interface, or front end.

The development of the “common workstation,” where users log onto multiple independent IT systems, has led to the emergence of presentation integration as a requirement. Once it became possible to host multiple applications from multiple vendors on a single workstation, users started to complain about the lack of a common look and feel among applications. The problems were often more than cosmetic. The applications’ different presentation styles and methods of accepting input were confusing and led to errors in entering and interpreting data. Furthermore, the need to log on and out of each application and perform common functions separately, such as patient selections, was time-consuming and redundant. These problems focused attention on architecture, standards, and tools for managing presentation services within the workstation environment.

An obvious architecture change has been the recent adoption of the Internet browser (e.g., Internet Explorer) as the common presentation framework. This choice may seem obvious, but it has been challenging to move from the thick client/server applications of the 1990s (developed at a cost of tens of millions of dollars and years of time) to the browser and the presentation metaphors of the Internet. Most vendors have delivered isolated external applications in a browser (e.g., reviewing patient test results via the Internet), but few have finished rewriting their core applications for the new Web-enabled development environments (e.g., Microsoft’s.NET or IBM’s WebSphere).

Context Management

Beyond presentation integration, user and patient context management is required in the shared workstation environment. If a workstation hosts a common access to multiple applications used for patient care, the user’s effectiveness and accuracy are greatly increased if the applications work together. As the applications all share the same patient and user data, users shouldn’t have to re-enter either type of data into each application manually.

The HL7 standard, clinical context object workgroup (CCOW), specifies technically how applications should interact within a workstation, over the Web, and on application servers in order to share user and patient data. CCOW was originally developed to support multiple client/server “thick” applications hosted by a workstation. In 2000, HL7 published a new version of the CCOW standard (1.3) that supports applications in a “thin,” Web-enabled environment. The CCOW standard specifies common components and interfaces (i.e., application program interfaces, or APIs) that create the mechanisms for the user and patient contexts.

User context management comes into play most significantly when users first identify themselves at a device. It is a part of what is often called “common user log-on.” Common user logon allows users to identify themselves just once. The log-on environment then determines the user’s pre-established security privileges and initiates the applications assigned to that user. Commercial user log-on products, such as IBM’s Tivoli, support CCOW user context management APIs in a health care environment. Many software applications today make use of APIs to support external common user log-on applications. In health care, many support CCOW for this function.

Patient context management shares patient identification data between applications after two or more applications have been initiated and one has identified the patient whose data the user is accessing. Imagine that a caregiver has called up a patient’s chart. Once an application makes this initial patient identification, it communicates it to the other applications instantiated in the user’s applications environment. Each of these applications (if permitted and safe) then selects the same patient in its process workflow. Typically, each application receives the patient identification from the active application through an API interface and then looks up the patient on its own local database and populates its screen with the patient’s information. By doing this, the application is ready as soon as the user needs it, and the user doesn’t have to repeat the tedious and error-prone process of patient selection with each application.

Many vendors today claim to support various features of CCOW. As CCOW inherently applies to a multivendor environment, it is difficult to verify such claims before the applications are installed. Sadly, some claims of compliance are made to close a sale when compliance either doesn’t exist or exists under terms that the buyer didn’t understand. CCOW requires infrastructure software (e.g., a task manager) to identify and register the participating applications and coordinate their actions. Some vendors write their own software to accomplish this task, while others purchase licenses to use third-party software (e.g., Sentillion, Carefx). This software must be licensed and installed, in addition to the applications, before a CCOW environment can be configured into an organization’s IT environment.

The Future of Collaboration

Collaboration among health care IT systems is clearly taking different paths in the United States and the rest of the world. The United States will only catch up when it invests more time and money in establishing and adhering to robust standards that make collaboration possible. But technology improvement is only half the battle. We have to expand our thinking about the role collaboration could play in improving the delivery of health care. We have to remove our conceptual blinders and adopt a multidimensional view of what collaboration, properly implemented, could mean for all stakeholders in the health care delivery system.