2016 Interoperability Standards Advisory



200015494020002006602016 Interoperability Standards AdvisoryOffice of the National Coordinator for Health IT 0960002016 Interoperability Standards AdvisoryOffice of the National Coordinator for Health IT -4327197155005662839centerBest Available Standards and Implementation Specifications096000Best Available Standards and Implementation Specifications11641107703652[Draft for Comment]020000[Draft for Comment]5662839center096000Table of Contents TOC \o "1-3" \h \z \u Introduction PAGEREF _Toc430593064 \h 4Scope PAGEREF _Toc430593065 \h 4Purpose PAGEREF _Toc430593066 \h 4The 2016 Interoperability Standards Advisory PAGEREF _Toc430593067 \h 5Section I: Best Available Vocabulary/Code Set/Terminology Standards and Implementation Specifications PAGEREF _Toc430593068 \h 8I-A: Allergies PAGEREF _Toc430593069 \h 8I-B: Care Team Member PAGEREF _Toc430593070 \h 9I-C: Encounter Diagnosis PAGEREF _Toc430593071 \h 9I-D: Race and Ethnicity PAGEREF _Toc430593072 \h 10I-E: Family Health History PAGEREF _Toc430593073 \h 10I-F: Functional Status/Disability PAGEREF _Toc430593074 \h 11I-G: Gender Identity, Sex, and Sexual Orientation PAGEREF _Toc430593075 \h 11I-H: Immunizations PAGEREF _Toc430593076 \h 13I-I: Industry and Occupation PAGEREF _Toc430593077 \h 14I-J: Lab tests PAGEREF _Toc430593078 \h 14I-K: Medications PAGEREF _Toc430593079 \h 15I-L: Numerical References & Values PAGEREF _Toc430593080 \h 15I-M: Patient “problems” (i.e. conditions) PAGEREF _Toc430593081 \h 15I-N: Preferred Language PAGEREF _Toc430593082 \h 16I-O: Procedures PAGEREF _Toc430593083 \h 16I-P: Radiology (interventions and procedures) PAGEREF _Toc430593084 \h 17I-Q: Smoking Status PAGEREF _Toc430593085 \h 17I-R: Unique Device Identification PAGEREF _Toc430593086 \h 17I-S: Vital Signs PAGEREF _Toc430593087 \h 18Section II: Best Available Content/Structure Standards and Implementation Specifications PAGEREF _Toc430593088 \h 18II-A: Admission, Discharge, and Transfer PAGEREF _Toc430593089 \h 18II-B: Care Plan PAGEREF _Toc430593090 \h 19II-C: Clinical Decision Support PAGEREF _Toc430593091 \h 19II-D: Drug Formulary & Benefits PAGEREF _Toc430593092 \h 19II-E: Electronic Prescribing PAGEREF _Toc430593093 \h 20II-F: Family health history (clinical genomics) PAGEREF _Toc430593094 \h 21II-G: Images PAGEREF _Toc430593095 \h 22II-H: Laboratory PAGEREF _Toc430593096 \h 23II-I: Patient Education Materials PAGEREF _Toc430593097 \h 24II-J: Patient Preference/Consent PAGEREF _Toc430593098 \h 25II-K: Public Health Reporting PAGEREF _Toc430593099 \h 25II-L: Quality Reporting PAGEREF _Toc430593100 \h 29II-M: Representing clinical health information as a “resource” PAGEREF _Toc430593101 \h 29II-N: Segmentation of sensitive information PAGEREF _Toc430593102 \h 30II-O: Summary care record PAGEREF _Toc430593103 \h 30Section III: Best Available Standards and Implementation Specifications for Services PAGEREF _Toc430593104 \h 31III-A: An unsolicited “push” of clinical health information to a known destination PAGEREF _Toc430593105 \h 31III-B: Clinical Decision Support Services PAGEREF _Toc430593106 \h 32III-C: Image Exchange PAGEREF _Toc430593107 \h 33III-D: Provider Directory PAGEREF _Toc430593108 \h 34III-E: Publish and Subscribe PAGEREF _Toc430593109 \h 34III-F: Query PAGEREF _Toc430593110 \h 35III-G: Resource Location PAGEREF _Toc430593111 \h 37Section IV: Questions and Requests for Stakeholder Feedback PAGEREF _Toc430593112 \h 38Appendix I - Annual Process to Update the Interoperability Standards Advisory PAGEREF _Toc430593113 \h 40Appendix II – Sources of Security Standards PAGEREF _Toc430593114 \h 41Appendix III - Revision History PAGEREF _Toc430593115 \h 42The Interoperability Standards Advisory (ISA) represents the Office of the National Coordinator for Health Information Technology’s current thinking and is for informational purposes only. It is non-binding and does not create nor confer any rights or obligations for or on any person or entity. IntroductionThe Interoperability Standards Advisory (ISA) process represents the model by which the Office of the National Coordinator for Health Information Technology (ONC) will coordinate the identification, assessment, and determination of the “best available” interoperability standards and implementation specifications for industry use to fulfill specific clinical health IT interoperability needs. The Draft 2016 Interoperability Standards Advisory (Draft 2016 Advisory) remains focused on clinical health information technology (IT) interoperability and is published at . For detailed background on the Advisory, its purpose, and its processes please review the 2015 Advisory. Updates to the Draft 2016 Advisory’s substance and structure reflect input obtained from the public at large throughout 2015 and the HIT Standards Committee. A final 2016 Advisory will be published at the end of 2015. At a high-level, the most substantial changes between the 2015 and 2016 Advisory are structural changes to way in which the content is organized, presented, and annotated. This includes the following: Instead of referencing a general “purpose,” a section’s lead-in is framed to convey an “interoperability need” stakeholders may express to convey an outcome they would want to achieve with interoperability. A set of six informative characteristics are now associated with each referenced standard and iimplementation specification to give readers an overall sense of maturity and adoptability.Associated with each “interoperability need” are two subsections.The first would identify any known limitations, dependencies, or preconditions associated with best available standards and implementation specifications.The second would identify, where applicable, known “security patterns” associated with best available standards and implementation specifications. This subsection’s goal would be to identify the generally reusable security techniques applicable to interoperability need(s) without prescribing or locking-in particular security standards.A security standards sources appendix is included to point stakeholders to the entities that maintain and curate relevant security standards information.A revision history section has been added at the end of the document.This document is a draft for comment and will continue to be refined during the public comment period. Additionally, because this draft includes both new structural and content sections please note that content for many of the new structural subsections is intentionally incomplete. Those sections that are more fully populated were done so to give the public an early opportunity to weigh in on and react to perceived value that these subsections could provide. Your feedback is critical to improve and refine these new subsections. ScopeThe standards and implementation specifications listed in this advisory focus explicitly on clinical health IT systems’ interoperability. Thus, the advisory’s scope includes electronic health information created in the context of treatment and subsequently used to accomplish a purpose for which interoperability is needed (e.g., a referral to another care provider, public health reporting). The advisory does not include within its scope administrative/payment oriented interoperability purposes or administrative transaction requirements that are governed by HIPAA and administered by the Centers for Medicare & Medicaid Services (CMS).PurposeThe ISA is meant to serve at least the following purposes:To provide the industry with a single, public list of the standards and implementation specifications that can best be used to fulfill specific clinical health information interoperability needs. To reflect the results of ongoing dialogue, debate, and consensus among industry stakeholders when more than one standard or implementation specification could be listed as the best available.To document known limitations, preconditions, and dependencies as well as known security patterns among referenced standards and implementation specifications when they are used to fulfill a specific clinical health IT interoperability need. The 2016 Interoperability Standards AdvisoryThe following represents an updated list of the best available standard(s) and implementation specification(s) in comparison to the 2015 Advisory. The list is not exhaustive but it is expected that future advisories will incrementally address a broader range of clinical health IT interoperability needs. While the standards and implementation specifications included in an advisory may also be adopted in regulation (already or in the future), required as part of a testing and certification program, or included as procurement conditions, the advisory is non-binding and serves to provide clarity, consistency, and predictability for the public regarding ONC’s assessment of the best available standards and implementation specifications for a given interoperability need. It is also plausible, intended, and expected for advisories to be “ahead” of where a regulatory requirement may be, in which case a standard or implementation specification’s reference in an advisory may serve as the basis for industry or government action. When one standard or implementation specification is listed as the “best available,” it reflects ONC’s current assessment and prioritization of that standard or implementation specification for a given interoperability need. When more than one standard or implementation specification is listed as the best available, it is intended to prompt industry dialogue as to whether one standard or implementation specification is necessary or if the industry can efficiently interoperate more than one. “Best Available” CharacteristicsThe 2015 Advisory introduced several “characteristics” and additional factors by which standards and implementation specifications were determined to be the “best available.” For example, whether a standard was in widespread use or required by regulation. Public comment and feedback from the HIT Standards Committee indicated that more explicit context for each standard and implementation specification would benefit stakeholders and clearly convey a standard’s relative maturity and adoptability. This added context will allow for greater scrutiny of a standard or implementation specification despite its inclusion as the “best available.” For instance, a standard may be referenced as best available, yet not be widely adopted or only proven at a small scale. Public comment noted that in the absence of additional context, stakeholders could inadvertently over-interpret the “best available” reference and apply a standard or implementation specification to a particular interoperability need when it may not necessarily be ready or proven at a particular scale. The 2016 Advisory uses the following six informative characteristics to provide added context. When known, it also lists an “emerging alternative” to a standard or implementation specification, which is shaded in a lighter color, and italicized for additional emphasis. Interoperability need: [Descriptive Text]Standard/Implementation SpecificationStandards ProcessMaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard FinalProductionYesFreeYesEmerging Alternative StandardDraftPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Descriptive text with “(recommended by the HIT Standards Committee)” included in cases where the HIT Standards Committee recommended the text, and on which public feedback is sought. Descriptive textThe following describes the six characteristics that were added to the Advisory in detail in order to better inform stakeholders about the maturity and adoptability of a given standard or implementation specification and provides definitions for the terms and symbols used throughout the Advisory. #1: Standards Process Maturity This characteristic conveys a standard or implementation specification’s maturity in terms of its stage within a particular organization’s approval/voting process. “Final” – when this designation is assigned, the standard or implementation specification is considered “final text” or “normative” by the organization that maintains it. “Draft” – when this designation is assigned, the standard or implementation specification is considered to be a Draft Standard for Trial Use (DSTU) or in a “trial implementation” status by the organization that maintains it. #2: Implementation Maturity This characteristic conveys a standard or implementation specification’s maturity based on its implementation state.“Production” – when this designation is assigned, the standard or implementation specification is being used in production to meet a health care interoperability need. “Pilot” – when this designation is assigned, the standard or implementation specification is being used at limited scale or only as part of pilots to meet a health care interoperability need. #3: Adoption Level This characteristic conveys a standard or implementation specification’s approximate level of adoption in health care. The following scale is used:“Unknown” – indicates no known status for the current level of adoption in health care. indicates 0% to 20% adoption. indicates 21% to 40% adoption.indicates 41% to 60% adoption. indicates 61% to 80% adoption. indicates 81% to 100% adoption. #4: RegulatedThis characteristic (provided as a “Yes” or “No”) conveys whether a standard or implementation specification has been adopted in regulation or required by HHS for a particular interoperability need. #5: CostThis characteristic conveys whether a standard or implementation specification costs money to obtain. “$” – when this designation is assigned, it signifies that some type of payment needs to be made in order to obtain the standard or implementation specification.“Free” – when this designation is assigned, it signifies that the standard or implementation specification can be obtained without cost. This designation applies even if a user account or license agreement is required to obtain the standard at no cost. #6: Test Tool AvailabilityThis characteristic conveys whether a test tool is available to evaluate health IT’s conformance to the standard or implementation specification for the particular interoperability need.“Yes” – when this designation is assigned, it signifies that a test tool is available for a standard or implementation specification and is free to use. Where available, a hyperlink pointing to the test tool will be included.“Yes$”– when this designation is assigned, it signifies that a test tool is available for a standard or implementation specification and has a cost associated with its use. Where available, a hyperlink pointing to the test tool will be included.“No” – when this designation is assigned, it signifies that no test tool is available for a standard or implementation specification.“N/A” – when this designation is assigned, it signifies that a test tool for the standard or implementation would be “not applicable.” The Structure of Sections I through IIIFor the purposes of the lists that follow, a specific version of the standard or implementation specification is not listed unless it makes a helpful distinction. The standards and associated implementation specifications for clinical health IT interoperability are grouped into these categories:Vocabulary/code sets/terminology (i.e., “semantics”).Content/structure (i.e., “syntax”).Services (i.e., the infrastructure components deployed and used to fulfill specific interoperability needs)At the recommendation of the HIT Standards Committee, we have removed the “transport” section which previously referenced low-level transport standards because 1) it was deemed to not provide additional clarity/value to stakeholders; and 2) the standards and implementation specifications in the “services” section included them as applicable. Thus, focusing on that section in addition to vocabulary and content were deemed more impactful and necessary.Section IV includes questions on which public input is requested. Last, as noted in the 2015 Advisory, this Advisory is not intended to imply that a standard listed in one section would always be used or implemented independent of a standard in another section. To the contrary, it will often be necessary to combine the applicable standards from multiple sections to achieve interoperability for a particular clinical health information interoperability purpose.Section I: Best Available Vocabulary/Code Set/Terminology Standards and Implementation SpecificationsI-A: Allergies Interoperability Need: Representing patient allergic reactionsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardSNOMED-CTFinalProductionNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requested Feedback requestedInteroperability Need: Representing patient allergens: medicationsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardRxNormFinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: When a medication allergy necessitates capture by medication class, HYPERLINK "" NDF-RT is best available (as recommended by the HIT Standards Committee)Feedback requestedInteroperability Need: Representing patient allergens: food substances TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard SNOMED-CTFinalUnknownUnknownNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedInteroperability Need: Representing patient allergens: environmental substances TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard [See Question 4-5]Limitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Currently, there are no vocabulary code sets considered “best available” for environmental allergens.Feedback requestedI-B: Care Team Member Interoperability Need: Representing care team member (health care provider)TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardNational Provider Identifier (NPI)FinalProductionNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: For the purpose of recording a care team member, it should be noted that NPI permits, but does not require, non-billable care team members to apply for an NPI number to capture the concept of ‘person’. There is a SNOMED-CT value set for a “subjects role in the care setting” that could also be used in addition to NPI for care team members.Feedback requestedI-C: Encounter Diagnosis Interoperability Need: Documenting patient encounter diagnosis TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard SNOMED-CTFinalProductionYesFreeN/AStandard ICD-10-CMFinalProduction YesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedI-D: Race and EthnicityInteroperability Need: Representing patient race and ethnicityTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardOMB standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, Oct 30, 1997FinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The HYPERLINK "" CDC Race and Ethnicity Code Set Version 1.0, which expands upon the OMB standards may help to further define race and ethnicity for this interoperability need as it allows for multiple races and ethnicities to be chosen for the same patient. The HIT Standards Committee noted that the high-level race/ethnicity categories in the OMB Standard may be suitable for statistical or epidemiologic purposes but may not be adequate in the pursuit of precision medicine and enhancing therapy or clinical decisions.Feedback requestedI-E: Family Health HistoryInteroperability Need: Representing patient family health history TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardSNOMED-CTFinalProduction44455334000YesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Some details around family genomic health history may not be captured by SNOMED-CT (recommended by the HIT Standards Committee)Feedback requestedI-F: Functional Status/Disability Interoperability Need: Representing patient functional status and/or disability TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard[See Question 4-5]Limitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedI-G: Gender Identity, Sex, and Sexual OrientationInteroperability Need: Representing patient gender identity TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardSNOMED-CTFinalUnknownUnknownNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The HIT Standards Committee recommended collecting discrete structured data on patient gender identity, sex, and sexual orientation following recommendations issued in a report by The Fenway Institute and the Institute of Medicine.Feedback requestedInteroperability Need: Representing patient sex (at birth) TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardFor Male and Female, HL7 Version 3 Value Set for Administrative GenderFinalProduction-635-4445000NoFreeN/AStandardFor Unknown, HL7 Version 3 Null Flavor FinalProduction-6350254000NoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The HIT Standards Committee recommended collecting discrete structured data on patient gender identity, sex, and sexual orientation following recommendations issued in a HYPERLINK "" report by The Fenway Institute and the Institute of Medicine.Feedback requestedInteroperability Need: Representing patient sexual orientation TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardSNOMED-CTFinalUnknownUnknownNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The HIT Standards Committee recommended collecting discrete structured data on patient gender identity, sex, and sexual orientation following recommendations issued in a HYPERLINK "" report by The Fenway Institute and the Institute of Medicine.Feedback requestedI-H: Immunizations Interoperability Need: Representing immunizations – historical TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 Standard Code Set CVX—Clinical Vaccines AdministeredFinalProduction876301841500YesFreeN/AStandard HL7 Standard Code Set MVX -Manufacturing Vaccine FormulationFinalProduction NoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: HL7 CVX codes are designed to represent administered and historical immunizations and will not contain manufacturer-specific information. When an MVX code is paired with a CVX (vaccine administered) code, the specific trade named vaccine may be indicated providing further specificity as to the vaccines administered.Feedback requestedInteroperability Need: Representing immunizations – administered TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 Standard Code Set CVX—Clinical Vaccines AdministeredFinalProductionYesFreeN/AStandardNational Drug CodeFinalProductionNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: HL7 CVX codes are designed to represent administered and historical immunizations and will not contain manufacturer-specific information. According to the HIT Standards Committee, National Drug (NDC) codes may provide value to stakeholders for inventory management, packaging, lot numbers, etc., but do not contain sufficient information to be used for documenting an administered immunization across organizational boundaries. Feedback requestedI-I: Industry and OccupationInteroperability Need: Representing patient industry and occupation TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard[See Question 4-5]Limitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedI-J: Lab testsInteroperability Need: Representing laboratory tests and observations TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardLOINCFinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The HIT Standards Committee recommended that laboratory test and observation work in conjunction with values or results which can be answered numerically or categorically. If the value/result/answer to a laboratory test and observation is categorical that answer should be represented with the SNOMED-CT terminology. The HIT Standards Committee recommended that organizations not using LOINC codes should maintain and publish a mapping of their codes to the LOINC equivalent until migration to LOINC has occurred.Feedback requestedI-K: MedicationsInteroperability Need: Representing patient medications TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardRxNormFinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedI-L: Numerical References & ValuesInteroperability Need: Representing numerical references and values TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardThe Unified Code of Units of MeasureFinalProductionNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The case sensitive version is the correct unit string to be used for interoperability purposes per HIT Standards Committee recommendations. Feedback requestedI-M: Patient “problems” (i.e. conditions) Interoperability Need: Representing patient “problems” (i.e., conditions) TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardSNOMED-CTFinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedI-N: Preferred Language Interoperability Need: Representing patient preferred languageTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardRFC 5646FinalProductionUnknownNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: RFC 5646 encompasses ISO 639-1, ISO 639-2, ISO 639-3 and other standards related to identifying preferred language.Feedback requestedI-O: ProceduresInteroperability Need: Representing dental procedures performedTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardCode on Dental Procedures and Nomenclature (CDT) FinalProductionYes$N/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: CDT is a proprietary terminology standard. Feedback requestedInteroperability Need: Representing medical procedures performedTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard SNOMED-CTFinalProductionYesFreeN/AStandard the combination of CPT-4/HCPCSFinalProduction Yes$N/AStandard ICD-10-PCSFinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedI-P: Radiology (interventions and procedures) Interoperability Need: Representing radiological interventions and procedures TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardLOINCFinalProductionNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Radlex and LOINC are currently in the process of creating a common data model to link the two standards together to promote standardized indexing of radiology terms as indicated by public comments and HIT Standards Committee recommendations.Feedback requestedI-Q: Smoking Status Interoperability Need: Representing patient smoking statusTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardSNOMED-CTFinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: According to the HIT Standards Committee, there are limitations in SNOMED-CT for this interoperability need, which include not being able to capture severity of dependency, quit attempts, lifetime exposure, and use of e-Cigarettes. Feedback requestedI-R: Unique Device Identification Interoperability Need: Representing unique implantable device identifiers TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardUnique device identifier as defined by the Food and Drug Administration at 21 CFR 830.3FinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedI-S: Vital SignsInteroperability Need: Recording patient vital signs TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardLOINCFinalProductionNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedSection II: Best Available Content/Structure Standards and Implementation SpecificationsII-A: Admission, Discharge, and TransferInteroperability Need: Sending a notification of a patient’s admission, discharge and/or transfer statusTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardHL7 2.x ADT messageFinalProductioncentercenterNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Any HL7 2.x version messaging standard associated with ADT is acceptable.A variety of transport protocols are available for use for ADT delivery. Trading partners will need to determine which transport tools best meet their interoperability needs.Feedback requestedII-B: Care PlanInteroperability Need: Documenting patient care plans TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 Clinical Document Architecture (CDA?), Release 2.0, Final EditionFinalProductionNoFreeNoImplementation Specification HL7 Implementation Guide for CDA? Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1DraftPilot UnknownNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requested Feedback requestedII-C: Clinical Decision Support Interoperability Need: Shareable clinical decision supportTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 Implementation Guide: Clinical Decision Support Knowledge Artifact Implementation Guide, Release 1.3, Draft Standard for Trial Use.DraftPilotUnknownNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedII-D: Drug Formulary & BenefitsInteroperability Need: The ability for pharmacy benefit payers to communicate formulary and benefit information to prescribers systemsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard NCPDP Formulary and Benefits v3.0FinalProductioncentercenterYes$NoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The HIT Standards Committee noted that the NCPDP Real Time Prescription Benefit Inquiry (RTPBI) is an alternative in development that should be monitored as a potential emerging alternative. Feedback requestedII-E: Electronic Prescribing Interoperability Need: A prescriber’s ability to create a new prescription to electronically send to a pharmacy TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard NCPDP SCRIPT Standard, Implementation Guide, Version 10.6FinalProductionYes$YesLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The “New Prescription” transaction is best suited for this interoperability need. Both the prescriber and the receiving pharmacy must have their systems configured for the transaction in order to facilitate successful exchange. Feedback requestedInteroperability Need: Prescription refill requestTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard NCPDP SCRIPT Standard, Implementation Guide, Version 10.6FinalProductionNo$NoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The “Refill Request” transaction is best suited for this interoperability need. Both the prescriber and the receiving pharmacy must have their systems configured for the transaction in order to facilitate successful exchange. Feedback requestedInteroperability Need: Cancellation of a prescriptionTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard NCPDP SCRIPT Standard, Implementation Guide, Version 10.6FinalProductionUnknownNo$NoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The “Cancel” transaction is best suited for this interoperability need. Both the prescriber and the receiving pharmacy must have their systems configured for the transaction in order to facilitate successful exchange. Feedback requestedInteroperability Need: Pharmacy notifies prescriber of prescription fill status TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard NCPDP SCRIPT Standard, Implementation Guide, Version 10.6FinalProductionUnknownNo$NoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The “Fill Status” transaction is best suited for this interoperability need. Both the prescriber and the receiving pharmacy must have their systems configured for the transaction in order to facilitate successful exchange. Feedback requestedInteroperability Need: A prescriber’s ability to obtain a patient’s medication history TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard NCPDP SCRIPT Standard, Implementation Guide, Version 10.6FinalProductionNo$NoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The “Medication History” transaction is best suited for this interoperability need. Both the prescriber and the receiving pharmacy must have their systems configured for the transaction in order to facilitate successful exchange. Feedback requestedII-F: Family health history (clinical genomics)Interoperability Need: Representing family health history for clinical genomicsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 Version 3 Standard: Clinical Genomics; PedigreeFinalProductionYesFreeNoImplementation Specification HL7 Version 3 Implementation Guide: Family History/Pedigree Interoperability, Release 1FinalProductionNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: According to the HIT Standards Committee, there is no available vocabulary to capture family genomic health history. According to the HIT Standards Committee, further constraint of this standard and implementation specification may be required to support this interoperability need. Feedback requestedII-G: Images [See Question 4-7]Interoperability Need: Medical image formats for data exchange and distributionTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard Digital Imaging and Communications in Medicine (DICOM)FinalProductionNoFreeNoImplementation Specification Image Acquisition Technology Specific Service/Object Pairs (SOP) Classes [See Question 4-8]FinalProductionNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedInteroperability Need: Exchange of imaging reportsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard Digital Imaging and Communications in Medicine (DICOM)FinalProductionNoFreeNoImplementation Specification PS3.20 Digital Imaging and Communications in Medicine (DICOM) Standard – Part 20: Imaging Reports using HL7 Clinical Document Architecture.FinalProductionNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedII-H: LaboratoryInteroperability Need: Receive electronic laboratory test resultsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 2.5.1FinalProductionNoFreeNoImplementation SpecificationHL7 Version 2.5.1 Implementation Guide: S&I Framework Lab Results Interface, Release 1—US Realm [HL7 Version 2.5.1: ORU_R01] Draft Standard for Trial Use, July 2012FinalProductionYesFreeYesEmerging Alternative Implementation Specification HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Results Interface Implementation Guide, Release 1 DSTU Release 2 - US Realm [no hyperlink available yet]DraftPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: HL7 Laboratory US Realm Value Set Companion Guide, Release 1, September 2015, provides cross-implementation guide value set definitions and harmonized requirements.Feedback requestedInteroperability Need: Ordering labs for a patient TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 2.5.1FinalProductionNoFreeNoImplementation specification HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR, Release 1 DSTU Release 2 - US Realm[no hyperlink available yet]DraftPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: HL7 Laboratory US Realm Value Set Companion Guide, Release 1, September 2015, provides cross-implementation guide value set definitions and harmonized requirements.Feedback requestedInteroperability Need: Support the transmission of a laboratory’s directory of services to health IT. TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 2.5.1FinalProductionNoFreeNoStandard HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework, Release 2, DSTU Release 2[no hyperlink available yet]DraftPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: HL7 Laboratory US Realm Value Set Companion Guide, Release 1, September 2015, provides cross-implementation guide value set definitions and harmonized requirements.Feedback requestedII-I: Patient Education Materials Interoperability Need: A standard mechanism for clinical information systems to request context-specific clinical knowledge form online resourcesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2.FinalProduction YesFreeNoImplementation Specification HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1.FinalProduction NoFreeNoImplementation Specification HL7 Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton), Release 4.FinalProduction NoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedII-J: Patient Preference/Consent[See Question 4-9]Interoperability Need: Recording patient preferences for electronic consent to access and/or share their health information with other care providers TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityImplementation Specification IHE Basic Patient Privacy Consents (BPPC)FinalProduction NoFreeNoImplementation SpecificationIHE Cross Enterprise User Authorization (XUA)FinalProductionNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedII-K: Public Health Reporting Interoperability Need: Reporting antimicrobial use and resistance information to public health agenciesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 Clinical Document Architecture (CDA?), Release 2.0, Final EditionFinalProductionNoFreeNoImplementation Specification HL7 Implementation Guide for CDA? Release 2 – Level 3: Healthcare Associated Infection Reports, Release 1, U.S. Realm.FinalProductionNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: This is a national reporting system to CDC. Stakeholders should refer to implementation guide for additional details and contract information for enrolling in the program.Feedback requestedInteroperability Need: Reporting cancer cases to public health agenciesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 Clinical Document Architecture (CDA?), Release 2.0, Final EditionFinalProductionNoFreeNoImplementation Specification HL7 Implementation Guide for CDA? Release 2: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1 - US RealmDraftProductionYesFreeYesEmerging Alternative Implementation SpecificationHL7 CDA ? Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1, DSTU Release 1.1 – US RealmDraftPilot NoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Stakeholders should refer to the health department in their state or local jurisdiction to determine onboarding procedures, obtain a jurisdictional implementation guide if applicable, and determine which transport methods are acceptable for submitting cancer reporting data as there may be jurisdictional variation or requirements.Feedback requestedInteroperability Need: Case reporting to public health agenciesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool Availability(1) Implementation Specification IHE Quality, Research, and Public Health Technical Framework Supplement, Structured Data Capture, Trial Implementation, HL7 Consolidated CDA? Release 2.0DraftPilotNoFreeNo(2) Standard Fast Healthcare Interoperability Resources (FHIR)DraftPilotNoFreeNo(2) Implementation SpecificationStructured Data Capture Implementation GuideDraftPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Electronic case reporting is not wide spread and is determined at the state or local jurisdiction.Feedback requested`Interoperability Need: Electronic transmission of reportable lab results to public health agenciesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 2.5.1FinalProductionYesFreeNoImplementation specificationHL7 Version 2.5.1: Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1 with Errata and Clarifications and ELR 2.5.1 Clarification Document for EHR Technology CertificationFinalProductionYesFreeYesEmerging Alternative Implementation Specification HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 2 (US Realm), Draft Standard for Trial Use, Release 1.1DraftPilotUnknownNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Stakeholders should refer to the health department in their state or local jurisdiction to determine onboarding procedures, obtain a jurisdictional implementation guide if applicable, and determine which transport methods are acceptable for submitting ELR as there may be jurisdictional variation or requirements.Feedback requestedInteroperability Need: Sending health care survey information to public health agenciesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 Clinical Document Architecture (CDA?), Release 2.0, Final EditionFinalProductionNoFreeNoImplementation Specification HL7 Implementation Guide for CDA? R2: National Health Care Surveys (NHCS), Release 1 - US Realm [See Question 4-6]DraftPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: This is a national reporting system to CDC. Stakeholders should refer to the National Health Care Survey Program at: for information on participation.Feedback requestedInteroperability Need: Reporting administered immunizations to immunization registryTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 2.5.1FinalProductioncentercenterYesFreeNoImplementation SpecificationHL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.4FinalProductionYesFreeYesEmerging Alternative Implementation Specification HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5FinalPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Stakeholders should refer to the health department in their state or local jurisdiction to determine onboarding procedures, obtain a jurisdictional implementation guide if applicable, and determine which transport methods are acceptable for submitting immunization registry data as there may be jurisdictional variation or requirements.Feedback requestedInteroperability Need: Reporting syndromic surveillance to public health (emergency department, inpatient, and urgent care settings)TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 2.5.1FinalProductioncentercenterYesFreeNoImplementation SpecificationPHIN Messaging Guide for Syndromic Surveillance: Emergency Department and Urgent Care Data Release 1.1FinalProductionYesFreeYesEmerging Alternative Implementation Specification PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Care Settings, Release 2.0FinalPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Stakeholders should refer to the health department in their state or local jurisdiction to determine onboarding procedures, obtain a jurisdictional implementation guide if applicable, and determine which transport methods are acceptable for submitting syndromic surveillance data as there may be jurisdictional variation or requirements.Feedback requestedII-L: Quality Reporting Interoperability Need: Reporting aggregate quality data to quality reporting initiativesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 Clinical Document Architecture (CDA?), Release 2.0, Final EditionFinalProduction NoFreeNoImplementation Specification HL7 Implementation Guide for CDA? Release 2: Quality Reporting Document Architecture - Category III (QRDA III), DRAFT Release 1DraftProductionYesFreeYesLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedInteroperability Need: Reporting patient-level quality data to quality reporting initiatives TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 Clinical Document Architecture (CDA?), Release 2.0, Final EditionFinalProduction NoFreeNoImplementation SpecificationHL7 Implementation Guide for CDA? Release 2: Quality Reporting Document Architecture – Category I, DSTU Release 2 (US Realm)DraftProductionYesFreeYesEmerging Alternative Implementation Specification HL7 CDA? R2 Implementation Guide: Quality Reporting Document Architecture - Category I (QRDA I) DSTU Release 3 (US Realm)DraftPilotYesFreeYesLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedII-M: Representing clinical health information as a “resource”Interoperability Need: Representing clinical health information as “resource”TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard Fast Healthcare Interoperability Resources (FHIR)DraftPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedII-N: Segmentation of sensitive information Interoperability Need: Document-level segmentation of sensitive information TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 Clinical Document Architecture (CDA?), Release 2.0, Final EditionFinalProduction NoFreeNoImplementation Specification Consolidated HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1FinalPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedII-O: Summary care record Interoperability Need: Support a transition of care or referral to another provider TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 Clinical Document Architecture (CDA?), Release 2.0, Final EditionFinalProduction centercenter00NoFreeNoImplementation Specification Consolidated CDA? Release 1.1 (HL7 Implementation Guide for CDA? Release 2: IHE Health Story Consolidation, DSTU Release 1.1 - US Realm)DraftProductionYesFreeYesEmerging Alternative Implementation SpecificationHL7 Implementation Guide for CDA? Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1DraftPilot UnknownNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: There are several specific document templates within the C-CDA implementation specification. Trading partners will need to ensure that their systems are capable of supporting specific document templates.Feedback requestedSection III: Best Available Standards and Implementation Specifications for Services [See Question 4-10]III-A: An unsolicited “push” of clinical health information to a known destination [See Question 4-3]Interoperability Need: An unsolicited “push” of clinical health information to a known destination between individuals TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardApplicability Statement for Secure Health Transport v1.1 (“Direct”)FinalProduction YesFreeYesEmerging Alternative StandardApplicability Statement for Secure Health Transport v1.2FinalPilotNoFreeNoImplementation SpecificationXDR and XDM for Direct Messaging SpecificationFinalProductionYesFreeYesImplementation Specification IG for Direct Edge ProtocolsFinalProductionYesFreeYesImplementation Specification IG for Delivery Notification in DirectFinalProductionNoFreeNoEmerging Alternative StandardFast Healthcare Interoperability Resources (FHIR)DraftPilotcentercenterNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: “Direct” standard is based upon the underlying standard: Simple Mail Transfer Protocol (SMTP) RFC 5321 and for security uses Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification, RFC 5751.For Direct, interoperability may be dependent on the establishment of “trust” between two parties and may vary based on the trust community(ies) to which parties belong. System Authentication - The information and process necessary to authenticate the systems involved Recipient Encryption - the message and health information are encrypted for the intended userSender Signature – details that are necessary to identity of the individual sending the messageInteroperability Need: An unsolicited “push” of clinical health information to a known destination between systemsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard SOAP-Based Secure Transport Requirements Traceability Matrix (RTM) version 1.0 specificationFinalProduction YesFreeYesImplementation Specification IHE-XDR (Cross-Enterprise Document Reliable Interchange)FinalProduction NoFreeNoImplementation Specification NwHIN Specification: Authorization FrameworkFinalProduction NoFreeNoImplementation Specification NwHIN Specification: Messaging PlatformFinalProduction NoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The IHE-XDR implementation specification is based upon the underlying standards: SOAP v2, and OASIS ebXML Registry Services 3.0The NwHIN Specification: Authorization Framework implementation specification is based upon the underlying standards: SAML v1.2, XSPAv1.0, and WS-1.1.System Authentication - The information and process necessary to authenticate the systems involved Purpose of Use - Identifies the purpose for the transactionPatient Consent Information - Identifies the patient consent information that may be required before data can be accessed.III-B: Clinical Decision Support ServicesInteroperability Need: Providing patient-specific assessments and recommendations based on patient data for clinical decision supportTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 Version 3 Standard: Decision Support Service, Release 2.DraftPilotNoFreeNoImplementation Specification HL7 Implementation Guide: Decision Support Service, Release 1.1, US Realm, Draft Standard for Trial Use DraftPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedInteroperability Need: Retrieval of contextually relevant, patient-specific knowledge resources from within clinical information systems to answer clinical questions raised by patients in the course of careTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard HL7 Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2.FinalProduction centercenterYesFreeNoImplementation Specification HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1.FinalProduction NoFreeNoImplementation Specification HL7 Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton), Release 4.FinalProduction NoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedIII-C: Image Exchange Interoperability Need: Exchanging imaging documents among a group of affiliated entitiesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityImplementation Specification IHE Cross Enterprise Document Sharing for Images (XDS-I)DraftPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedIII-D: Provider Directory Interoperability Need: Listing of providers for access by potential exchange partners TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityImplementation Specification IHE IT Infrastructure Technical Framework Supplement, Healthcare Provider Directory (HPD), Trial ImplementationDraftPilotcentercenterNoFreeYesLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedIII-E: Publish and Subscribe Interoperability Need: Publish and subscribe message exchange TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityImplementation Specification NwHIN Specification: Health Information Event Messaging Production SpecificationFinalProduction NoFreeNoEmerging Alternative Implementation Specification IHE Document Metadata Subscription (DSUB), Trial Implementation DraftPilot NoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedIII-F: Query Interoperability Need: Query for documents within a specific health information exchange domain TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityImplementation Specification IHE-XDS (Cross-enterprise document sharing)FinalProduction NoFreeNoImplementation Specification IHE-PDQ (Patient Demographic Query)FinalProduction NoFreeNoImplementation Specification IHE-PIX (Patient Identifier Cross-Reference)FinalProductionNoFreeNoEmerging Alternative Implementation Specification IHE – MHD (Mobile Access to Health Documents)DraftPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: IHE-PIX and IHE-PDQ are used for the purposes of patient matching and to support this interoperability need.Feedback requestedInteroperability Need: Query for documents outside a specific health information exchange domain TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityImplementation Specifications the combination of IHE-XCPD (Cross-Community Patient Discovery) and IHE-PIX (Patient Identifier Cross-Reference)FinalProduction NoFreeNoImplementation SpecificationNwHIN Specification: Patient DiscoveryFinalProduction NoFreeNoImplementation SpecificationsIHE-XCA (Cross-Community Access) further constrained by eHealth Exchange Query for Documents v 3.0FinalProduction NoFreeNoImplementation SpecificationNwHIN Specification: Query for DocumentsFinalProduction NoFreeNoImplementation SpecificationNwHIN Specification: Retrieve DocumentsFinalProduction NoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: IHE-PIX and IHE-XCPD are used for the purposes of patient matching and to support this interoperability need.System Authentication - The information and process necessary to authenticate the systems involved User Details - identifies the end user who is accessing the dataUser Role - identifies the role asserted by the individual initiating the transactionPurpose of Use - Identifies the purpose for the transactionPatient Consent Information - Identifies the patient consent information that may be required before data can be accessed.Query Request ID - Query requesting application assigns a unique identifier for each query request in order to match the response to the original query.Interoperability Need: Data element based query for clinical health information TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandard Fast Healthcare Interoperability Resources (FHIR)DraftPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedSystem Authentication - The information and process necessary to authenticate the systems involved User Details - identifies the end user who is accessing the dataUser Role - identifies the role asserted by the individual initiating the transactionPurpose of Use - Identifies the purpose for the transactionPatient Consent Information - Identifies the patient consent information that may be required before data can be accessed.Query Request ID - Query requesting application assigns a unique identifier for each query request in order to match the response to the original query.III-G: Resource Location Interoperability Need: Resource location within the US TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityImplementation Specification IHE IT Infrastructure Technical Framework Supplement, Care Services Discovery (CSD), Trial ImplementationDraftPilotcentercenterNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedSection IV: Questions and Requests for Stakeholder FeedbackSimilar to the 2015 Advisory, this draft gives stakeholders a body of work from which to react in order to prompt continued dialogue to improve the Advisory. As stated in the Introduction, this draft 2016 Advisory will continue to be refined during the public comment period. Additionally, because this draft includes both new structural and content sections please note that content for many of the new structural subsections is intentionally incomplete. Those sections that are more fully populated were done so to give the public an early opportunity to weigh in on and react to perceived value that these subsections could provide. Your feedback is critical to improve and refine these new subsections. Please visit to provide your comments and suggestions. GeneralIn the 2015 Advisory, each standard and implementation specification was listed under a “purpose.” Prior public comments and HIT Standards Committee recommendations suggested that the Advisory should convey a clearer link to the ways in which standards need to support business and functional requirements. This draft attempts to do so and lists standards and implementation specifications under more descriptive “interoperability needs.” Please provide feedback on whether revision from “purpose” to “interoperability need” provides the additional requested context and suggestions for how to continue to improve this portion.3M is impartial the use of the terms ‘purpose’ or ‘interoperability need.’ It is helpful that the interoperability need represents an ‘outcome’ that stakeholders would want to achieve. 3M suggests that there must be a clearly defined use case for each of the interoperability needs. Clear terminology harmonization across the regulatory initiatives to meet these initiates should be a top priority. For each standard and implementation specification there are six assessment characteristics. Please review the information provided in each of these tables and check for accuracy. Also, please help complete any missing or “unknown” information.3M believes that creating metrics for evaluating standards is necessary. In general, the characteristics outlined are valid and useful. 3M agrees with the need to identify limitations, dependencies, or preconditions associated with best available standards and implementation specifications. Further, 3M agrees with that most of the criteria presented as characteristics is valuable in assessing standards. However, there are unnecessary criteria, clear gaps and missing information in the assessment characteristics. The remainder of this document will focus on 3M’s review of the content w ithin However, Section I: Best Available Vocabulary/Code Set/Terminology Standards and Implementation Specifications. Some of the characteristics used to evaluate Section I are not applicable or appropriate. Security patterns is not applicable to Section I. Additionally, another characteristic that should be removed is #1: Standards Process Maturity. 3M believes that vocabulary standard maturity is an important evaluation criteria; however, it is not applicable to the vocabulary standards section because only mature vocabulary standards should be considered for inclusion in the ISA. Additionally, characteristic #6: Test Tool Availability should be removed from section one. Within the 2016 ISA, every interoperability need has ‘N/A’ for criteria #6.The gaps in the assessment criteria is of high importance to 3M. It is obvious that implementation specifications are absent from Section I. If ONC cannot suggest practical ways for organizations to implement the myriad standards listed, it will lead to implementation difficulties as well as inconsistent implementations. It is also unclear to 3M, how the ONC evaluated characteristic #2: Implementation Maturity. Considering that many of the standards lack a specific implementation guide for each interoperability need, implementation maturity is difficult to assess. The evaluation of implementation maturity using ‘pilot’ or ‘production’ is not helpful to stake holders. It would be most helpful to provide guidance in the implementation of large terminologies (i.e. SNOMED CT) and those with difficult nomenclature (i.e. Logical Identifier Names and Codes-LOINC) so that implementers with minimal terminology expertise are able to understand the intended use of the terminology for each interoperability need. Implementation specifications should include standard value sets and possibly map sets. In addition to the terminologies and value sets, the correct datatypes must be defined. The datatype should be provided for the entire Section I so that the implementers implement terminologies consistently. Some systems merely send a concept code without identifying the code system or the code system version, which hinders interoperability. For example, the standards may specify that coded concepts must follow the CD datatype as specified by the HL7 ISO 21090 Harmonized Datatypes Specification. The CD datatype requires a code system identifier, code system version identifier, and concept code to uniquely identify a coded concept. The CD datatype optionally specifies the value set from which the coded concept was selected. This will reveal inconsistencies in the specifications. For example, National Provider Identifier is recommended for identifying Care Team Members. The NPI is not a terminology, it identifies individuals, rather than types of individuals. Hence, the Care Team Member data element is of type Instance Identifier, which consists of an Identifier Scheme (a code that denotes “National Provider Identifier” as the scheme) and the identifier (the actual NPI of an individual). If SNOMED CT was used to identify a subjects role in the care setting, the datatype would be CD. Finally, it is important to designate the terminology identifier (Object Identifier-OID) for each standard terminology.Another gap in the 2016 ISA, are the methods used to evaluate characteristic #3: Adoption Level. There are many ways to measure adoption level (survey, literature review etc.). The adoption level should be linked with each interoperability need (rather than overall adoption of the terminology) and evaluation of the adoption should be explained. Additionally, one clear gap is methods used to evaluate each of these characteristics. Better explanation as to the methods of assessment rather than just the scoring criteria should be provided in the advisory. 3M believes that more attention should be given to the ‘implementation specification’. There are no implementation guides provided for the content standards only the name of the content standard.In general, the assessment criteria can be considered adequate. However, evidence for the reported findings in the ISA are inadequate. It is unclear how the ONC determined level of adoption (survey, literature review etc.). Additionally the percentage of adoption should be related to the specific interoperability need. Iif characteristic #4: Regulated is designated as ‘Yes’ a standamore information should be provided in the ISA.rd is regulated, There is limited utility of stating that the standard is regulated without providing a link to the regulatory guidance or program of interest. there should be a link to the program that the standard is regulated by. Stakeholders would be benefited by a cross-reference to the regulation.Finally, it would be beneficial to include information on licensing as well as the use of standard terminology within syntax standards (Section II). Many of the standard terminologies do have specific ‘terms of use’ licenses that stakeholder should evaluate. Additionally, standard terminology is not used ‘by itself’ to meet an interoperability need. Each interoperability need in Section I, should correspond to an interoperability need in Section II. For example, it should be explained how SNOMED CT in Section I-M is implemented within a Summary of Care (Section II-O). At a minimum, an association, between syntax standards and standard terminologies should be presented in the ISA.Additionally, the test tool criteria was rarely populated. In some instances, it was indicated that the standard did have a test tool (Test Tool Availability was ‘Yes’) but there was no reference or hyperlink to the tool. Licensing is missingFor each standard and implementation specifications, there is a table that lists security patterns. This draft only includes select examples for how this section would be populated in the future. Please review examples found in Sections III-A and III-F and provide feedback as to the usefulness of this approach and any information you know for a specific interoperability need.As mentioned in question 4-2, security patterns are not applicable to Section I.For each interoperability need, there is a table beneath the standards and implementation specifications that includes limitations, dependencies, and preconditions. This draft only includes select examples for how this section would be populated in the future. Please review populated sections and provide feedback as to the usefulness of this approach and any specific information you know for a specific interoperability need.Please see specific responses in the response to question 4-5.Section I: Vocabulary/Code SetBased on public feedback and HIT Standards Committee review, there does not appear to be a best available standard for several “interoperability needs” expressed in this section of the draft Advisory. Please provide feedback on whether this is correct or recommend a standard (and your accompanying rationale).Section I-A: Allergies3M believes that SNOMED CT has the best coverage for food, environmental or drug allergies and allergens.In a recent use case delivered to the IHTSDO, 3M provided examples of the variation in the representation of allergy data that exists within the electronic health record today. 3M’s experience with allergy data has mostly centered on establishing alerts for medical providers. Clinically, there are distinct differences in hypersensitivities, pseudo-allergies or intolerances and true allergic reactions. However, these term is loosely used by clinicians and laypeople to denote any such ‘reaction’. It has been 3M’s experience that these ‘reactions’ are defined in many different ways. The representation of allergy disorders, allergic reactions, allergen substance and severity are captured in an inconsistent manner. It would be helpful for stakeholders if a value set for ‘reactions’ was published in the ISA.3M has published and presented findings of challenges in normalizing clinical data from disparate systems one of the common themes is addressing the varying levels of granularity between code systems (standard and legacy alike). It is important to note that RxNorm does not include RxNorm native concepts for drug classes such as “Penicillins.” We agree that NDF-RT could be used to represent medication class, however, adoption level of NDF-RT is unknown to 3M. We recommend adding SNOMED CT as an alternate terminology, to represent medication class and a value set derived from the SNOMED CT substance domain as the implementation specification for Medication Allergens.Section I-B: Care Team MemberIt should be noted that the Care Team Member data element is of type Instance Identifier, which consists of an Identifier Scheme (a code that denotes “National Provider Identifier” as the scheme) and the identifier (the actual NPI of an individual).Section I-C: Encounter Diagnosis3M requests clarification on this interoperability need. ‘Documenting’ implies capturing the encounter diagnosis at the point of care. Most other interoperability needs are more clear in their verbiage such as ‘Representing…’. However, 3M agrees with the use of SNOMED CT and ICD-10-CM Diagnosis codes when sharing encounter diagnosis.Section I-D: Race and EthnicityThe 1997 Federal Register Notice on race and ethnicity by the Office of Management and Budget (OMB) classifies race into five categories (American Indian or Alaska Native, Asian, Black or African American, Native Hawaiian or other Pacific Islander, and White), and ethnicity into two categories (Hispanic or Latino, and Not Hispanic or Latino). 3M agrees that this classification may be adequate for statistical purposes within the scope of OMB, but these classifications are underspecified for use in healthcare. In fact, the Bureau of Census also uses more categories for race/ethnicity compared to the OMB classifications. Furthermore, the OMB classifications of race and ethnicity are not conformant with the HL7 ISO 21090 Harmonized Datatypes Specification and other standard terminology specifications. A terminology must be uniquely identified by a terminology or codesystem identifier such as an OID registered with a standards registry such as the HL7 OID Registry. The OMB classifications are not formally registered as codesystems, and the closest identifiers available for these are the value sets defined by the CDC PHIN VADS (Centers for Disease Control and Prevention’s Public Health Information Network Vocabulary Access and Distribution System), which are aligned with HL7 version 2 and version 3 tables, as well as specifications defined by the Federal Health Information Model (FHIM) project.Hence, race and ethnicity need to be clearly defined from four aspects – definitions, conformant terminology design, conformant value set design, and the individual concepts themselves. Race is defined as a biological category based on distinguishing genotypical and phenotypical characteristics of a group of individuals or an individual, which are inherited genetically from parents to children, and hence does not change over the life of an individual. Ethnicity is defined as a socio-cultural category of a group of individuals or an individual based on environmental attributes like physical location, culture, nationality, language, religion, food and so on, are influenced by the environment in which a person lives, and hence may change over time. Some concepts may appear to be both a race and ethnicity, e.g. Icelander. However, in such cases, one must clearly define Icelander race (a subtype of Norse/Northern Germanic race) and Icelander ethnicity (a subtype of Northern European or Scandinavian ethnicity) as two separate concepts, which often (but not always) apply to an individual together. Identifying the race and ethnicity of an individual at a finer level of granularity is necessary for assessing their genetic (e.g., increased risk of colon cancer in Ashkenazi Jewish population) and environmental (e.g., increased rick of stomach cancer in Japanese population) risks for certain diseases, respectively. It must also be noted that an individual may have multiple races or ethnicities, and clinical information systems must support multiple concepts for race or ethnicity.However, a detailed classification of ethnicity and race is an exhaustive process, especially when the races and ethnicities are from distant parts of the world and the terminology editors and medical practitioners in the United States may not be aware of the subtleties. On the other hand, SNOMED CT has a more comprehensive (though incomplete and sometimes inaccurate) classification of ethnicity compared to any administrative classification currently prevalent in the United States. However, SNOMED CT currently has a high level and non-exhaustive classification of race. Classification of race and ethnicity in SNOMED CT can be expected to grow in the future as more countries become members of IHTSDO, and are interested in classifying the races and ethnicities that are of interest to them. In addition, the hierarchical classification in SNOMED CT allows one to infer that the Icelander race is a subcategory (specialization) of the Caucasian race, and that Norwegian ethnicity is a subcategory of Scandinavian ethnicity. This provides the healthcare provider or the healthcare administrative staff the flexibility to record data at any level of granularity, which may then be rolled up using the SNOMED CT hierarchy from the “Clinical Documentation value set level of granularity” to the level of granularity desired for specific applications such as “US Bureau of Census value set granularity” or “OMB value set level of granularity”. Hence, the ideal approach for the definition of race and ethnicity for clinical usage in the United States will be defining US-realm-specific value sets for race and ethnicity that are derived from specific versions of SNOMED CT and are updated over time. The preceding definitions of terminology (e.g. SNOMED CT International Release or SNOMED CT US Edition) and value sets provide how such extensible definitions can be formally specified. SNOMED CT is formally defined as a terminology and is registered with the HL7 OID Registry, in contrast with the OMB classifications. In addition, any value set that is defined based on SNOMED CT for race (e.g. Race Value Set for US Healthcare Interoperability) and ethnicity (e.g. Ethnicity Value Set for US Healthcare Interoperability) need to be formally specified according to the upcoming HL7 Value Set Definition Specification, and be distributed through the National Library of Medicine’s Value Set Authority Center.Section I-E: Family Health History3M agrees with the consideration that SNOMED CT has limited content coverage for family health history. Due to this limited coverage, it should also be noted that SNOMED CT expressions must be utilized to post coordinate terms to reflect a complete family history for certain disease.Section I-F: Functional Status/DisabilityThere is a working group within the IHTSDO developing a function and abilities subset of SNOMED CT. Because of this important step towards a principle-based convergence of domain vocabularies using SNOMED CT, we feel that the United States should be involved in defining function and ability concepts within SNOMED CT.Section I-G: Gender, Sex and Sexual Orientation3M agrees that value sets should be recommended in the 2016 ISA. However, a value set is not a terminology, but an implementation specification based on one or more terminologies. This data element needs to be correctly defined using the underlying terminology and value set. Section I-H: ImmunizationsThe advisory specifies CVX (Immunizations – Historical) and NDC (Immunizations – administered) for different applications of the same data. Both of these can be covered by specifying RxNorm (Drugs) as the terminology, with application specific value sets as the implementation specification for both the immunization categories. We recommend using the RxNorm RXCUI codes rather than NDC codes, since RxNorm codes have concept permanence whereas NDC codes may change their meanings over time. RxNorm includes mapping to NDC codes, and the RxCUIs can be mapped to NDCs or mapped/rolled up to higher levels of granularity such as CVX or MVX as needed by the sender or the receiver of the information to support specific use cases.Hence, we recommend the use of RxNorm codes to identify the semantic branded drug (RxNorm semantic type SBD) or branded packaging (RxNorm semantic type BPCK) to capture the vaccine (medication) administered with the finest level of granularity. It must be noted that RxNorm supports additional semantic types at a higher level of granularity such as Semantic Clinical Drug (SCD) and Generic Pack (GPCK) when the specific brand name is not available or needs to be harmonized across brands. The Semantic Clinical Drug and Semantic Branded Drug are in turn linked to ingredients, which may be specific influenza strains in case of the US seasonal flu vaccine from a specific year, various pneumococcal strains (in case of a branded vaccine such as Prevnar 13), or the different inactivated viruses used in the Measles Mumps and Rubella (MMR) vaccine.Section I-I: Industry and OccupationThe Standard Occupation Codes (SOC) ADDIN EN.CITE <EndNote><Cite><Author>Statistics</Author><Year>2015</Year><RecNum>10</RecNum><DisplayText>(6)</DisplayText><record><rec-number>10</rec-number><foreign-keys><key app="EN" db-id="5w0adwsx8ev904e5xvoppx5j2wws02z959z5" timestamp="1425417201">10</key></foreign-keys><ref-type name="Web Page">12</ref-type><contributors><authors><author>U.S. Bureau of Labor Statistics </author></authors></contributors><titles><title>Standard Occupational Classification </title></titles><volume>2015</volume><number>02/27/15</number><dates><year>2015</year></dates><pub-location> States Department of Labor</publisher><urls></urls></record></Cite></EndNote>(1) are used by Federal statistical agencies to classify workers into occupational categories. It is our recommendation that ONC stay aligned with this standard list of codes. Even though we recommend this as the standard, we also suggest that the code set be evaluated and expanded for use within healthcare. Currently, CDA-2 uses the National Uniform Claim Committee Health Care Taxonomy (NUCC) codes, therefore, there needs to be an evaluation of the NUCC codes to determine the ones needed within SOC codes. Additionally, it is worthwhile to investigate the overlap and coverage of SNOMED CT occupation content when determining the appropriate approach to capturing industry and occupation data. Special attention to industries that have a known health risk should be identified and examines with scrutiny in order to assess the effect that job type has on health status.Section I-J: Lab testsLab tests should be broken out into two line items, lab orders and lab results, which should both have LOINC as the standard.When setting the context for laboratory orders against LOINC terms, stakeholders need to be aware of the difference between single lab test orders vs panel orders.? A potassium level, a single lab test with a single result will have the same LOINC term for its order and result answer. However, if a panel of electrolytes is desired, there is an Order LOINC term for electrolytes and four accompanying result LOINC terms for the sodium, potassium, chloride and carbon dioxide.It should be noted that in June 2015, the recommendations from the?a LOINC Order Code?group were forwarded as a final report to the Office of the National Coordinator (ONC). The recommendations included guidelines for organizations to follow when comparing their panels or batteries to LOINC Order terms with the goals of enhancing LOINC adoption in the US.3M’s experience with categorical answers within structured lab assays has good coverage with current SNOMED CT releases, is in regards to basic serologies, hematology, microbiology cultures and recording of basic specimen sources. 3M agrees that when lab test results are non-numerical/categorical (such as a susceptibility list) the recorded results should be encoded using SNOMED CT. However, it should be noted that laboratories create result fields to record information that belongs in other portions of an HL7 message.? This includes patient demographics (when a referral lab is capturing state reportable information).? No-numeric answers of such nature are not categorical or provided in SNOMED CT.Section I-K: Medications3M agrees in the assessment and use of RxNorm for medications. Section I-L: Numerical References & Values3M agrees in the assessment and use of UCUM for Numerical References and Values.Section I-M: Patient “problems” (i.e. conditions)3M agrees that SNOMED CT should be used for the representation of patient problems. Resources, such as the NLM problem list should be provided to ease implementation. Known challenges and the requirement of utilizing SNOMED CT expressions for the representations of problems (i.e. left leg fracture require the use of two SNOMED CT codes) should be noted as a precondition for consideration).Section I-N: Preferred LanguageIt should be noted that ISO 639-2 was regulated for Meaningful Use Stage 2. It would be helpful if an additional link to the Library of Congress where the ISO 639-2 codes can be viewed is provided to stakeholders. Section I-O: Procedures (medical and dental)The ONC should cautiously consider the use of proprietary terminologies such as CPT and CDT which require licensing and royalties. The use of terminologies which require licensing and fees impact the development and dissemination of health information technology applications and the sharing of data across entities. If the ONC supports the sharing of clinical data encoded with these terminologies, guidance should be provided on the content sharing processes as it applies to licensing and use of these terminologies. 3M suggests removing ‘planned’ qualifier from this interoperability need. Section I-P: Radiology (interventions and procedures)3M agrees that LOINC should be recognized as the standard to encode radiologic interventions and procedures. Several large organizations use LOINC to encode radiology, and it is considered a mature standard thus meets the criteria for inclusion.Implementation guides should be developed to assist organizations in implementing LOINC within messaging standards.Section I-Q: Smoking Status3M agrees that SNOMED CT contains basic information on capturing smoking status. Work on assessing terminology gaps and extending SNOMED CT content should be prioritized. 3M suggests that the value sets to assess smoking status be represented in the ISA.Section I-R: Unique Device IdentificationUDI is not a standard but rather an identification system. Per the FDA, the Unique Device Identification system will be phased in over several years, with the final compliance date of September 2020. This should be recognized as a limitation for consideration. Section I-S: Vital Signs3M requests information on this interoperability need. ‘Recording’ implies capturing vital sign observations at the point of care. Most of the other ‘interoperability needs’ are clear in their verbiage, ‘Representing….’. If ‘representing vital signs’ is not appropriate, an appropriate need would be ‘Sharing patient’s vital signs.’3M agrees that LOINC is a mature content standard for capturing vital sign observations. From 3M’s experience many systems record vital signs using proprietary codes and may translate the codes into LOINC for exchange of clinical observations. In the absence of a testing tool, it is unclear how implementation maturity and adoption level is measured for this interoperability need.It would be helpful to stakeholders to include a reference (ie a hyperlink) to the messaging standards that use LOINC to represent vital signs.Section II: Content / StructureShould more generalized survey instruments such as the IHE Profile Retrieve Form for Data Capture be considered? In addition to the two interoperability needs already listed, are there others that should be included related to imaging? If so, what would the best available standard and/or implementation specifications be? Should a more specific/precise aspect of DICOM be referenced for the implementation specification for this interoperability need?The HIT Standards Committee recommended to ONC that clearer implementation guidance is required. Are there additional implementation specifications that should be considered for this interoperability need?Section III: ServicesThe 2015 Advisory’s Section III, Transport has since been removed with content representation migrated as applicable within Section IV Services. What is your view of this approach?Appendix II: Sources of Security StandardsAre there other authoritative sources for Security Standards that should be included in Appendix II?Appendix I - Annual Process to Update the Interoperability Standards AdvisoryONC intends to implement the following timeline and process to update the Interoperability Standards Advisory for subsequent years. Note that timelines are approximate and may vary slightly for a variety of reasons. December Preceding the Upcoming Calendar Year The new Interoperability Standards Advisory for the next calendar year is published (e.g., December 2016 for the 2017 Advisory).A first round of an approximately 90- to 120-days of public comment period will be opened on that year’s Interoperability Standards Advisory.April/MaySometime during late April/early May the comment period will expire.ONC staff will compile all comments received during the first round comment period.ONC staff will present a summary of received comments to the HIT Standards Committee (or designated Task Force) in order to prepare them to make recommendations on updates for the following year’s Interoperability Standards Advisory.AugustThe HIT Standards Committee submits recommendations to the National Coordinator concerning updates to the following year’s Interoperability Standards Advisory.A second round of approximately 60-days of public comment will be opened on the HIT Standards Committee’s recommendations concerning the Interoperability Standards Advisory.October – DecemberSometime during October the comment period will expire.ONC will review the HIT Standards Committee recommendations as well as public comments on those recommendations.ONC will prepare the next year’s Interoperability Standards Advisory for publication.If a standard or implementation is under development and expected to be completed during this process, it could be considered for inclusion in the next year’s Interoperability Standards Advisory. For example, if an implementation guide is expected to be completed in October 2016 for a particular standard, this process should be able to anticipate and accommodate the potential addition of that implementation guide in the 2017 Interoperability Standards Advisory.Appendix II – Sources of Security Standards [See Question 4-11]In this draft Advisory, a structure to capture necessary security patterns associated with interoperability needs is represented (see Section III-A and III-F for examples, and related Question 4-3). To address public comments that requested a distinct security standards section the list below provides a number of sources to which stakeholders can look in order to find the latest applicable security standards. Note that this list is not meant to be exhaustive.ASTM: Information Organization for Standardization (ISO) Information Security Standards: National Institute for Standards and Technology (NIST) Special Publications 800 Series: NIST’s Federal Information Processing Standard (FIPS): Appendix III - Revision HistorySummary Level Description of ChangesISA AreaSummary Level Description of Revision HistoryRevision History, ExpandedAbbreviated IntroductionWith the 2015 Advisory, a great deal more 'explanatory' detail was offered to lend context and history and to spark necessary feedback. That level of information for the ISA 2016 within the Introduction was determined unnecessary. Any interest to access history and/or to gain context however, would be supported via link to 2015 Advisory.The ISA 2016 bypassed the need of an Executive Summary. The introduction sustained content deemed most relevantScope precedes PurposeThe two Purposes were mildly enhanced and one was added. The third addresses the biggest ISA 2016 change; namely, the added meta data to the table standards/implementation specification structureDocument RestructuringThe Public Comments and ISA Task Force received appreciable comments and direction from the Health IT Standards Committee (HITSC). In order to best serve the range of interests with this and subsequent ISA releases, the primary focus for the 2016 ISA was to address table restructuring -- particularly focused on finding the best way to add relevant characteristics of a standard/implementation specification thus offering added context. The breadth of changes to document structure has introduced noteworthy content which did extend the volume of the ISA, e.g., greater than 40 pages as compared to the 13 with the original ISA 2015.Instead of using the term “purpose,” a section’s lead-in is framed to convey an “interoperability need” stakeholders may express to convey an outcome they would want to achieve with interoperability. Meta Data describing six informative characteristics has been added to each referenced standard and implementation specification to give readers an overall sense of maturity and level of adoption: Standards Process Maturity; Implementation Maturity; Adoption Level; Regulated; Cost & Testing Tool AvailabilityInteroperability Need has two subsections.The first would identify any known limitations, dependencies, or preconditions associated with best available standards and implementation specifications.The second would identify, where applicable, known “security patterns” associated with best available standards and implementation specifications. This subsection’s goal would be to identify the generally reusable security techniques applicable to interoperability need(s) without prescribing or locking-in particular security standards.Transport Section (previously ISA 2015 Section III)), has been removed: 1) it was deemed to not provide additional clarity/value to stakeholders; and 2) the standards and implementation specifications in the “services” section included them as applicable.A security standards sources appendix is included to point stakeholders to the entities that maintain and curate relevant security standards informationRevised QuestionsThe questions offered, were structured to solicit feedback on changes made to the ISA 2016 and to assist in addressing recommendations where disposition is pending. These are found within Section IV Revision HistoryIn order to capture the changes the first ISA received, a Revision History has been introduced and is found in Appendix III. The Revision History, Appendix III, records summary & detailed levels changes and will record for the applicable ISA version, the additions, deletions and/or enhancements made as part of the annual review process.Given changes will continue during the Public Comment period and beyond, the Revision History will likewise be updated as changes occur and be cumulative in nature offering traceability. Additions/Enhancements Section / Interoperability NeedStandard AddedDescriptionOverarchingThe Interoperability Needs reflected have received edits to expand the context and support the consolidation of like interoperability needsI-A: AllergiesSNOMED-CT (Food Allergy)NDF-RT (Medication Allergen)Per HITSC recommendation, allergies were organized to add distinction between the reaction, the allergen causing the reaction and types of allergenHITSC recommendation were added via Limitations, Dependencies & Preconditions supporting medications and environmental substances allergensI-B: Care Team MemberHITSC views/recommendations added via Limitations, Dependencies & PreconditionsI-D: Race and EthnicityCDC Race and Ethnicity Code Set Version 1.0HITSC views/recommendation added via Limitations, Dependencies & PreconditionsI-E: Family Health HistoryHITSC views (around family genomic health history) added via Limitations, Dependencies & PreconditionsI-G: Gender Identity, Sex and Sexual Orientation Reference/link to Fenway Institute of Medicine report offeredFor Male and Female patient sex (at birth), HL7 Version 3 Value Set for Administrative GenderFor Unknown patient sex (at birth), HL7 Version 3 Null FlavorArea renamed & reorganized to address interoperability needs connected to Gender Identity, Sex & Sexual OrientationHITSC recommendation added via Limitations, Dependencies & PreconditionsI-H: Immunizations For administered: HL7 Standard Code Set CVX—Clinical Vaccines AdministeredHistorical & Administered: HITSC views / recommendations (surrounding use of CVX and MVX codes) added via Limitations, Dependencies & PreconditionsI-P: Radiology (interventions and proceduresLOINCReplaced RadLex; per HITSC recommendation added via Limitations, Dependencies & PreconditionsI-Q: Smoking StatusHITSC recommendation describing the limitations in what SNOMED-CT captures added via Limitations, Dependencies & PreconditionsII-A: Admission, Discharge, and TransferHITSC recommendation added via Limitations, Dependencies & Preconditions citing acceptability of any HL7 2.x version messaging standardHITSC recommendation added via Limitations, Dependencies & Preconditions surrounding available transport protocolsII-B: Care PlanHITSC recommendation added via Limitations, Dependencies & Preconditions citing availability of transport protocolsII-C: Clinical Decision SupportThe standards and specifications supporting what were 3 areas have been combined under interoperability need of “Shareable clinical decision supportII-D Drug Formulary & BenefitsHITSC recommendation added via Limitations, Dependencies & Preconditions related to monitoring NCPDP Real Time Prescription Benefit inquiry (RTPBI)II-E: Electronic Prescribing A prescriber’s ability to create a new prescription to electronically send to a pharmacyPrescription refill requestCancellation of a prescriptionPharmacy notifies prescriber of prescription fill statusA prescriber’s ability to obtain a patient’s medication historyArea reorganized to address five connected interoperability needs each with recommendations via Limitations, Dependencies and Preconditions to leverage their area’s particular transaction and of necessity to have prescriber and receiving pharmacy systems configured to facilitate the exchange II-F: Family Health HistoryHITSC recommendation added via Limitations, Dependencies & Preconditions related to lack of vocabulary for family genomic health history and a reference to transport of this dataII-G: ImagesImage Acquisition Technology Specific Service/Object Pairs (SOP) Classes HITSC recommendation added via Limitations, Dependencies & Preconditions related to need for feedback on new SOPII-H: LaboratoryReceive Lab test resultsHL7 2.5.1 as StandardHL7 Version 2.5.1 Implementation Guide: S&I Framework Lab Results Interface, Release 1—US Realm [HL7 Version 2.5.1: ORU_R01] Draft Standard for Trial Use, July 2012 from Standard to Implementation SpecificationHL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Results Interface Implementation Guide, Release 1 DSTU Release 2 - US Realm as Emerging Alternative Implementation SpecificationArea reorganized to address the three connected interoperability needs and also notes the HL7 Laboratory US Realm Value Set Companion Guide, Release 1, Sep 2015 as a resource for eachOrdering labs for a patientHL7 2.5.1 as StandardHL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR, Release 1 DSTU Release 2 - US Realm as Implementation SpecificationSupport the transmission of a laboratory’s directory of services to health ITHL7 2.5.1 as StandardHL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework, Release 2, DSTU Release 2 as StandardII-J: Patient Preference/ConsentIHE Basic Patient Privacy Consents (BPPC)IHE Cross Enterprise User Authorization (XUA)Per HITSC recommendations, two implementation specifications addedII-K: Public Health ReportingReporting antimicrobial use and resistance information to PH agenciesArea reorganized to consolidate seven applicable PH Reporting interoperability needsReporting cancer cases to PH agenciesHL7 CDA ? Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1, DSTU Release 1.1 – US Realm as Emerging Alternative Implementation SpecificationHITSC recommendation added via Limitations, Dependencies & Preconditions for stakeholders to refer to health departments in their jurisdiction for added information when transmitting informationCase reporting to PH agenciesFast Healthcare Interoperability Resources (FHIR) & Structured Data Capture Implementation Guide as StandardStructured Data Capture Implementation Guide as Implementation SpecificationElectronic transmission of reportable lab results to PH agenciesHL7 Version 2.5.1: Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1 with Errata and Clarifications and ELR 2.5.1 Clarification Document for EHR Technology Certification as Implementation SpecificationSending health care survey information to PH agenciesHL7 Implementation Guide for CDA? R2: National Health Care Surveys (NHCS), Release 1 - US Realm inserted as replacementReporting administered immunizations to immunization registryHL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.4 added as an implementation specificationHL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5 reflected an emerging alternative as Emerging Alternative ISReporting syndromic surveillance to PH (ED, inpatient, and urgent settings) PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent CareData Release 1.1 as Implementation SpecificationII-L: Quality ReportingHL7 Implementation Guide for CDA? Release 2: Quality Reporting Document Architecture – Category I, DSTU Release 3 (US Realm)II-O: Summary care recordSupport a transition of care or referral to another providerHL7 Implementation Guide for CDA? Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1 as emerging alternative Implementation SpecificationHITSC recommendation added via Limitations, Dependencies & Preconditions regarding specific document templates within the C-CDA Implementation Specification and need for trading partners to have systems supporting the document templatesIII-A: An unsolicited ‘push’ of clinical health information to a known destinationbetween providers between systemsFast Healthcare Interoperability Resources (FHIR) as an emerging alternative standardHITSC recommendation added via Limitations, Dependencies & Preconditions regarding Direct standard and its basis standard (SMTP) and for security uses; Direct dependencies also relayed. Approximate nine Applicable Security Patterns were also listed for both interoperability needsThe alignment of standards / implementations specifications received minor updatesIII-E: Resource LocationIHE IT Infrastructure Technical Framework Supplement, Care Services Discovery (CSD), Trial Implementation reflected from standard to an Implementation SpecificationIII-F: Provider DirectoryIHE IT Infrastructure Technical Framework Supplement, Healthcare Provider Directory (HPD), Trial Implementation reflected from standard to an Implementation SpecificationIII-G: Publish and SubscribeNwHIN Specification: Health Information Event Messaging Production Specification reflected from standard to an Implementation SpecificationIHE Document Metadata Subscription (DSUB), Trial Implementation as an Emerging Alternative Implementation SpecificationDeletions / Refinements Section / Interoperability NeedStandard RemovedDescriptionI-N: Preferred LanguageRefined from 4 to 1: RFC 5646 HITSC recommendation added via Limitations, Dependencies & Preconditions citing the fact RFC 5646 contains the others originally listedI-P: Radiology (interventions and proceduresRadLexReplaced by LOINCII-K Public Health ReportingSending health care survey information to PH agenciesHL7 Implementation Guide for CDA? Release 2: National Ambulatory Medical Care Survey (NAMCS), Release 1, US Realm, Volume 1- Introductory Material, Draft Standard for Trial Use replacedStatistics USBoL. Standard Occupational Classification HYPERLINK ":" : United States Department of Labor; 2015 [cited 2015 02/27/15]. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download