The Standards Value Chain: Where Health IT Standards Come From

By Glen F. Marshall

The Health Information Technology for Economic and Clinical Health (HITECH) Act of the American Recovery and Reinvestment Act contains clear requirements for actively using healthcare IT standards. But where do standards come from? And how can IT implementers and users contribute to the standard-creating process?

There is more to using standards than implementing system-to-system interfaces, using diagnosis and procedures codes, or meeting the new “meaningful use” requirements for electronic health records. This article presents an overview of how standards are created, refined, tested, and implemented.

First Step: Developing Standards

Standards typically go through several stages, from initial work through implementation in IT systems. This process is called the standards value chain. The chain begins with standards developers, who produce new standards or update existing ones.

The resulting documents are published as drafts, which often draw substantive comments that are then addressed in revised drafts. Standards often go through multiple drafts that sometimes take two or more years to resolve, seeking input from successively wider audiences until yielding final standards documents.

Each development organization determines how to make its work products available, whether free to the public or available for purchase. Specifics vary based on organizational practices and processes, but from initial publication to actual implementations, standards often take three or more years to produce value.

Work products from standards developers include:

• Cross-industry standards, which enable networks to function, trading partners to exchange data electronically, and IT systems to be protected from security threats. Examples include TCP/IP, HTTP, XML, and OASIS Web services specifications.
• Healthcare IT standards, which specify data record content syntax, format, and processing. Examples include Health Level Seven (HL7) messaging and Clinical Document Architecture, Accredited Standards Committee X12 messaging, National Council of Prescription Drug Programs Script, and Digital Imaging and Communications in Medicine image data. Functional requirements are sometimes found in standards (e.g., HL7 Electronic Health Records System Functional Model).
• Healthcare terminology standards, which define sets of data values, often coded to enable automated processes. Examples include ICD codes, SNOMED CT, and the Omaha System taxonomy.

Making Standards Useable

Final standards are often generalized, covering the needs of multiple use scenarios. In some cases there is more than one applicable standard. This makes standards difficult to directly use for specific situations.

Standards-profiling organizations make it easier. They select from among the applicable standards, combine the works of multiple standards developers, and specify how to apply the standards to well-defined use scenarios. They also may include criteria for testing conformance. The resulting standards profile documents are useful for technology development, conformance test specifications, and implementation plans.

The time required to create and publish completed standards profiles is about 12 to 18 months. It takes at least another year to realize value from implementations. Some standards developers publish implementation guides, reducing the need for separate profiles. That in turn can reduce the time to realize value from the standards.

There are two principal healthcare IT standards-profiling organizations in the US:

• Integrating the Healthcare Enterprise (IHE), which selects healthcare IT and cross-industry standards to develop implementation profiles based on market requirements. These have been used to define system integration and conformance specifications. IHE profiles are available at no cost.
• Healthcare Information Technology Standards Panel (HITSP), which selects applicable standards and profiles and creates implementation specifications based on requirements from the Office of the National Coordinator for Health Information Technology. HITSP implementation specifications are available at no cost.

Testing the Standards

In the standards-testing stage of the value chain, healthcare IT application systems are inspected to determine how well they conform with standards or profiles. This is typically done by independent neutral parties.

The HITECH Act specifies certification testing for EHR systems as a requirement for receiving adoption incentives, so standards testing is expected to evolve quickly over the next few years.

In the US, there have been two recognized forms of testing healthcare IT:

• Conformance testing, exemplified by the annual IHE Connectathon. IHE tests the interoperability of healthcare IT systems, based on its profiles, using technical experts and tools it and partner organizations have developed. Many vendors now have IHE-tested products (see www.ihe.net/Resources/ihe_integration_statements.cfm).
• Certification testing, conducted by the Certification Commission for Healthcare Information Technology. CCHIT inspects healthcare IT systems for conformance with standards-based criteria for clinical application functions, security, and interoperability. CCHIT-tested systems qualify for an exception under the physician self-referral prohibition law (Stark) and safe harbor under the Anti-Kickback Act for donating interoperable EHR technology to healthcare practitioners.

Implementing the Standards

Standards implementers supply technology to be included in healthcare IT systems. They often participate in earlier stages of the value chain, helping ensure their products correctly follow standards and profiles, conform with testing criteria, and provide the intended value.

In some cases standards implementers are distinct enterprises, supplying technology components to software implementers. In other instances they are part of a larger software implementer enterprise.

Standards Advocates

The standards value chain is facilitated by advocacy organizations. The figure [below] illustrates their involvement at every step.

Government Advocates

National governments are prominent standardization advocates. They provide sponsorship, funding, and volunteer staff to many standard value-chain activities. They also develop some standards directly.

Many US government agencies are influential stakeholders, including:

