From a health information system perspective, there are federal laws relative to information management, data authentication, health exchange, standards, and end user needs. Additionally, o

Chapter 11 Health Care Information System Standards

Throughout this text we have examined a variety of different types of standards that affect, directly or indirectly, the management of health information systems. In Chapter Ten we examined health care performance standards; Chapter Two looked at data quality standards, Chapter Nine at security standards, and so on. In this chapter we will examine yet another category of standards that affect healthcare data and information systems: health care information system (HCIS) standards. In all cases the standards examined represent the measuring stick or set of rules against which an entity, such as an organization or system, will compare its structures, processes, or functions to determine compliance. In the case of the HCIS standards discussed in this chapter the aim is to provide a common set of rules by which health care information systems can communicate. Systems that conform to different standards cannot possibly communicate with one another. Portability, data exchange, and interoperability among different health information systems can be achieved only if they can “communicate.” For a simple analogy, think about traveling to a country where you do not speak the language. You would not be able to communicate with that country's citizens without a common language or translator. Think of the common language you adopt as the standard set of rules to which all parties agree to adhere. Once you and others agree on a common language, you and they can communicate. You may still have some problems, but generally these can be overcome.

By nature HCIS standards include technical specifications, which make it less easy for the typical health care administrator to fully understand them. In addition, a complex web of public and private organizations create, manage, and implement HCIS standards, resulting in standards that are not always aligned, making the standards even more difficult to fully grasp. In fact, some may actually compete with one another. In addition to the complex web of standards specifically designed for HCIS, there are many general IT standards that affect healthcare information systems. Networking standards, such as Ethernet and Wi-Fi, employed by health care organizations are not specific to healthcare. Extensible markup language (XML) is widely accepted as a standard for sharing data using web-based technologies in healthcare and other industries. There are many other examples that are beyond the scope of this text. Our focus will be on the standards that are specific to HCIS.

With HIPAA came the push for adoption of administrative transaction and data exchange standards. This effort has been largely successful; claims are routinely submitted via standard electronic transaction protocols. However, although real progress has been made in recent years, complete interoperability among health care information systems remains elusive. Chapter Three examined the need for interoperability among health care information systems to promote better health of our citizens; Chapter Two discussed the lack of standardization in EHRs as an issue with using EHR data in research; and Chapter Nine outlined problems associated with misalignment of quality and performance measures, in part because of a lack of interoperability and standardization in EHRs and other health care information systems. Interoperability, as defined by the ONC (2015) in its publication Connecting Health Care for the Nation: A Shared Nationwide Interoperability Roadmap, results from multiple initiatives, including

payment, regulatory, and other policy changes to support a collaborative and connected health care system. The best political and social infrastructures, however, will not succeed in achieving interoperability without supportive technologies.

This chapter is divided into three main sections. The first section is an overview of HCIS standards, providing general information about the types of standards and their purposes. The second section examines a few of the major initiatives, public and private, responsible for creating, requiring, or implementing HCIS standards. Finally, the last section of the chapter examines some of the most commonly adopted HCIS standards, including examples of the standards when possible. HCIS Standards Overview Keith Boone, a prolific blogger and writer on all topics related to HIT standards, once wrote, “Standards are like potato chips. You always need more than one to get the job done” (Boone, 2012b). In general, the health care IT community discusses HCIS standards in terms of their specific function, such as privacy and security, EHRs, electronic prescribing (e-prescribing), lab reporting, and so on, but the reality is that achieving one of these or other functions requires multiple standards directed at different levels within the HCIS. For example, there is a need for standards at the level of basic communication across the Internet or other network (Transporting), standards for structuring the content of messages communicated across the network (Data Interchange and Messaging), standards that describe required data elements for a particular function, such as the EHR or clinical summary (Content), and standards for naming or classifying the actual data, such as units of measure, lab tests, diagnoses, and so on (Vocabulary/Terminology). Unfortunately, there is no universal model for categorizing the plethora of HCIS standards. In this chapter we will look at standards described as Data Interchange and Messaging, Content, and Vocabulary/Terminology standards.

