FAQ: Standards in Health IT

The following Frequently Asked Questions (FAQ) and answers provide high-level information on the concept and use of standards in health IT.  This page will be updated regularly - if you have a question about Standards that you'd like to see included, please submit a request to us at interop@himss.org.

A standard is "something established by authority, custom or general consent as a model 'Standard.'" (Merriam-Webster, n.d. Web. 26 Mar. 2014.)

  • Generally, standards are established by consensus and approved by a recognized body.
  • Most standards are voluntary in the sense that they are offered for adoptiong by people or industry, without being mandated in law.
  • Some standards become mandatory when they are adopted by regulators as legal requirements in particular domains.


Yes!  Standards are typically broken down into three categories:

  1. Formal Standards refer to a specification that has been approved and published by a standards setting organization, such as ISO or HL7 (see Who Creates Standards? below)
  2. De Jure Standards refer to standards mandated by federal legislation or regulation, or may refer generally to any formal standard.
  3. De Facto Standards refer to a specification, protocol or technology that has achieved widespread use and acceptance - often without being approved by any standards organization or by receiving such approval only after it has already achieved widespread use.



A Healthcare IT Standard provides the fundamental definitions for and structures of the data that can be communicated across a wide variety of healthcare use cases.


Standards may be developed by standards development or standards setting organizations, as well as by other groups such as trade unions or associations.

  • A standards organization, standards body, standards development organization (SDO) or standards setting organization (SSO) is any organization whose primary activities are developing, coordinating, promulgating, revising, amending, reissuing, interpreting, or otherwise producing standards that are intended to address the needs of some relatively wide base of affected adopters. (source)
  • In order to be recognized as an SDO, an organization should be accredited by the American National Standards Institute (ANSI) or the International Organization for Standardization (ISO).
  • SDOs ensure the unambiguous guidance of base standards to most effectively advance interoperability. These organizations can develop standards or package existing standards together to drive adoption of standards for particular use cases.
  • Standards can also be developed or adopted by groups, such as trade unions or trade associations. Standards organizations often have more input and usually develop voluntary standards - these might become mandatory if adopted by a government, business contract, etc. (source)
  • Many SDOs exist in the health IT arena. Some create standards, such as Health Level Seven (HL7).  Others, like Integrating the Healthcare Enterprise (IHE), are not SDOs but rather combine different base standards into profiles that are used to define a specific function or use case, and then are balloted. This creates a scenario that helps drive adoption of the base standards.

Standards can be found in almost every area of our daily lives, but why do we need them in healthcare information technology? Ideally in healthcare, data exchange schema and standards should permit data to be shared between clinician, lab, hospital, pharmacy and patient, regardless of application vendor, in order to improve healthcare (i.e., for delivery, outcomes and costs).

  • Standards are created in order to enable interoperability between two systems.
  • HIMSS's definition of interoperability incorporates the definition given by the Institute of Electronics and Electrical Engineers Standards Association (IEEE-SA), which is the most often quoted and/or paraphrased: "The ability of two or more systems or components to exchange information and to use the information that has been exchanged." (source)
  • A more recent IEEE definition states that a standard is the "ability of a system or a product to work with other systems or products without special effort on the part of the customer. Interoperability is made possible by the implementation of standards."
  • Standards provide a common framework for communicating across a variety of use cases, which thus enables system interoperability. An example is the Consolidated CDA (C-CDA) protocol, which is the base standard used for exchanging health information in compliance with requirements for the transition of care measure in Meaningful Use Stage Two. This standard allows two different EHR technologies to effectively exchange data and interpret it so that caregivers can use the data to treat patients.

There are many healthcare IT standards commonly used throughout the industry. The following are a sub-set of the most common standards.

Vocabulary / Terminology Standards - define the specific set of values that apply to a specific data type

  • SNOMED CT (Systemized Nomenclature of Medicine Clinical Terms)
  • ICD-10 (International Statistical Classification of Diseases and Related Health Problems, 10th revision)
    • Note: The US currently uses ICD-9, and will be moving to ICD-10 in 2015.
  • LOINC (Logical Observation Identifiers Names and Codes)
  • DICOM (Digital Imaging Communications in Medicine)
  • RxNorm - Normalized names for clinical drugs