• The Office of the National Coordinator for Health Information Technology, designated by HITECH to oversee the new Health IT Policy and Standards Committees. ONC also oversees the activities of HITSP and CCHIT.
• The National Institute for Standards and Technology, which HITECH identified for healthcare IT conformance and certification activities. NIST also was instrumental in developing and testing IHE’s EHR-enabling profiles.
• The Centers for Medicare and Medicaid Services, which oversees standards for HIPAA and maintains the DRG and APC coding systems standards.
• The Agency for Healthcare Research and Quality, which promotes uniform, accurate, and automated healthcare data.
• The National Library of Medicine, which is responsible for the Unified Medical Language System that develops and distributes electronic “knowledge sources” and lexical programs, such as RxNorm.
• The Departments of Veterans Affairs and Defense, which both contain very large healthcare provider organizations with strong participation in standards value-chain organizations.

Organizational Advocates

In addition, there are many advocacy organizations. Some have broad agendas, such as promoting healthcare IT interoperability standards, and others have a narrower focus, such as promoting patient privacy. They influence the healthcare standards value chain through their publications, educational forums, orchestrated public comment on standards, lobbying, and similar channels.

Advocacy organizations can be placed in several categories:

• Healthcare provider advocates, which represent licensed healthcare professionals and care-providing enterprises. Examples include the American College of Physicians, the American Hospital Association, the American Nurses Association, the College of American Pathologists, and the Radiological Society of North America. Some of them develop and publish standards, such as CPT and the Diagnostic and Statistical Manual of Mental Disorders.
• Healthcare financial advocates, including both providers and benefit plans that pay for care. Examples include the Healthcare Financial Management Association, the Council for Affordable Quality Healthcare, the Leapfrog Group, and the Workgroup for Electronic Data Interchange.
• Healthcare IT advocates, which promote healthcare IT standardization. Examples include AHIMA, the American Medical Informatics Association, the Center for Health Transformation, the Healthcare Information and Management Systems Society (HIMSS), the National Quality Forum, and the Medical Imaging and Technology Alliance.
• The academic community for cross-industry technologies and clinical informatics, which provides intellectual capital from research, sponsors standardization activities, influences government actions, conducts educational forums, and consults with value-chain organizations. For example, HL7 was fostered at Duke University, and the Logical Observation Identifiers Names and Codes (LOINC) code set was developed and maintained by the Regenstrief Institute.
• Healthcare consumers, although they are underrepresented in healthcare IT standardization advocacy. Organizations with relevant agendas include AARP, Medic Alert, Patient Privacy Rights, and consumer-oriented activities within AHIMA and HIMSS.

Economic Stakeholders

While there are many stakeholders for healthcare overall, the economic stakeholders for healthcare IT are those who sell, install, and use the software (shown in “Market Stakeholders”). Through participation and funding, these stakeholders strongly influence the standards value chain and advocacy organizations.

Economic stakeholders include:

• Software vendors, who supply products to implementers and users. Standards are just one element of product requirements, features, and functions. In general, vendors get no direct reward for including standards, but they can be strongly penalized by the marketplace if they do not. They have an economic incentive to do the minimum necessary for standards conformance.
• Software implementers, who enable software to support end user requirements. They may be groups within software vendors or stand-alone consulting organizations. Standards conformance can significantly lower the cost and difficultly of implementation, so software implementers have an economic incentive to seek increased standards conformance.
• Software users, who use software to help perform their workflows and tasks. They may be caregivers, care support workers, administrators, or even healthcare consumers who access their own healthcare data online. They have an economic incentive to seek increased standardization because it can simplify and speed up their interaction with healthcare IT, relieve them of tedious repetitive work, and reduce medical errors.

The balance of interests among economic stakeholders is to promote standardization strategically and tactically. Clear business measures for the economic benefits (e.g., improved quality, increased satisfaction, and lower cost) will help motivate them to exert stronger influence over standards value-chain and advocacy organizations.

How to Participate

HIM participation can enhance the benefits of the standards value chain.

Individual participation in any of the value-chain and nongovernmental advocacy organizations is generally open and welcome. The cost is minimal for many of them and usually requires the individual’s time and travel expenses. Some organizations are more expensive, having annual membership dues and per-meeting fees. Signing up for committee work is typically very simple. In many cases it requires simply showing up at the meeting, but sometimes one needs to apply via e-mail or online to be added to a committee roster.

Participants need to bring subject-matter knowledge, good communications skills, an open mind, and the desire to work collaboratively toward a consensus. While acronyms and other jargon may make initial participation a bit confusing, things become clearer after a few meetings, especially by volunteering to take on work.

Many workgroup meetings are now virtual, with infrequent face-to-face meetings. The meetings occur weekly to monthly, depending on the work. Participants should plan on 5–10 percent time allocation per year, with peaks and valleys of intensity.

The timeframes shown in “The Standards Value Chain” give approximate guidance on where to participate in the process. Those whose horizon is strategic (e.g., three to five or more years) will want to participate at the start of the value chain. Those with a more tactical approach (one to two years) should participate in standards testing and implementation.

Glen F. Marshall (glen@grok-a-lot.com) is a private consultant. He participates in the standards value chain in HL7, ISO/TC 215, IHE, HITSP, and CCHIT.