Standards, as we have seen, are the sets of rules for what should be included for the needed function and system level. This is only a portion of the challenge in implementing standards. The other challenge is how are the standards used for a particular function or use case? Much of the work today toward achieving interoperability of healthcare information systems is concerned with the how. Organizations that develop standards may also create specific implementation guides for using the standard in a particular use case. (To further complicate the already complicated standards environment, these implementation guides are sometimes referred to as standards.) Other organizations, such as the ONC, develop frameworks for implementing standards, and several government initiatives, such as HIPAA and HITECH, have set requirements for implementing specific standards or sets of standards. Standards Development Process When seeking to understand why so many different IT and health care information standards exist, it is helpful to look first at the standards development process that exists in the United States (and internationally). In general the methods used to establish healthcare IT standards can be divided into four categories (Hammond & Cimino, 2006):

Ad hoc. A standard is established by the ad hoc method when a group of interested people or organizations agrees on a certain specification without any formal adoption process. The Digital

Imaging and Communications in Medicine (DICOM) standard for health care imaging came about in this way. De facto. A de facto standard arises when a vendor or other commercial enterprise controls such a large segment of the market that its product becomes the recognized norm. The SQL database language and the Windows operating system are examples of de facto standards. XML is becoming a de facto standard for health care and other types of industry messaging. Government mandate. Standards are also established when the government mandates that the healthcare industry adopt them. Examples are the transaction and code sets mandated by the Health Insurance Portability and Accountability Act (HIPAA) regulations. Consensus. Consensus-based standards come about when representatives from various interested groups come together to reach a formal agreement on specifications. The process is generally open and involves considerable comment and feedback from the industry. This method is employed by the standards developing organizations (SDOs) accredited by the American National Standards Institute (ANSI). Many health care information standards are developed by this method, including Health Level Seven (HL7) standards and the health-related Accredited Standards Committee (ASC) standards. The relationships among standard-setting organizations can be confusing, to say the least. Not only do many of the acronyms sound similar but also the organizations themselves, as voluntary, member-based organizations, can set their own missions and goals. Therefore, although there is a formally recognized relationship among the International Organization for Standardization (ISO), ANSI, and the SDOs, there is also some overlap in activities. Table 11.1 outlines the relationships among the formal standard-setting organizations and for each one gives a brief overview of important facts and a current website.

Table 11.1 Relationships among standards-setting organizations

Source: ANSI (n.d.a, n.d.b, n.d.c); ISO (n.d.).

Organizations Facts Website International Organization for Standardization (ISO) Members are national standards bodies from many different countries around the world. Oversees the flow of documentation and international approval of standards development under the auspices of the its member bodies www.iso.org American National Standards Institute (ANSI) US member of ISO Accredits standards development organizations (SDOs) from a wide range of industries, including health care Does not develop standards but accredits the organizations that develop standards Publishes more than ten thousand standards developed by accredited SDOs www.ansi.org Standards Developing Organizations (SDOs) Must be accredited by ANSI Develop standards in accordance with ANSI criteria

Can use the label “Approved American National Standard” Approximately two hundred SDOs are accredited; twenty of these produce 90 percent of the standards. www.standardsportal.org All the ANSI-accredited SDOs must adhere to the guidelines established for accreditation; therefore, they have similar standard-setting processes. According to ANSI, this process includes the following:

Consensus on a proposed standard by a group or “consensus body” that includes representatives from materially affected or interested parties Broad-based public review and comment on draft standards Consideration of and response to comments submitted by voting members of the relevant consensus body and by public review commenters Incorporation of approved changes into a draft standard Right to appeal by any participant that believes that due process principles were not sufficiently respected during the standards development in accordance with the ANSI-accredited procedures of the standards developer (ANSI, n.d.c) The IT industry in general has experienced a movement away from the process of establishing standards via the accredited SDOs. The Internet and World Wide Web standards, for example, were developed by groups with much less formal structures. However, the accredited SDOs continue to have a significant impact on the IT standards for the healthcare industry.

Boone (2012a) lists the following organizations as major developers of HIT standards in the United States, which includes a mix of accredited SDOs and other developers. Each organization's specific areas for standard development are indicated in parentheses. ANSI-accredited SDOs are indicated with an “*.”