Transport Messaging Standards - describe how messages get transported/exchanged between systems

  • SOAP (Service Object Access Protocol)
  • TCP/IP (Transmission Control Protocol / Internet Protocol)
  • Secure VPN (Virtual Private Network) over SSL (Secure Socket Layer)
  • DIRECT - like email, using SMTP (Simple Message Transport Protocol) or XDR (External Data Representation) protocols
  • EDI (Electronic Data Interchange)
  • IEEE (Institute of Electronics and Electrical Engineers) - used for medical device data

Security Standards - assure that the messages being transported are secure

Content Standards - describe what data elements are included, where they are included in the message, field length, data type, etc. Common examples of content and document standards include:

  • CDA (Clinical Document Architecture)
  • HL7 (Health Level Seven) V2.3x, V2.5x and V3
  • ASC X12 (Accredited Standards Committee) - examples include 277/278 eligibility

Reference Standards - have an assigned value by direct comparison with a reference base or model

Specification Standards - explicit set of requirements for item, material, component, system or device

Services Standards - assist in the translation, movement or securing of data

  • Certificates - certificate services assure that messages are secure
  • Provider Directory
  • CTS2 (Common Terminology Services 2) - services standard that helps address vocabulary and terminology standardization problems

Technical Standards - usually a formal document that established uniform engineering or technical criteria, methods, processes and practices


There are different perceptions of whether something is a "standard" or not. The following are some examples that help to clarify standards and their accompanying implementation guidance.

Are Implementation Guides "standards?"

  • Standards are helpful because they describe and constrain the "what" of the data movement. Implementation Guides (IG) describe the "how" for a specific use case.
    • Although an IG is referred to as a standard by HL7, the common understanding in the healthcare domain is that an IG is a companion to a standard that describes how the standard should be used to satisfy a specific healthcare use case. The IG is often balloted along with the standard.
  • An IG should specify which way a standard is to be applied in a particular use case - how to structure the data consistently, what vocabulary to use, etc. There are many ways you can implement a standard, but under an IG for a particular use case, the guide should direct one way to constrain the standard for a particular situation - removing ambiguity, achieving consistency, and increasing interoperability.
    • The CDA IG describes how to use the CDA standard template structure for nine different document types.
    • The HL7 IG is a document that provides guidance on implementing existing HL7 standards in an electronic system for a specific purpose.

How is "guidance" different from a "standard?"

  • Guidance Documents are documents prepared for FDA staff, applicants/sponsors, and the public that describe the agency's interpretation of, or policy on, a regulatory issue.
    • Guidance documents include, for example, documents that relate to:
      • Design, production, labeling, promotion, manufacturing and testing of regulated products
      • Processing, content and evaluation or approval of submissions
      • Inspection and enforcement policies
    • Guidance documents do not include:
      • Documents relating to internal FDA procedures, agency reports, or general information documents provided to consumers or health professionals
      • Speeches, journal articles and editorials, media interviews or other press materials
      • Warning letters, memoranda of understanding, or other communications directed to individual persons or firms
  • Good Guidance Practices (GGP) are the FDA's policies and procedures for developing, issuing and using guidance documents.

Are "operating rules" considered "standards?"

  • No. Operating rules - as stated in the Affordable Care Act - are "the necessary business rules and guidelines for the electronic exchange of information that are not defined by a standard or its implementation specifications."
  • According to CMS, "Operating rules are business rules and guidelines that are not already defined by the standards, which means they do not duplicate what is the standard. Nor are operating rules inconsistent or in conflict with the standard. Operating rules typically go above and beyond the standard with regard to a number of aspects, including data content. Thus, it is possible for covered entities to implement both the operating rules and the standards in every use case. (source)

Are Meaningful Use (MU) Health IT requirements considered "standards?"

  • No. Although the ONC 2014 Edition Standards and Certification Criteria specify standards that must be implemented by Certified EHR Technology (CEHRT) and must be used to meet the CMS Meaningful Use objectives and measures by physicians and hospitals, the MU requirements themselves are not standards.
    • For example, to create and transmit a transition of care document, a provider must use their CEHRT to create the summary document in a C-CDA and transmit the document using DIRECT or other certified transport protocols.

Are CMS rules that appear in the Federal Register considered "standards?"

  • No. Similarly to the ONC 2014 Edition Standards and Certification Criteria, CMS rules might specify standards that need to be used to meet certain objectives or criteria identified by the rule, but they are not standards.