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 NDF-RT Final Production Unknown No Free N/A Source: ONC (2016). Other Organizations Influencing Health Care IT Standards The following organizations certainly do not represent the full list of bodies that are involved with healthcare IT standards development and implementation. However, they do represent a few of the most significant non government contributors. ASTM International and HL7 International are accredited SDOs with standards specifically addressing health care information. IHE is a recognized profiling body influencing the implementation of interoperability standards. ASTM International ASTM International was formerly known as the American Society for Testing and Materials. ASTM International has more than thirty thousand members from across the globe, and they are responsible for publishing more than twelve thousand standards. ASTM standards range from those that dictate traffic paint to cell phone casings (ASTM, n.d.a, n.d.b). The ASTM Standards for Healthcare Services, Products and Technology include medical device standards and health information standards. The health information standards are managed by the ASTM Committee E31, which focuses on “the development of standards that help doctors and health care practitioners preserve and transfer patient information using EHR technologies” (ASTM, 2014). Of particular note, the E31 standards include the continuity of care record (CCR) discussed further on in this chapter. HL7 International HL7 International was founded in 1987. It is an ANSI-accredited SDO “dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services” (HL7, n.d.). The HL7 standards related to interoperability and listed on its website as “Primary Standards,” or most used, include the following: Version 2 and 3 HL7 messaging standards, interoperability specifications for health and medical transactions; these are the standards commonly referred to as HL7 Clinical Document Architecture (CDA), a document markup standard for clinical information exchange among providers based on version 3 of HL7 Continuity of Care Document (CCD), a joint effort with ASTM providing complete guidance for implementation of CDA in the United States Clinical Context Object Workgroup (CCOW), interoperability standards for visually integrating applications “at the point of use” These primary standards are not the only ones developed by HL7 International. The organization also publishes Functional EHR and PHR specifications; Arden Syntax, a markup language for sharing medical information; and GELLO, a query language for medical records. One of the most promising of the HL7 International standards is Fast Healthcare Interoperability Resources (FHIR). FHIR is built on HL7 but is considered easier to implement because it uses web-based technologies (Ahier, 2015). Several of the HL7 standards, including FHIR, will be explained in greater detail further on in this chapter. IHE Integrating the Healthcare Enterprise (IHE) has developed a series of profiles to guide health care documentation sharing. These profiles are not standards but rather include very specific guidance for how existing standards can be implemented to meet clinical needs (IHE, n.d.b). The current IHE profiles are organized as follows: Anatomic Pathology Cardiology Eye Care IT Infrastructure Laboratory Pathology and Laboratory Medicine Patient Care Coordination Patient Care Device Pharmacy Quality, Research, and Public Health Radiation Oncology Radiology As an example, the IHE Patient Care Coordination Profile group includes twenty individual profiles, and each profile is further identified by its current implementation stage (IHE, n.d.a). Health IT Standards The development and implementation of healthcare IT standards is complex and constantly evolving. The preceding sections of this chapter are intended to provide some insight into the processes of the organizations involved in standards development. The following sections examine examples of the actual standards. This is by no means an exhaustive list of healthcare IT standards but rather samplings of a few that are commonly used or significant in other ways. Vocabulary and Terminology Standards One of the most difficult problems in exchanging health care information and creating interoperable EHRs is coordinating the vast amount of health information that is generated in diverse locations for patients and populations. The vocabulary and terminology standards discussed in this section serve similar purposes—to create a common language that enables different information systems or vendor products to communicate unambiguously with one another. In a very simplified example, a standard vocabulary would ensure that the medical term myocardial infarction, for example, is mapped to the term heart attack and that both terms share exactly the same attributes. An effective standard vocabulary must also standardize the very complex hierarchy and syntax of the language used in the health industry. This is a complicated and detailed endeavor to say the least. So it is not surprising that, to date, no single vocabulary has emerged to meet all the information exchange needs of the health care sector. The most widely recognized coding and classification systems—ICD, Current Procedural Terminology (CPT), and diagnosis related groups (DRGs)—were discussed in Chapter Two. Although these systems and the other coding systems discussed in this section do not meet the criteria for full clinical vocabularies, they are used to code diagnoses and procedures and are the basis for information retrieval in healthcare information systems. Most were originally developed to facilitate disease and procedure information retrieval, but they have been adopted to code for billing services as well. Several of the most commonly used classification systems are actually incorporated across more robust standard vocabularies such as SNOMED CT and UMLS. The code sets required by HIPAA include the following: HCPCS (ancillary services or procedures) (see Chapter Two) CPT-4 (physicians procedures) (see Chapter Two) CDT (dental terminology) ICD-10 (see Chapter Two) NDC (national drug codes) The HITECH Meaningful Use final rule also includes ICD-10 as its classification standard. The National Committee on Vital and Health Statistics (NCVHS) has the responsibility, under a HIPAA mandate, to recommend uniform data standards for patient medical record information (PMRI). Although no single vocabulary has been recognized by NCVHS as the standard, they have recommended the following as a core set of PMRI terminology standards: Systematized Nomenclature of Medicine—Clinical Terms (SNOMED CT) Logical Observation Identifiers Names and Codes (LOINC) laboratory subset Several federal drug terminologies, including RxNorm (NCVHS, 2003) The HITECH Meaningful Use final rule and the ONC Advisory include these standards and the standard for clinical vaccines administered (CVX). In this section we will describe SNOMED CT, LOINC, CVX, and RxNorm, along with the National Library of Medicine’s Unified Medical Language (UMLS) (of which RxNorm is one component), which has become the standard for bibliographic searches in health care and has the potential for other uses as well. Code on Dental Procedures and Nomenclature The American Dental Association (ADA) publishes the CDT, Code on Dental Procedures and Nomenclature. This set of codes is designed to support accurate recording and reporting of dental treatments. The ADA strives to maintain an up-to-date set of codes that reflect actual practice (ADA, n.d.). The code set is divided into twelve sections, as follows (Washington Dental Service, 2012): Diagnostic (D0000–D0999) Preventative (D1000–D1999) Restorative (D2000–D2999) Endodontics (D3000–D3999) Periodontics (D4000–D4999) Prosthodontics (D5000–D5899) Maxillofacial prosthetics (D5900–D5999) Implant services (D6000–D6199) Prosthodontics (D6200–D6999) Oral and maxillofacial surgery (D7000–7999) Orthodontics (D8000–8999) General Services (D9000–D9999) National Drug Codes The National Drug Code (NDC) is the universal product identifier for all human drugs. The Drug Listing Act of 1972 requires registered drug companies to provide the Food and Drug Administration (FDA) a current listing of all drugs “manufactured, prepared, propagated, compounded, or processed by it for commercial distribution” (FDA, 2016). The FDA, in turn, assigns the unique, three-segment NDC (listed as package code in the following example) and maintains the information in the National Drug Code Directory. The NDC Directory is updated twice each month. Data maintained for each drug include up to sixteen fields. The information for the common over-the-counter drug Tylenol PM (Extra Strength), for example, is as follows: Product NDC: 50580–176 Product Type Name: Human OTC Drug Proprietary Name: Tylenol PM (Extra Strength) Non-proprietary Name: Acetaminophen and Diphenhydramine Hydrochloride Dosage Formulation: Tablet, Coated Route Name: Oral Start Marketing Date: 12–01–1991 End Marketing Date: Marketing Category Name: OTC Monograph Final Application Number: part338 Labeler Name: McNeil Consumer Healthcare Div. McNeil-PPC, Inc Substance Name: Acetaminophen; Diphenhydramine Hydrochloride Strength Number/Unit: 500 mg/1, 25 mg/1 Pharm Class: Histamine H1 Receptor Antagonists [MoA], Histamine-1 Receptor Antagonist [EPC] Package Code: 50580–176–10 Package Description: 1 Bottle, Plastic in 1 Carton (50580–176–10) > 100 tablet, coated in 1 Bottle, Plastic DEA classification: (US FDA, 2016) Systematized Nomenclature of Medicine—Clinical Terms Systematized Nomenclature of Medicine—Clinical Terms (SNOMED CT) is a comprehensive clinical terminology developed specifically to facilitate the electronic storage and retrieval of detailed clinical information. It is the result of collaboration between the College of American Pathologists (CAP) and the United Kingdom’s National Health Service (NHS). SNOMED CT merges CAP’s SNOMED Reference Terminology, an older classification system used to group diseases, and the NHS’s Clinical Terms Version 3 (also known as Read Codes), an established clinical terminology used in Great Britain and elsewhere. As a result, SNOMED CT is based on decades of research. As of April 2007 SNOMED is owned, maintained, and distributed by the International Health Terminology Standards Development Organization (IHTSDO), a nonprofit association based in Denmark. The National Library of Medicine is the US member of the IHTSDO and distributes SNOMED CT at no cost within the United States (IHTSDO, n.d.; NLM, 2016b). Logical Observation Identifiers Names and Codes The Logical Observation Identifiers Names and Codes (LOINC) system was developed to facilitate the electronic transmission of laboratory results to hospitals, physicians, third-party payers, and other users of laboratory data. Initiated in 1994 by the Regenstrief Institute at Indiana University, LOINC provides a standard set of universal names and codes for identifying individual laboratory and clinical results. These standard codes enable users to merge clinical results from disparate sources (Regenstrief Institute, n.d.). LOINC codes have a fixed length field of seven characters. Current codes range from three to seven characters long. There are six parts in the LOINC name structure: component/analyte, property, time aspect, system, scale type, and method. The syntax for a name follows this pattern (Case, 2011): LOINC Code: Component: Property Measured: Timing: System: Scale: Method Example 5193–8:Hepatitis B virus surface Ab: ACnc:Pt:Ser:Qn:EIA Clinical Vaccines Administered The Centers for Disease Control and Prevention (CDC) National Center of Immunization and Respiratory Diseases (NCIRD) developed the Clinical Vaccines Administered (CVX) as standard codes and terminology for use with HL7 messaging standards. Table 11.2 is an excerpt from the full CVX table. Table 11.2 Excerpt from CVX (clinical vaccines administered) Short Description Full Vaccine Name CVX Code Status Last Date Updated Notes adenovirus types 4 and 7 adenovirus, type 4 and type 7, live, oral 143 Active 3/20/2011 This vaccine is administered as two tablets. anthrax anthrax vaccine 24 Active 5/28/2010 BCG Bacillus Calmette-Guerin vaccine 19 Active 5/28/2010 DTaP, IPV, Hib, HepB Diphtheria and Tetanus Toxoids and Acellular Pertussis Absorbed, Inactivated Poliovirus, Haemophilus b Conjugate (Meningococcal Outer Membrane Protein Complex), and Hepatitis B (Recombinant) Vaccine 146 Pending 9/21/2015 Note that this vaccine is different from CVX 132. influenza, seasonal, injectable influenza, seasonal, injectable 141 Active 7/17/2013 This is one of two codes replacing CVX 15, which is being retired. influenza, live, intranasal influenza virus vaccine, live, attenuated, for intranasal use 111 Inactive 5/28/2010 RxNorm The National Library of Medicine (NLM) produces RxNorm, which serves two purposes: as “a normalized naming system for generic and brand name drugs and as a tool for supporting semantic interoperation between drug terminologies and pharmacy knowledge–based systems” (NLM, 2016a). The goal of RxNorm is to enable disparate health information systems to communicate with one another in an unambiguous manner. There are twelve separate RxNorm data files that are released on a monthly basis. The files show this information: Drug names and unique identifiers Relationships Attributes Semantic types Data history (three files) Obsolete data (three files) Metadata (two files) The following example from the first RxNorm data file represents the “concept,” Azithromycin 250 MG Oral Capsule, with the unique identifier 141962 (NLM, 2016a): 141962|ENG||||||944489|944489|141962||RXNORM|SCD|141962| Azithromycin 250 MG Oral Capsule||N|| Unified Medical Language System The NLM began the Unified Medical Language System (UMLS) project in 1986, and it is ongoing today. The purpose of the UMLS project is “to facilitate the development of computer systems that behave as if they ‘understand’ the meaning of the language of biomedicine and health. The UMLS provides data for system developers as well as search and report functions for less technical users” (NLM, 2016b). The UMLS has three basic components, called knowledge sources: UMLS Metathesaurus, which contains concepts from more than one hundred source vocabularies. All the common health information vocabularies, including SNOMED CT, ICD, and CPT, along with approximately one hundred other vocabularies, including RxNorm, are incorporated into the metathesaurus. The metathesaurus project’s goal is to incorporate and map existing vocabularies into a single system. UMLS Semantic Network, which defines 133 broad categories and dozens of relationships between categories for labeling the biomedical domain. The semantic network contains information about the categories (such as “Disease or Syndrome” and “Virus”) to which metathesaurus concepts are assigned. The semantic network also outlines the relationships among the categories (for example, “Virus” causes “Disease or Syndrome”). SPECIALIST Lexicon and Lexical Tools. The SPECIALIST lexicon is a dictionary of English words, common and biomedical, which exist to support natural language processing. The UMLS products are widely used in NLM’s own applications, such as PubMed, and they are available to other organizations free of charge, provided the users submit a license agreement (NLM, 2016b). Currently, components of UMLS are incorporated into other standards and profiles for health care IT interoperability. Data Exchange and Messaging Standards The ability to exchange and integrate data among health care applications is critical to the success of any overall health care information system, whether an organizational, regional, or national level of integration is desired. Although there is some overlap, these standards differ from the vocabulary standards because their major purpose is to standardize the actual “messaging” between health care information systems. Messaging standards are key to interoperability. In this section we will look at a few of the standards that have been developed for this purpose. There are others, and new needs are continually being identified. However, the following groups of standards are recognized as important to the health care sector, and together they provide examples of broad standards addressing all types of applications and specific standards addressing one type of application: Health Level Seven Messaging standards (HL7) Digital Imaging and Communications in Medicine (DICOM) National Council for Prescription Drug Programs (NCPDP) ANSI ASC X12N standards Two other groups of standards discussed in this section actually combine some features of messaging standards and content standards: Continuity of Care Document (CCD) Fast Health Interoperability Resources (FHIR) HIPAA specifically requires covered entities to comply with specific ANSI X12N and NCPCP. HITECH and the ONC Advisory also cite specific messaging standards and the CCD. FHIR is currently under development by HL7 International and is being cited by health care IT professionals as a major advancement toward true interoperability. Health Level Seven Standards Two versions of HL7 messaging standards, Version 2 and Version 3, are listed by HL7 International as “primary,” or commonly used. HL7 v2 remains popular in spite of the development of HL7 v3. HL7 v2 was first introduced in 1987 and has become the “workhorse of electronic data exchange” (HL7, n.d.). HL7 v3 incorporates the root elements of XML and, as such, is a significant change from early versions. See the HL7 Perspective for an example of HL7 v3. Digital Imaging and Communications in Medicine Standards The growth of digital diagnostic imaging (such as CT scans and MRIs) gave rise to the need for a standard for the electronic transfer of these images between devices manufactured by different vendors. The American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) published the first standard, a precursor to the current Digital Imaging and Communications in Medicine (DICOM) standard, in 1985. The goals of DICOM are to “achieve compatibility and to improve workflow efficiency between imaging systems and other information systems in healthcare environments worldwide.” It is used by all of the major diagnostic medical imaging vendors, which translates to its use in nearly every medical profession that uses images (DICOM, 2016). National Council for Prescription Drug Program Standards The National Council for Prescription Drug Programs (NCPDP), an ANSI-accredited SDO with more than 1,600 members representing the pharmacy services industry, has developed a set of standards for the electronic submission of third-party drug claims (NCPDP, 2012). These standards not only include the telecommunication standards and batch standards required by HIPAA but also the SCRIPT standard required for e-prescribing, among others. Of note, the SCRIPT standard currently incorporates the RxNorm as its standardized medication nomenclature. The NCPDP Provider Identification Number is a unique identifier of more than seventy-five thousand pharmacies. Table 11.3 presents excerpts from the NCPDP Data Dictionary, which outlines a few of the Transmission Header Segment requirements. The entire data dictionary table is more than seventy pages long (CMS, 2002). Table 11.3 Excerpt from NCPDP data dictionary NCPDP Data Dictionary Name Field Number NCPDP Definition of Field Version D.0 FormatValid Values per the Standard Service Provider ID Qualifier 202-B2Code qualifying the Service Provider ID X(02) Blank=Not Specified 01=National Provider Identifier (NPI) 02=Blue Cross 03=Blue Shield 04=Medicare 05=Medicaid 06=UPIN 07=NCPDP Provider ID 08=State License 09=Champus 10=Health Industry Number (HIN) 11=Federal Tax ID 12=Drug Enforcement Administration (DEA) 13=State Issued 14=Plan Specific 15=HCID (HC IDea) 99=Other Service Provider ID 201-B1ID assigned to pharmacy or providerX(15) N/A Date of Service 401-D1 Identifies the date the prescription was filled or professional service rendered or subsequent payer began coverage following Part A expiration in a long-term care setting only 9(08) Format=CCYYMMDD Perspective HL7 Laboratory Results Use Case The following object identifiers (OIDs) are used within the Good Health Hospital (GHH): GHH Placer Order IDs: 2.16.840.1.113883.19.1122.14 GHH Lab Filler Order IDs: 2.16.840.1.113883.19.1122.4 The code system for the observation within the GHH is LOINC: 2.16.840.1.113883.6.1 The HL7 Confidentiality Code system: 2.16.840.1.113883.5.25 The HL7 v3 Message: Domain Content Excerpt The “Domain Content” starts with its own root element: observationEvent. The elements within specify the type of observation, the ID, the time of the observation, statusCode, and the results. The value for the actual result is shown in the value element. The interpretationCode element shows that the value has been interpreted as high (H), while referenceRange provides the normal values for this particular observation.
Source: Spronk (2007). http://www.ringholm.de/docs/04300_en.htm. Used under CC BY-SA 3.0,
https://creativecommons.org/licenses/by-sa/3.0/. Used with permission.
ANSI ASC X12N Standards
The ANSI Accredited Standards Committee (ASC) X12 develops standards in X12 and XML
formats for the electronic exchange of business information. One ASC X12 subcommittee,
X12N, has been specifically designated to deal with electronic data interchange (EDI) standards
in the insurance industry, and this subcommittee has a special health care task group, known as
TG2. According to the X12 TG2 website, “the purpose of the Health Care Task group shall be
the development and maintenance of data standards (both national and international) which shall
support the exchange of business information for healthcare administration. Health care data
includes, but is not limited to, such business functions as eligibility, referrals and authorizations,
claims, claim status, payment and remittance advice, and provider directories” (ASC X12, n.d.).
To this end ASC X12N has developed a set of standards that are monitored and updated
through ASC X12N work groups.
Table 11.4 lists the current X12 work group areas. A portion of the X12 5010 Professional Claim
standard is shown in Exhibit 11.2. The standard for Professional Claim alone is more than ninety
pages in length.
Table 11.4 X12 TG2 work groups
Source: ASC X12 (n.d.).
Work Group Number Work Group Name
WG1 Health Care Eligibility
WG2 Health Care Claims
WG3 Claim Payments
WG4 Enrollments
WG5 Claims Status
WG9 Patient Information
WG10 Health Care Services Review
WG15 Provider Information
WG20 Insurance—824 Implementation Guide
WG21 Health Care Regulation Advisory/Collaboration
Exhibit 11.2 X12 5010 Professional Claim Standard
5010
Element Identifier Description ID Min. Max. Usage Reg. Loop Loop Repeat
Values
837-P 5010
ISA INTERCHANGE CONTROL HEADER 1 R ___ 1
ISA01 Authorization Information Qualifier ID 2-2 R 00, 03
ISA02 Authorization Information AN 10-10 R
ISA03 Security Information Qualifier ID 2-2 R 00, 01
ISA04 Security Information AN 10-10 R
ISA05 Interchange ID Qualifier ID 2-2 R 01, 14, 20, 27, 28, 29,
30, 33, ZZ
ISA06 Interchange Sender ID AN 15-15 R
ISA07 Interchange ID Qualifier ID 2-2 R 01, 14, 20, 27, 28, 29,
30, 33, ZZ
ISA08 Interchange Receiver ID AN 15-15 R
ISA09 Interchange Date DT 6-6 R YYMMDD
ISA10 Interchange Time TM 4-4 R HHMM
ISA11 Interchange Control Standards ID 1-1 R
ISA12 Interchange Control Version NumberID 5-5 R 00501
ISA13 Interchange Control Number N0 9-9 R
ISA14 Acknowledgement Requested ID 1-1 R 0, 1
ISA15 Usage Indicator ID 1-1 R P, T
ISA16 Component Element Separator AN 1-1 R
GS FUNCTIONAL GROUP HEADER 1 R ___ 1
GS01 Functional Identifier Code ID 2-2 R
GS02 Application Sender Code AN 2-15 R
GS03 Application Receiver Code AN 2-15 R
GS04 Date DT 8-8 R CCYYMMDD
GS05 Time TM 4-8 R HHMM
GS06 Group Control Number N0 1-9 R
GS07 Responsible Agency Code ID 1-2 R X
GS08 Version Identifier Code AN 1-12 R 005010X222
Continuity of Care Document (CCD)
The Continuity of Care Document (CCD) is a standard for the electronic exchange of patient
summary information, so-called transportable patient care information. The current CCD
standard is actually a merger of two other standards: the HL7 Clinical Document Architecture
(CDA) standard and the ASTM Continuity of Care Record (CCR). There has been some
discussion among experts about the CCR and CCD being competing standards, but HL7 has
taken the position that CCD is an implementation of CCR and simply an evolution of the CCR
(Rouse, 2010). Although discussed in this section, the CCD standard is not solely a content
standard; it includes elements of a data exchange standard. It has an XML-based specification
for exchanging patient summary data, but it also includes a standard outline of the summary
content. The content sections of the CCD include the following:
Payers
Advance Directives
Support
Functional Status
Problems
Family History
Social History
Allergies
Medications
Medical Equipment
Immunizations
Vital Signs
Results
Procedures
Encounters
Plan of Care (Dolin, 2011)
Fast Health Interoperability Resources (FHIR)
Fast Health Interoperability Resources (FHIR) is currently being tested (as of this text’s
publication date) by a range of healthcare IT professionals. So far, the testing has led to
predominantly positive results, with many citing FHIR as having the potential to truly accelerate
healthcare IT interoperability. The difference between FHIR and other standards is that it goes
beyond the function of a traditional messaging system and includes modern web services to
exchange clinical information. FHIR builds on the HL7 Clinical Document Architecture (CDA)
and HL7 messaging, However, unlike CDA, FHIR enables granular pieces of information rather
than an entire summary document to be shared (Ahier, 2015). According to Ahier (2015), FHIR
offers easy-to-use tools not only to build faster and more efficient data exchange mechanisms
but also to use personal health care information to create “innovative new apps” with the
potential to create a “plug and play platform . . . similar to the Apple app store.”
Health Record Content and Functional Standards
Health record content and functional standards are not the same as messaging or data
exchange standards. These standards outline what should be included in an EHR or other
clinical record. They do not include technical specifications but rather the EHR content
requirements. As mentioned previously, the CCD and FHIR have content standards within
them, along with messaging standards. HL7 EHR-S (Electronic Health Record-System)
Functional Model is an example of a comprehensive EHR content and functional standard that
does not include technical specifications.
HL7 EHR-S Functional Model
The HL7 Health Record-System (EHR-S) Functional Model, Release 2 was published by Health
Level Seven International in 2014. The purpose of this functional model is to outline important
features and functions that should be contained in an EHR. Targeted users of the functional
model include vendors and care providers, and it has been recognized by the ISO as an
international standard (ISO 10781). The stated benefits of the functional model are as follows:
Provide an international standard for global use.
Enable a consistent framework for the development of profiles that are conformant to the base
model.
Support the goal of interoperability.
Provide a standard that is easily readable and understandable to an “everyday person,” which
enables a user to articulate his or her business requirements (HL7, 2014).
The EHR-S Functional Model is divided into seven sections:
Overarching (OV)
Care Provision (CP)
Care Provision Support (CPS)
Population Health Support (POP)
Administrative Support (AS)
Record Infrastructure (RI)
Trust Infrastructure (TI)
Each function within the model is identified by section and described by specific elements. Table
11.5 is an example of the function list for managing a problem list. Note: The list type indicates
Header (H), Function (F), or Conformance Criteria (C).
Table 11.5 Excerpt from the HL7 EHR-S Functional Model
ID Type Name Statement Description Conformance Criteria
CP.1 H Manage Clinical History Manage the patient’s clinical history lists used to
present summary or detailed information on patient health history. Patient Clinical History lists
are used to present succinct snapshots of critical health information including patient history,
allergy intolerance and adverse reactions, medications, problems, strengths, immunizations,
medical equipment/devices, and patient and family preferences.
CP.1.4 F Manage Problem List Create and maintain patient-specific problem lists. A
problem list may include but is not limited to chronic conditions, diagnoses, or symptoms,
injury/poisoning (both intentional and unintentional), adverse effects of medical care (e.g., drugs,
surgical), functional limitations, visit or stay-specific conditions, diagnoses, or symptoms . . .
CP.1.4 C 1. The system SHALL provide the ability to manage, as
discrete data, all active problems associated with a patient.
CP.1.4 C 2. The system SHALL capture and render a history of all
problems associated with a patient.
CP.1.4 C 3. The system SHALL provide the ability to manage
relevant dates including the onset date and resolution date of the problem.
Summary
Multiple standard-setting organizations have roles in standards development, leading to a
somewhat confusing array of current healthcare IT standards that address code sets,
vocabularies and terminology, data exchange and messaging, and content and function. The
standards developing organizations and standards discussed in this chapter, along with other
general IT standards, enable health care information systems to be interoperable, portable, and
to exchange data. The future of our healthcare system relies on having interoperable EHRs and
other health care information systems. Clearly, this will not be realized without standards. The
government, as well as the private sector, is actively engaged in promoting the development of
best practices for implementing health care IT standards. HIPAA and CMS, for example, have
had a significant impact on the adoption of specific health care information standards that focus
on code set, terminology, and transactions. The ONC is charged with coordinating the national
efforts for achieving interoperability among health care information systems, which has led to
their publication of the Interoperability Roadmap and annual Interoperability Standards
Advisories. Both of these tools will likely have a significant impact on the direction of national
standards development and cooperation among the many standards developing organizations.
References
Accredited Standards Committee X12 (ASC X12). (n.d.). X12N/TG2: Health care purpose and
scope. Retrieved September 6, 2016, from http://www.wpc-edi.com/onlyconnect/TG2.htm
Ahier, B. (2015, Jan. 6). FHIR and the future of interoperability. Retrieved November 10, 2016,
from http://www.healthcareitnews.com/news/fhir-and-future-interoperability
American Dental Association (ADA). (n.d.). Code on dental procedures and nomenclature (CDT
code). Retrieved September 7, 2016, from http://www.ada.org/en/publications/cdt/
American National Standards Institute (ANSI). (n.d.a). About ANSI. Retrieved September 7,
2016, from https://www.ansi.org/about_ansi/overview/overview.aspx?menuid=1
American National Standards Institute (ANSI). (n.d.b). Resources: Standards developing
organizations (SDOs). Retrieved September 7, 2016, from
https://www.standardsportal.org/usa_en/resources/sdo.aspx
American National Standards Institute (ANSI). (n.d.c). Standards activities overview. Retrieved
September 7, 2016, from
https://www.ansi.org/standards_activities/overview/overview.aspx?menuid=3
ASTM International. (2014, Nov.). ASTM standards for healthcare services, products and
technology. Retrieved September 5, 2016, from
http://www.astm.org/ABOUT/images/Medical_sector.pdf
ASTM International. (n.d.a). ASTM video. Retrieved September 5, 2016, from
https://www.astm.org/about-astm-corporate.html
ASTM International. (n.d.b). Standards & publications. Retrieved September 6, 2016, from
https://www.astm.org/Standard/standards-and-publications.html
Boone, K. W. (2012a, April 9). Health IT standards 101. Retrieved September 7, 2016, from
http://www.healthcareitnews.com/blog/health-it-standards-101
Boone, K. W. (2012b, March 26). An informatics model for HealthIT standards [Web log post].
Retrieved September 22, 2016, from
http://motorcycleguy.blogspot.com/2012/03/informatics-model-for-healthit.html
Case, J. (2011). Using RELMA or . . . In search of the missing LOINC [PowerPoint]. Retrieved
March 2012 from http://loinc.org/slideshows/lab-loinc-tutorial
CEN CENELEC. (n.d.). About us. Retrieved September 7, 2016, from
http://www.cencenelec.eu/aboutus/Pages/default.aspx
Centers for Disease Control and Prevention (CDC). (2016, June 21). IIS: HL7 standard code set
CVX—Vaccines administered. Vaccines and Immunizations. Retrieved September 6, 2016,
from http://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cvx
Centers for Medicare and Medicaid (CMS). (2002). NCPDP flat file format. NCPDP reference
manual. Retrieved September 6, 2016, from
http://www.cms.gov/Medicare/Billing/ElectronicBillingEDITrans/downloads/NCPDPflatfile.pdf
Centers for Medicare and Medicaid (CMS). (2013, April 2). Adopted standard and transactions,
adopted part D: E-prescribing standards. Retrieved September 5, 2016, from
https://www.cms.gov/Medicare/E-Health/Eprescribing/Adopted-Standard-and-Transactions.html
Centers for Medicare and Medicaid (CMS). (2016a, June 23). Adopted standards and operating
rules. Retrieved September 5, 2016, from
https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/Ado
ptedStandardsandOperatingRules.html
Centers for Medicare and Medicaid (CMS). (2016b, June 21). Standards-setting and related
organizations. Retrieved September 5, 2016, from
https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/Stan
dardsSettingandRelatedOrganizations.html
Department of Health and Human Services (HHS). (2008). The ONC-coordinated federal health
information technology strategic plan: 2008–2012. Retrieved August 2008 from
http://www.hhs.gov/healthit/resources/HITStrategicPlanSummary.pdf
Department of Health and Human Services (HHS). (2012). About ONC. The Office of the
National Coordinator for Health Information Technology. Retrieved March 2012 from
http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov_onc/1200
DICOM. (2016). Strategic document. DICOM: Digital Imaging and Communications in Medicine.
Retrieved September 6, 2016, from http://dicom.nema.org/dicom/geninfo/Strategy.pdf
Dolin, B. (2011). CDA and CCD for patient summaries. Retrieved November 10, 2016, from
https://www.hl7.org/documentcenter/public_temp_143D9F91-1C23-BA17-0C15A882DDE6815D
/calendarofevents/himss/2012/CDA%20and%20CCD%20for%20Patient%20Summaries.pdf
European Committee for Standardization (CEN). (n.d.). CEN/TC 251: Health informatics.
Retrieved September 7, 2016, from
https://standards.cen.eu/dyn/www/f?p=204:29:0::::FSP_ORG_ID,FSP_LANG_ID:6232,25&cs=
1FFF281A84075B985DD039F95A2CAB820#1
Food and Drug Administration (FDA). (2016, April 22). National drug code directory. Retrieved
September 7, 2016, from http://www.fda.gov/Drugs/InformationOnDrugs/ucm142438.htm
Hammond, W., & Cimino, J. (2006). Standards in biomedical informatics. In E. Shortliff & J.
Cimino (Eds.), Biomedical informatics (pp. 265–311). New York, NY: Springer-Verlag.
HealthIT.gov (2014). Meaningful use table series. Retrieved September 22, 2016, from
https://www.healthit.gov/sites/default/files/meaningfulusetablesseries1_110112.pdf
HealthIT.gov. (n.d.). About ONC. Retrieved September 5, 2016, from
https://www.healthit.gov/newsroom/about-onc
Health Level Seven International (HL7). (2014). HL7 EHR-System Functional Model, release 2.
Retrieved September 6, 2016, from
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=269
Health Level Seven International (HL7). (n.d.). HL7 version 2 product suite. Retrieved
September 6, 2016, from
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=185
Integrating the Healthcare Enterprise (IHE). (n.d.a.). IHE patient care coordination profiles.
Retrieved November 10, 2016, from
http://wiki.ihe.net/index.php/Profiles#IHE_Patient_Care_Coordination_Profiles
Integrating the Healthcare Enterprise (IHE). (n.d.b.). Profiles. Retrieved November 10, 2016,
from https://www.ihe.net/Profiles/
International Health Terminology Standards Development Organization (IHTSDO). (n.d.).
History of SNOMED CT. Retrieved September 7, 2016, from
http://www.ihtsdo.org/snomed-ct/what-is-snomed-ct/history-of-snomed-ct
International Organization for Standardization (ISO). (n.d.). About ISO. Retrieved September 7,
2016, from http://www.iso.org/iso/home/about.htm
National Committee on Vital and Health Statistics (NCVHS). (2003, Nov. 5). Letter to the
secretary: Recommendations for PMRI terminology standards. Retrieved March 2012 from
http://www.ncvhs.hhs.gov/031105lt3.pdf
National Council for Prescription Drug Programs (NCPDP). (2012). About. Retrieved March
2012 from http://www.ncpdp.org/about.aspx
National Library of Medicine (NLM). (2016a, Jan. 4). RxNorm overview. Unified Medical
Language System (UMLS). Retrieved September 6, 2016, from
https://www.nlm.nih.gov/research/umls/rxnorm/overview.html
National Library of Medicine (NLM). (2016b, July 13). SNOMED CT. Retrieved September 7,
2016, from https://www.nlm.nih.gov/healthit/snomedct/
Office of the National Coordinator for Health Information Technology (ONC). (2015). Connecting
health and care for the nation: A shared nationwide interoperability roadmap. Retrieved August
3, 2016, from
https://www.healthit.gov/sites/default/files/nationwide-interoperability-roadmap-draft-version-1.0.
pdf
Office of the National Coordinator for Health Information Technology (ONC). (2016). 2016
interoperability standards advisory: Best available standards and implementation specifications.
Retrieved September 5, 2016, from
https://www.healthit.gov/sites/default/files/2016-interoperability-standards-advisory-final-508.pdf
Regenstrief Institute, Inc. (n.d.). About LOINC. Retrieved September 7, 2016, from
https://loinc.org/background
Rouse, M. (2010, May). Continuity of care document. SearchHealthIT. Retrieved March 2012
from http://searchhealthit.techtarget.com/definition/Continuity-of-Care-Document-CCD
Spronk, R. (2007). HL7 message examples: Version 2 and version 3. Retrieved from
http://www.ringholm.de/docs/04300_en.htm
United States Food & Drug Administration (US FDA). (2016). National drug code directory.
Retrieved November 10, 2016, from
http://www.fda.gov/Drugs/InformationOnDrugs/ucm142438.htm
Washington Dental Service. (2012). CDT procedure code information. Retrieved March 2012
from
http://wwwldeltadentalwa.com/Dentist/Public/ResourceCenter/CDT%20Procedure%20Codes.as
px