International Standards Organization (ISO) [various] ASTM International (ASTM) [various]* Accredited Standards Committee (ASC) X12 [Insurance Transactions]* Health Level Seven International (HL7) [various]* Digital Imaging and Communication in Medicine (DICOM) [Imaging] National Council for Prescription Drug Programs (NCPDP) [ePrescribing] Regienstrief (LOINC) [Laboratory Vocabulary]

international Health Terminology SDO (IHTSDO) [Clinical Terminology] In addition, Boone (2012a) identifies the following “other” organizations as having a major impact on HIT:

World Wide Web Consortium (W3C) [XML, HTML] Internet Engineering Task Force (IETF) [Internet] Organization for the Advancement of Structured Information Standards (OASIS) [Business use of XML]

He further identifies key groups known as “profiling bodies” (Boone, 2012a) that use existing standards to create comprehensive implementation guides. Two examples of profiling bodies are Integrating the Healthcare Enterprise (IHE) and the ONC, which focus on guidance for implementing clinical interoperability standards. Perspective European Committee for Standardization (CEN) Although the focus of this chapter is standards developed within the United States, it is important to recognize there are other standards organizations worldwide. For example, the European Committee for Standardization (CEN) was created in Brussels in 1975. In 2010 CEN partnered with another European standards developing organization, the European Committee for Electrotechnical Standardization (CENELEC), to form the CEN-CENELEC Management Centre (CCMC) in Brussels, Belgium. The CCMC current membership includes national standards bodies from thirty-three European countries (CEN-CENELEC, n.d.).

The Technical Committee within CEN that oversees healthcare informatics standards is CEN TC 251, which consists of two working groups:

WG1: Enterprise and Information WG2: Technology and Applications Source: CEN (n.d.). Federal Initiatives Affecting Healthcare IT Standards There are many federal initiatives that affect healthcare IT standards. In this section we look at federal initiatives for healthcare IT standards as a part of HIPAA, CMS e-prescribing, CMS EHR Incentive Program, and the Office of the National Coordinator for Health Information Technology (ONC), including the Interoperability Roadmap.

HIPAA In August 2000, the US Department of Health and Human Services published the final rule outlining the standards to be adopted by health care organizations for electronic transactions and announced the designated standard maintenance organizations (DSMOs). In publishing this rule, which has been modified as needed, the federal government mandated that health care organizations adopt certain standards for electronic transactions and standard code sets for these transactions and identified the standards organizations that would oversee the adoption of standards for HIPAA compliance. The DSMOs have the responsibility for the development, maintenance, and modification of relevant electronic data interchange standards. HIPAA transaction standards apply to all covered entities' electronic data interchange (EDI) related to claims and encounter information, payment and remittance advice, claims status, eligibility, enrollment and disenrollment, referrals and authorizations, coordination of benefits, and premiums payment. The current HIPAA transaction standards are ASC X12N version 5010 (which accommodates ICD-10) along with NCPDP D.0 for pharmacy transactions (CMS, 2016b). In addition to these transaction standards, several standard code sets were established for use in electronic transactions, including ICD-10-CM, ICD-10-PCS, HCPCS, CPT, and Code on Dental Procedures and Nomenclature (CDT) (CMS, 2016a). Centers for Medicare and Medicaid E-prescribing

The Medicare Prescription Drug, Improvement, and Modernization Act of 2003 (MMA) established a Voluntary Prescription Drug Benefit program. There is no requirement in this act that providers write prescriptions electronically, but those who choose to do so must comply with specific e-prescribing standards. The current published CMS e-prescribing standards consist of three sets of existing healthcare IT standards as “foundation” standards, which include NCPDP's SCRIPT Standard for e-Prescribing, ASC X12N standard for Health Care Eligibility Benefit and Response, and NCPDP's telecommunications standard. In addition, the final rule identifies three additional electronic tools to be used in implementing e-prescribing:

NCPDP Formulary and Benefit Standard Implementation Guide, which provides information about drugs covered under the beneficiary's benefit plan NCPDP SCRIPT Medication History Transactions, which provides information about medications a beneficiary has been taking Fill Status Notification (RxFill), which allows prescribers to receive an electronic notice from the pharmacy regarding the beneficiary's prescription status (CMS, 2013) Centers for Medicare and Medicaid EHR Incentive Programs As discussed previously, the Medicare and Medicaid EHR Incentive Programs were established as a part of the HITECH Act to encourage eligible providers (EPs) and eligible hospitals (EHs) to demonstrate Meaningful Use of certified EHR technology. EHR certification for Stage 1 and Stage 2 Meaningful Use requires EPs and EHs to meet specific criteria. Certification requirements are organized according to objectives, measures, specific criteria, and standards. Not all criteria include specific standards, but many do. Examples of standards required by 2014 certification rules include using the HL7 Implementation Guide for CDA in meeting the criteria for providing patients the ability to view online, download, and transmit information about a hospital. Other standards include SNOMED CT, which is required for coding a patient's smoking status, RxNorm, which is required for medications, and LOINC, which is required for laboratory tests, among others (HealthIT.gov, 2014). Office of the National Coordinator for Health Information Technology As discussed in previous chapters the Office of the National Coordinator for Health Information Technology (ONC) was established in 2004 and charged with providing “leadership for the development and nationwide implementation of an interoperable health information technology infrastructure to improve the quality and efficiency of health care” (HHS, 2008). In 2009, the role of the ONC was strengthened when the HITECH Act legislatively mandated ONC to provide this leadership and oversight (HHS, 2012). Today, the ONC is “the principal federal entity charged with coordination of nationwide efforts to implement and use the most advanced health information technology and the electronic exchange of health information” (HealthIT.gov, n.d.).

Current ONC initiatives, in addition to implementing HITECH, include implementation of healthcare IT standards for interoperability. In Chapter Three, the ONC Interoperability Roadmap was introduced and key milestones related to payment reform and outcomes were outlined. The Roadmap also outlines key milestones for the development and implementation of technologies to support interoperability (ONC, 2015). Beginning in 2015, the ONC published its first Interoperability Standards Advisory, which has been subsequently updated annually. This Advisory document outlines the ONC-identified “best available” standards and implementation

specifications for clinical IT interoperability. The identified standards and specifications in the 2016 Advisory are grouped into three sections:

Best Available Vocabulary/Code Set/Terminology Standards and Implementation Specifications, which address the “semantics,” or standard meanings of codes and terms needed for interoperability Best Available Content/Structure Standards and Implementation Specifications, which address the “syntax,” or rules by which the common data elements can be shared to achieve interoperability Best Available Standards and Implementation Specification for Services, which address infrastructure components needed to achieve interoperability (ONC, 2016) Each specific standard is identified and defined by six characteristics: process maturity, implementation maturity, adoption level, federal requirement status, cost, and whether a testing tool is available. The Advisory also includes hyperlinks to the standards and implementation guides cited. Exhibit 11.1 is an excerpt from the 2016 Advisory. Exhibit 11.1 Excerpt from ONC 2016 Interoperability Standards Advisory Section I: Best Available Vocabulary/Code Set/Terminology Standards and Implementation Specifications I-A: Allergies

Interoperability Need: Representing patient allergic reactions Type Standard/Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally Required Cost Test Tool Availability Standard SNOMED CT Final Production No Free N/A Limitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s): SNOMED CT may not be sufficient to differentiate between an allergy or adverse reaction, or the level of severity Value Set Problem urn:oid:2.16.840.1.113883.3.88.12.3221.7.4 Interoperability Need: Representing patient allergens: medications Type Standard/Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally Required Cost Test Tool Availability Standard RxNorm Final Production Yes Free N/A Standard

Collepals.com Plagiarism Free Papers

Are you looking for custom essay writing service or even dissertation writing services? Just request for our write my paper service, and we'll match you with the best essay writer in your subject! With an exceptional team of professional academic experts in a wide range of subjects, we can guarantee you an unrivaled quality of custom-written papers.

Get ZERO PLAGIARISM, HUMAN WRITTEN ESSAYS

Why Hire Collepals.com writers to do your paper?

Quality- We are experienced and have access to ample research materials.

We write plagiarism Free Content

Confidential- We never share or sell your personal information to third parties.

Support-Chat with us today! We are always waiting to answer all your questions.