Draft 2017 Interoperability Standards Advisory



5662839center09600020001549402000200660Draft 2017 Interoperability Standards AdvisoryOffice of the National Coordinator for Health IT 096000Draft 2017 Interoperability Standards AdvisoryOffice of the National Coordinator for Health IT -432719715500-2590807606665Public Comment Version 00Public Comment Version 5662839center096000Table of Contents TOC \o "1-3" \h \z \u Introduction to the Draft 2017 Interoperability Standards Advisory PAGEREF _Toc459101057 \h 1Scope PAGEREF _Toc459101058 \h 1Purpose PAGEREF _Toc459101059 \h 2ISA Structure PAGEREF _Toc459101060 \h 2Section I: Vocabulary/Code Set/Terminology Standards and Implementation Specifications PAGEREF _Toc459101061 \h 6I-A: Allergies PAGEREF _Toc459101062 \h 6I-B: Encounter Diagnosis PAGEREF _Toc459101063 \h 8I-C: Family Health History PAGEREF _Toc459101064 \h 8I-D: Functional Status/Disability PAGEREF _Toc459101065 \h 9I-E: Health Care Provider PAGEREF _Toc459101066 \h 10I-F: Imaging (Diagnostics, interventions and procedures) PAGEREF _Toc459101067 \h 11I-G: Immunizations PAGEREF _Toc459101068 \h 11I-H: Industry and Occupation PAGEREF _Toc459101069 \h 12I-I: Lab tests PAGEREF _Toc459101070 \h 12I-J: Medications PAGEREF _Toc459101071 \h 13I-K: Numerical References & Values PAGEREF _Toc459101072 \h 14I-L: Nursing PAGEREF _Toc459101073 \h 15I-M: Patient Clinical “Problems” (i.e., conditions) PAGEREF _Toc459101074 \h 17I-N: Preferred Language PAGEREF _Toc459101075 \h 17I-O: Procedures PAGEREF _Toc459101076 \h 18I-P: Race and Ethnicity PAGEREF _Toc459101077 \h 18I-Q: Research PAGEREF _Toc459101078 \h 19I-R: Sexual Orientation and Gender Identity PAGEREF _Toc459101079 \h 20I-S: Social Determinants [See Questions 10 and 11, Section IV] PAGEREF _Toc459101080 \h 21I-T: Tobacco Use (Smoking Status) [See Question 12, Section IV] PAGEREF _Toc459101081 \h 24I-U: Unique Device Identification PAGEREF _Toc459101082 \h 25I-V: Vital Signs PAGEREF _Toc459101083 \h 25Section II: Content/Structure Standards and Implementation Specifications PAGEREF _Toc459101084 \h 26II-A: Admission, Discharge, and Transfer PAGEREF _Toc459101085 \h 26II-B: Care Plan PAGEREF _Toc459101086 \h 27II-C: Clinical Decision Support PAGEREF _Toc459101087 \h 28II- D: Clinical Quality Measurement PAGEREF _Toc459101088 \h 29II-E: Clinical Quality Reporting PAGEREF _Toc459101089 \h 30II-F: Data Provenance PAGEREF _Toc459101090 \h 31II-G: Drug Formulary & Benefits PAGEREF _Toc459101091 \h 31II-H: Electronic Prescribing PAGEREF _Toc459101092 \h 32II-I: Family health history (clinical genomics) PAGEREF _Toc459101093 \h 35II-J: Images PAGEREF _Toc459101094 \h 36II-K: Laboratory PAGEREF _Toc459101095 \h 37II-L: Medical Device Communication to Other Information Systems/Technologies PAGEREF _Toc459101096 \h 40II-M: Patient Education Materials PAGEREF _Toc459101097 \h 40II-N: Patient Preference/Consent PAGEREF _Toc459101098 \h 40II-O: Public Health Reporting PAGEREF _Toc459101099 \h 41II-P: Representing clinical health information as a “resource” PAGEREF _Toc459101100 \h 46II-Q: Research PAGEREF _Toc459101101 \h 47II-R: Segmentation of sensitive information PAGEREF _Toc459101102 \h 51II-S: Summary care record PAGEREF _Toc459101103 \h 52Section III: Standards and Implementation Specifications for Services PAGEREF _Toc459101104 \h 52III-A: “Push” Exchange PAGEREF _Toc459101105 \h 52III-B: Clinical Decision Support Services PAGEREF _Toc459101106 \h 55III-C: Image Exchange PAGEREF _Toc459101107 \h 56III-D: Healthcare Directory, Provider Directory PAGEREF _Toc459101108 \h 58III-E: Public Health Exchange PAGEREF _Toc459101109 \h 58III-F: Publish and Subscribe PAGEREF _Toc459101110 \h 59III-G: Query PAGEREF _Toc459101111 \h 59III-H: Resource Location PAGEREF _Toc459101112 \h 62Section IV: Questions and Requests for Stakeholder Feedback PAGEREF _Toc459101113 \h 64Appendix I – Sources of Security Standards and Security Patterns PAGEREF _Toc459101114 \h 66Appendix II - Revision History PAGEREF _Toc459101115 \h 68Appendix III – Responses to Comments Requiring Additional Consideration PAGEREF _Toc459101116 \h 72Legend for our comments:Yellow highlight with orange text indicates that text substantially changed, or added compared to 2016 ment boxes where we put our issues and recommendations.Red text with/without strikethrough are specific proposed changes for submission. The Draft 2017 Interoperability Standards Advisory represents the Office of the National Coordinator for Health Information Technology’s current assessment of the heath IT standards landscape. It 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. General HL7 Comments/suggestions:Comments included:Appreciate the introduction of “In Development” addressing our suggestion to improve focus on emerging standards and better stratify Standards Process Maturity.Appreciate the introduction of a link to the Interoperability Proving Ground addressing our suggestion in that regard.Appreciate continued expansion of implementation guide ments not clearly addressed:Vocabulary harmonization. Should reiterate that point.Change references from DSTU to STU. I guess they want to use what is on the actual published document. Suggest we do not repeat this comment. Drop the general comment and just comment case-by-case.Moving final/mature/widely adopted standards into a separate section to focus on emerging standards. Drop the general comment, and just case-by-case. By use case can provider better context.Clarity on guidance on responsibilities of the receiving party, e.g., Lab EHR-S guide. Re-emphasize in the specific places, not in general.Inclusion of CDISC standards.Clarify scope whether EHR or wider HIT. Not clear where it is. Depending on that, Research can be included or not.Recognition of adoption levels based on setting, e.g., inpatient vs. ambulatory, mobile, etc.Note samples of generally adopted, but not for this use case.Include short paragraph summarizing the use case.New:Should not reference just FHIR without an implementation guide / profile, lest we want to go back to the varied V2 and V3 days.Be specific as well. Look for trading partner negotiation.Ask for feedback on comments to understand disposition.Introduction to the Draft 2017 Interoperability Standards AdvisoryThe 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 public awareness of interoperability standards and implementation specifications that can be used by industry to fulfill specific clinical health IT interoperability needs. The Draft 2017 Interoperability Standards Advisory remains focused on clinical health information technology (IT) interoperability and its updates and improvements are due largely to recommendations received from public comments and the Health IT Standards Committee. For historical background on the ISA please review prior Interoperability Standards Advisory publications.At a high-level, the most substantial changes between the 2016 and the Draft 2017 ISA are largely related to the ISA’s content and framing. This includes the following: The beginning transition of the ISA from a stand-alone document to a Web-based resource with greater interactive potential.The discontinued use of the label “best available” as an overall concept for the ISA. This change, at the recommendation of the Health IT Standards Committee, seeks to address feedback that stakeholders may perceive varied standards and implementation specifications associated with an interoperability need as “best” despite known limitations or low adoption levels. Further, that the ISA serves as a way to “identify” standards and implementation specifications and should be as inclusive as possible in order to increase public awareness about a standard or implementation specification’s applicability to an interoperability need. Thus, a determination as to whether one standard listed in the ISA may be more “fit for purpose” than another (for the same interoperability need) could be reflected by referenced industry experience and the ISA’s associated informative characteristics. Where applicable, the addition of “Applicable Starter Set(s)” alongside appropriate code sets in Section I.Links to active projects listed in ONC’s Interoperability Proving Ground as a way to indicate their use of an ISA-listed standard or implementation specification to showcase ongoing implementations.Better representation of the pairing of standards for observations (i.e., questions) and standards for observation values (i.e., answers). The Draft 2017 ISA includes revisions and additional descriptive text for several of the six informative characteristics. Per the process first established with the publication of the 2015 ISA, this document represents the Draft ISA for 2017. The comment period on this version will open in August upon publication and run to mid-October, 2016. Based on public comments, the Draft 2017 ISA will be revised and the Final 2017 ISA will be published in December 2016. Your continued feedback and engagement is critical to improve and refine the ISA. HL7 Comments/suggestions:ScopeThe standards and implementation specifications listed in this Draft 2017 ISA focus explicitly on clinical health IT systems’ interoperability. Thus, the ISA’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 Draft 2017 ISA 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).The ISA is not exhaustive but it is expected that future ISAs will continue to incrementally include a broader range of clinical health IT interoperability needs. When more than one standard or implementation specification is listed 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. It may also reflect the fact that there is an ongoing transition from the use of one standard towards a new version or even next-generation approach.As noted in prior ISAs, a standard listed in one section is not intended to imply that it 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 need.HL7 Comments/suggestions:PurposeThe Interoperability Standards Advisory 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 used to fulfill specific clinical health information interoperability need.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 ISA is designed to provide clarity, consistency, and predictability for the public regarding the standards and implementation specifications that could be used for a given clinical health IT interoperability purpose. Stakeholders who administer government programs, procurements, and testing or certification programs with clinical health IT interoperability components are encouraged to look first to the ISA in order to more fully inform their goals. In that regard, standards and implementation specifications in the ISA and their associated informative characteristics are also available to help more fully inform policymaking. In this case, a standard or implementation specification’s reference in the ISA may serve as the initial basis for industry or government consideration and action. While the ISA itself is a non-binding document, standards and implementation specifications listed in the ISA may be considered for rulemaking or other Federal requirements. However, those decisions would be made on a case-by-case basis by the administering organization. HL7 Comments/suggestions:Concern that ISA is not in sync with Cert Edition and that we can get agencies out-of-sync. Is the intent that ISA replaces Certification Edition? Unclear what expectations would be. Check out data blocking in MACRA language. What is relationship with Cert Edition.Need specific guidance if ISA is to be the source on when it would be required (thresholds, timelines, etc.)Qualitative and Quantitative guidance required. General expectation cannot be universal adoption.ISA provides basis for general direction, but cannot support more in current state.ISA StructureThe ISA is organized and structured into four sections. Section I – Vocabulary/Code Sets/Terminology Standards and Implementation Specifications (i.e., “semantics”).Section II – Content/Structure Standards and Implementation Specifications (i.e., “syntax”).Section III – Standards and Implementation Specifications for Services (i.e., the infrastructure components deployed and used to fulfill specific interoperability needs)Section IV – Questions and Requests for Stakeholder Feedback Within each section specific “interoperability need” subheadings are listed and followed by the table illustrated below. Each interoperability need may have one or more standards and/or implementation specifications associated with it. Each standard and implementation specification has six informative characteristics (first introduced in the Draft 2016 ISA) attributed to it in order to provide added context. When known, an “emerging” standard or implementation specification is also listed and is shaded in a lighter color and italicized for additional emphasis. In addition, for vocabulary standards, where there may be one standard used to represent the “observation” or question being asked, and one standard used for the “observation value” or answer these are listed in distinct rows.The Draft 2017 ISA also includes links within the limitations, dependencies and preconditions to ONC’s Interoperability Proving Ground (IPG) to showcase real-world implementations of standards listed within the ISA. Please note: when accessing links to the IPG, all projects for the selected standard will be listed, including those that may be demonstrating use of the standard for different interoperability needs. In addition, IPG entries are self-reported by stakeholders, so the quality and accuracy of the data may vary across entries. Interoperability need: [Descriptive Text]Standard/Implementation SpecificationStandards ProcessMaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardFinalProductionNoFreeNoStandard for observationsFinalProductionYesFreeYesStandard for observation valuesFinalProductionNoFree YesEmerging StandardBalloted DraftPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration:Section I: Applicable Value Set(s) and Starter Set(s):Sections II & III: Applicable Security Patterns for Consideration:Where standards listed for an interoperability need have active projects listed on ONC’s Interoperability Proving Ground, a link to that standard will be provided in this section. Please note, all projects for the standard will be listed, including those that may be demonstrating use of the standard for different interoperability needs.Descriptive textThe following describes the ISA’s six informative characteristics in greater detail. This detail is meant to better inform stakeholders about the maturity and adoptability of a given standard or implementation specification and provides definition for the terms and symbols used throughout the ISA. These definitions remain similar in nature to those presented in the 2016 ISA, but have been modified slightly to provide additional clarity as requested by public comments. Stakeholders should consider all six characteristics together to gain insight into the level of maturity and adoptability of the standards and implementation specifications provided within the ISA. #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. “Balloted Draft” – when this designation is assigned, the standard or implementation specification is considered to be a Draft Standard for Trial Use (DSTU), Standard for Trial Use (STU), or in a “trial implementation” status by the organization that maintains it and has been voted on or approved by its membership as such. This designation does not include standards and implementation guides that are unofficial drafts and early “works in progress”. “In Development” – when this designation is assigned, the standard or implementation specification is currently in development. It also includes those that are in the midst of being balloted. This designation is generally reserved for “emerging standards.”#2: Implementation Maturity This characteristic conveys a standard or implementation specification’s maturity based upon its implementation state. Where available, a link to published maturity assessments based on known published criteria about the standards is also provided. [See Question 3, Section IV]“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 on a 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, average adoption level in health care within the United States. Presently, it is based on ONC’s analysis of several factors, including, but not limited to: 1) whether and/or how long a standard or implementation specification has been included in regulation for health IT certification (if applicable) or another HHS regulatory or program requirement; 2) feedback from subject matter experts and 3) public comments. The adoption level also considers the variety of stakeholders and stakeholder groups that would use the standard and implementation specification to address the specified interoperability need and attempts to display it as such, with the understanding that the designation is a generality and not a pre-defined measured value. Where available, annotated references or links to publicly available documentation known about adoption levels for listed standards is also provided. [See Question 4, Section IV]The following scale is used to indicate the approximate, average adoption level among the stakeholders that would use a standard or implementation specification to meet the specified interoperability need:“Feedback requested” Indicates that we do not have a known status for the current level of adoption in health care. Indicates low adoption. Indicates low-medium adoption.Indicates medium adoption. Indicates medium-high adoption. Indicates high or widespread adoption. #4: Federally RequiredThis characteristic (provided as a “Yes” or “No”) conveys whether a standard or implementation specification has been adopted in regulation, referenced as a federal program requirement, or referenced in a federal procurement (i.e., contract or grant) for a particular interoperability need. Where available, a link to the regulation has been provided. #5: CostThis characteristic conveys whether a fee is involved to purchase, license or obtain membership for access or use of the recommended standard or implementation specification.“$” – 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. Where known, the estimated cost for access will be provided.“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. Where available, a link will be provided to the publicly available test tool. [See Question 5, Section IV]“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.“Yes – Open” – When this designation is assigned, it signifies that a test tool is available for a standard or implementation specification and is available as open source with rights to modify. 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.”HL7 Comments/suggestions:“In Development” – On the one hand, could use to promote work in progress. On the other hand, concerned that if it is not yet in ballot, not enough visibility to promote this widely. Need to be inclusive and not pick winners too early, e.g., list both DAF efforts in HL7 and IHE, not just one or the other. UNTIL adoption levels and experience clearly favor one or the other.(Copied from 2016 ISA Response) We note that Adoption Level and Implementation Maturity may vary based on the environment/setting in which the standard is deployed. As they are presented, the current ratings assume the traditional in-house “EHR” space. As new interoperability needs and standards are identified for mobile/consumer use cases, additional ratings should be given to cater for newer classes of Adoption and Maturity in mobile and consumer settings. For example, HL7 v2 and CDA are widely adopted and mature in EHRs, but to a lesser extent in mobile health. Certain standards may be too heavyweight for mobile adoption, especially in situations where bandwidth is limited, thus never get widely adopted in that environment. Additionally, we suggest the application of these adoption status codes needs to be clarified. Are they intended to indicate the extent to which software developers have adopted a standard or implementation specification by having corresponding capability available? Or do they indicate whether such capability is actually deployed for use by providers, HIEs, etc. or the extent to which the breadth of requirements in a standard or implementation specification are covered or a combination of these factors? Some assertions may need to be adjusted accordingly(Copied from 2016 ISA Response) Regarding testing, it is important that proposed standards must be tested sufficiently prior to inclusion in rule making. The Standards Advisory is a helpful tool to create a sketch of what direction the industry is heading in this area. It is important in that context to enable providers and vendors to test new versions of standards, so there is a high confidence that adoption has value and is feasible across the industry as a whole. HL7 is ready to work with ONC and other parties to address testing and pilot programs of its standards to address this critical issue and to provide a feedback loop to further improve on its standards and implementation guides before wide endorsement through regulation.(Copied from 2016 ISA response) Organizing the standards and implementation specifications based on Use Case and Interoperability Needs must provide more helpful context to assess fit-for-purpose and maturity. As indicated earlier, certain standards may be applicable in one setting, but not another, or more mature for one use case rather than another. However, in a number of situations, e.g., Care Plan, it is unclear what the intended use case is that the interoperability need applies to, and what the difference is between a use case and interoperability need. We request ONC to clearly define the difference between the two, and provide for at least each use case header a short description of what the scope of the use case that is being considered for the suggest standard or implementation specification. We also understand that the intent of the Advisory is to identify gaps in available standards or implementation specifications for specific use cases, e.g., closed loop referral. Where ONC has identified those gaps we request that ONC lists them in a separate section to highlight where further focus is required, or to recognize projects in progress to fill that gap. Various standards were proposed for the 2015 Edition but did not get included in the final rule, and they did not make it in the Advisory either, e.g., esMD. HL7 believes that the Advisory should over time become a predictor of what will be endorsed for national adoption. Therefore, we suggest that the Advisory considers the various standards that did not make it into the 2015 Edition, or clarify that they are no longer being considered. It is critical that systems have required functionality to support interoperability. The HL7 EHR System Functional Model is the most detailed and comprehensive Normative Standard addressing the creation (Origination) of electronic health information (EHI) as well as its maintenance for primary and secondary uses. The EHR Workgroup welcomes this increasing visibility for EHI Origination in the Functional Model and invites increasing collaboration on implementation guides and tools. We especially invite interest in advancing EHR reliability for accurate and authentic patient care information at origination and throughout its lifecycle, with integrity assured. Recognizing that the value of interoperability depends heavily on the quality of the source extends benefits to all stakeholders and end-uses, locally and through exchange, in direct care, public health reporting, and public policy support. To these ends, HL7 has developed and approved (by formal consensus) a suite of Functional Models (FMs) and Functional Profiles for Electronic Health Record (EHR) and Personal Health Record (PHR) systems. The FMs have been further recognized internationally as they have been approved by consensus of ISO National Member Bodies. The two Functional Models are now published as International Standards by both organizations: 1) ISO/HL7 10781 EHR System Functional Model, Release 2, aka EHR-S FM (published by HL7 2014, ISO 2015) (see: ) 2) ISO/HL7 16527 PHR System Functional Model, Release 2, aka PHR-S FM (published by HL7 2014, ISO 2015) (see: ) To enable interoperability as part of US Meaningful Use, we have developed and approved via consensus: 3) HL7 Meaningful Use Functional Profile for Stages 1&2 (published 2015), based on ISO/HL7 10781 EHR-S FM (see: ) To enable interoperability for public/population health, we have developed (in collaboration with the US Centers for Disease Control and Prevention (CDC)) and approved via consensus: 4) HL7 Public Health Functional Profiles (published 2015), suite of nine (9) FPs for specific public health services/domain areas, based on ISO/HL7 10781 EHR-S FM (see: ) To enable interoperability of EHR/PHR record content when implementing HL7 Fast Health Interoperable Resources (FHIR), we have developed and approved via consensus: 5) HL7 Record Lifecycle Event Implementation Guide, part of FHIR DSTU-2 (published September 2015), based on ISO/HL7 10781 EHR-S FM, Record Infrastructure Chapter, Record Entry Lifespan and Lifecycle (see: ) Each of the Functional Profiles and the Functional Model support all EHR systems meeting a common set of conformance criteria that promote standardized collection, storage, and communication of structured and non-structured data. These profiles and the FM support enhanced interoperability. HL7 strongly supports the inclusion of these Functional Models/Profiles and the FHIR Implementation Guide (items 1-5 above). 10 HL7 suggests the inclusion of these Functional Models/Profiles and the FHIR Implementation Guide in a new category in the Advisory.Request EHR Workgroup to provide rationale why to include again. Need to make the case better why this is needed in addition to “pure” interoperability guidance. Provide the key points how it improves on such guidance. Perhaps start with EHR-S FM Lab Results IG. Section I: Vocabulary/Code Set/Terminology Standards and Implementation SpecificationsHL7 Comments/Suggestions:(copied from 2016 ISA) While many vocabulary standards may be applicable across all contexts, some may need adjustment when used in the consumer/mobile context. Consumer friendly vocabularies may be needed, with standardized mappings to/from clinical vocabularies like SNOMED-CT, LOINC, RxNorm. HL7 suggests adding these as they become available, to each Interoperability Need in the Vocabulary Section of the ISA.I-A: Allergies Interoperability Need: Representing Patient Allergic ReactionsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally Required CostTest Tool AvailabilityStandard for observationsLOINC?FinalProduction628651333500NoFreeN/AStandard for observation valuesSNOMED CT?FinalProduction47625-7747000NoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s):SNOMED CT? may not be sufficient to differentiate between an allergy or adverse reaction, or the level of severity For use of SNOMED CT?, codes should generally be chosen from the Clinical finding axis See LOINC projects in the Interoperability Proving Ground.SNOMED CT Value Set Problem urn:oid:2.16.840.1.113883.3.88.12.3221.7.4There is an ‘Adverse Clinical Reaction’ set in Value Set Authority Center (VSAC) created by Federal Health Interoperability Modeling and Standards (FHIMS) which can be considered a candidate as a starter set.HL7 Comments/suggestions:Interoperability Need: Representing Patient Allergens: MedicationsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardRxNormFinalProductionYesFreeN/AStandardNDF-RTFinalProduction Feedback requestedNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s):When a medication allergy necessitates capture by medication class, NDF-RT should be used. Grouping Value Set: Substance-Reactant for Intolerance urn:oid:2.16.840.1.113762.1.4.1010.1. The codes from the following value set should be selected in the following order of preference: NDF-RT -> RxNorm -> UNII -> SNOMED CT?Medication Drug Class (2.16.840.1.113883.3.88.12.80.18) (NDFRT drug class codes)Clinical Drug Ingredient (2.16.840.1.113762.1.4.1010.7) (RxNORM ingredient codesHL7 Comments/suggestions:(copied from 2016 ISA) RxNorm: We suggest clarifying whether RxNorm refers to RxNorm as the source or whether other sources are included with the RxNorm download.(copied from 2016 ISA) NDF-RT: We believe that the Adoption Level for NDF-RT should at least be one bullet, if not higher. We understand the Veterans Administration (VA) uses NDF-RT, which ONC may want to contact for validation.Interoperability Need: Representing Patient Allergens: Food Substances TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardUNII (Unique Ingredient Identifier)FinalFeedback requestedFeedback requestedNoFreeN/AStandard SNOMED CT?FinalFeedback requestedFeedback requestedNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s):Feedback requestedGrouping Value set: Substance-Reactant for Intolerance urn:oid:2.16.840.1.113762.1.4.1010.1.Substance Other Than Clinical Drug (2.16.840.1.113762.1.4.1010.9) (SNOMED CT? substance codes)Unique Ingredient Identifier - Complete Set (2.16.840.1.113883.3.88.12.80.20) (UNII ingredient codes)HL7 Comments/suggestions:Interoperability Need: Representing Patient Allergens: Environmental Substances TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardUNIIFinalFeedback requestedFeedback requestedNoFreeN/AStandard SNOMED CT?FinalProduction 762005969000NoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): Feedback requested Grouping Value set: Substance-Reactant for Intolerance urn:oid:2.16.840.1.113762.1.4.1010.1.Substance Other Than Clinical Drug (2.16.840.1.113762.1.4.1010.9) (SNOMED CT? substance codes).Unique Ingredient Identifier - Complete Set (2.16.840.1.113883.3.88.12.80.20) (UNII ingredient codes)HL7 Comments/suggestions:I-B: Encounter Diagnosis Interoperability Need: Representing Patient Medical Encounter Diagnosis TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard SNOMED CT?FinalProductionYesFreeN/AStandard ICD-10-CMFinalProduction YesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): Use of SNOMED CT? codes should generally be chosen from three axes: Clinical finding, Situation with explicit context, and Event.Systems should be able to handle older code sets, such as ICD-9, as legacy content still exists and may be used for analysis/decision support/quality measurement needs as retroactive analysis is often required.A mapping from SNOMED CT? to ICD-10-CM is available from the National Library of Medicine.Problem urn:oid:2.16.840.1.113883.3.88.12.3221.7.4 (SNOMED CT? code system)Recommended starter set: CORE Problem List Subset urn:oid: 2.16.840.1.113762.1.4.1018.240HL7 Comments/suggestions:Interoperability Need: Representing Patient Dental Encounter Diagnosis TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard SNODENTFinalProduction723902222500NoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Code System:Feedback requestedOID 2.16.840.1.113883.3.3150HL7 Comments/suggestions:I-C: Family Health HistoryInteroperability Need: Representing Patient Family Health History TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard for observationsLOINC?FinalProduction74295-635000NoFreeN/AStandard for observation valuesSNOMED CT?FinalProduction79375-4635500YesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): Some details around family genomic health history may not be captured by SNOMED CT? See LOINC projects in the Interoperability Proving Ground.For Diagnosis and Conditions:Problem Type 2.16.840.1.113883.3.88.12.3221.7.2 (LOINC? code system)Problem urn:oid:2.16.840.1.113883.3.88.12.3221.7.4 (SNOMED CT? code system)For genomic data:Gene Identifier: HGNC Value SetTranscript Reference Sequence Identifier: NCBI vocabularyDNA Sequence Variation Identifier: NCBI vocabularyDNA Sequence Variation: HGVS nomenclatureHL7 Comments/suggestions:Interoperability Need: Representing Patient Family Health History Observations TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard HYPERLINK "" LOINC?FinalProduction723901841500FreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s):Applicable Value Set(s) and Starter Set(s): Feedback requestedSee LOINC projects in the Interoperability Proving Ground.Problem Type 2.16.840.1.113883.3.88.12.3221.7.2?(LOINC? code system)HL7 Comments/suggestions:This topic was projected in 2016 ISA. Highlighted compares to what was projected.I-D: Functional Status/Disability Interoperability Need: Representing Patient Functional Status and/or Disability TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard[See Question 7, Section IV]Limitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s):Public comments were varied for this interoperability need. We heard the strongest support for SNOMED CT? and ICF standards, but at this time do not have enough information to warrant inclusion of either standard for this interoperability need. LOINC? and SNOMED CT? are the preferred vocabularies for this area. Feedback requestedHL7 Comments/suggestions:(Copied from 2016 ISA) We recommend considering PROMIS, acknowledging it is not an official standard and comes with the associated risk. Standards not maintained by an SDO or similar organization increases risks for implementers. While appropriate experts have developed many standards with the best of intentions, failure to move such standards into formal SDO organizations and processes leaves the standards without a clear plan for ongoing maintenance, update, and support. However, we still suggest including this standard where ONC can clearly identify that it is not under active maintenance by a formal SDO, and should clearly state the risks to implementers.I-E: Health Care Provider Interoperability Need: Representing Care Team Member (Health Care Provider)TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardNational Provider Identifier (NPI)FinalProductionNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s):For the purpose of recording a care team member, it should be noted that NPPES permits, but does not require, non-billable care team members to apply for an NPI number to capture the concept of ‘person’. Some care team members may not have an NPI and may not wish to apply for one as noted above. NPI taxonomy may not have sufficient enough detail to describe all roles associated with an individual’s care team.No Value SetHL7 Comments/suggestions:Interoperability Need: Representing Provider Role in Care SettingTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardSNOMED CT?FinalProductionNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s):Feedback requested.Healthcare Provider Taxonomy (HIPAA): 2.16.840.1.114222.4.11.1066HL7 Participation FunctionSubjects role in the care setting (SNOMED CT?)HL7 Comments/suggestions:This topic was projected in 2016 ISA. Highlighted compares to what was projected.HL7 CQI WG Comments (Sept 23, 2016):We recommend removing “HL7 Participation Function”, restrict to the following SNOMED-CT? concepts and their children:429577009 Patient Advocate223366009 Healthcare professional394730007 Healthcare related organizationI-F: Imaging (Diagnostics, interventions and procedures)Interoperability Need: Representing Imaging Diagnostics, Interventions and Procedures TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardLOINC?FinalProductionNoFreeN/AStandardDICOMFinal ProductionNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): 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. Feedback requestedHL7 Comments/suggestions:(Copied from 2016 ISA) We suggest that the expected timeframe for Radlex to be incorporated into LOINC be explicitly noted. Our understanding is that this is expected to be completed in Sept. 2017. What should be used prior to that time should also be specified.What specific vocabulary in DICOM is being referenced?I-G: Immunizations Interoperability Need: Representing Immunizations – Historical TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard HL7 Standard Code Set CVX—Clinical Vaccines AdministeredFinalProduction73660-18034000YesFreeN/AStandard HL7 Standard Code Set MVX -Manufacturing Vaccine FormulationFinalProduction 80010-13843000NoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): 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.CVX: Vaccines Administered 2.16.840.1.113762.1.4.1010.6 MVX: entire code setHL7 Comments/suggestions:(copied from 2016 ISA) We suggest MVX be reclassified from HISTORICAL representation to ADMINISTERED representationInteroperability Need: Representing Immunizations – Administered TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard HL7 Standard Code Set CVX—Clinical Vaccines AdministeredFinalProductionYesFreeN/AStandardNational Drug CodeFinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): HL7 CVX codes are designed to represent administered and historical immunizations and will not contain manufacturer-specific information.CVX: Vaccines Administered 2.16.840.1.113762.1.4.1010.6 RxNorm: Vaccine Clinical Drug 2.16.840.1.113762.1.4.1010.8 RxNorm: Specific Vaccine Clinical Drug urn:oid:2.16.840.1.113762.1.4.1010.10HL7 Comments/suggestions:(Copied from 2016 ISA) We also suggest RXNORM be added as another code set standard to represent ADMINISTERED data(Copied from 2016 ISA) We suggest a comment note be added under Limitations for National Drug Code, regarding the issue of which Bar Code to use when there are multiple active ingredients in a single package, or multiple separate ingredients that need to be mixed togetherI-H: Industry and OccupationInteroperability Need: Representing Patient Industry and Occupation TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard[See Question 8, Section IV]Limitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): Public comments were varied for this interoperability need. Stakeholders have conveyed the strongest support for National Institute for Occupational Safety and Health (NIOSH) list, which includes an Industry and Occupation Computerized Coding System (NIOCCS), U.S. Department of Labor, Bureau of Labor Statistics, Standard Occupational Classification, and National Uniform Claim Committee Health Care Taxonomy (NUCC) codes standards, but at this time do not have enough information to warrant inclusion of either standard for this interoperability need.Feedback requested HL7 Comments/suggestions:HL7 CQI WG Comments (Sept 22, 2016): In the limitations, Dependencies box we recommend the following changes/corrections:The text “Industry and Occupation Computerized Coding System” should be replaced with “CDC_Census Coding System” which is the one being recommended by NIOSH and which is structure more in line with job classifications; Federal agencies are required to use standard classifications (such as North American Industry Classification System) and the Standard Occupation Classification System. Recommend that ONC replace NIOCCS with CDC_Census Coding System. Also, NUCC and its Health Care Taxonomy code standard is not an appropriate reference here, since that code set is a classification of health profession specialties (medical, nursing, etc) and NOT an occupation classification system. Recommend to delete this reference.Lastly, a note should be made that while there are international classifications of occupation, they are not as granular as the one being referenced by NIOSH (CDC_Census) for use in the US.I-I: Lab testsInteroperability Need: Representing Laboratory Tests TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard for observationsLOINC?FinalProductionYesFreeN/AStandard for observation valuesSNOMED CT?FinalFeedback requestedFeedback requestedYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s):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. A single lab test with a single result will have the same LOINC? term for its order and result answer, but a panel order will have an order LOINC? term and multiple result LOINC? terms for each result in the panel. A single lab test with a single result may have the same LOINC? code for the order and the result or may have a more specific code in the result (for example if the order code was method less or did not declare the system property). A panel order will have an order LOINC? code and multiple result LOINC? terms for each result in the panel. See LOINC projects in the Interoperability Proving Ground.The list of LOINC? Top 2000+ Lab Observations is a starter set represented by OID:?1.3.6.1.4.1.12009.10.2.3?HL7 Comments/suggestions:I-J: MedicationsInteroperability Need: Representing Patient Medications TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardRxNormFinalProductionYesFreeN/AStandardNational Drug Code (NDC)FinalProductionNoFreeN/AStandardNational Drug File – Reference Terminology (NDF-RT)FinalProductionNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): The use of NDC in conjunction with RxNorm can help minimize gaps in representing medications, including compounded products, over -the-counter medications, and herbals. NDF-RT allows for representing classes of medications when specific medications are not known. Immunizations are not considered medications for this interoperability need. RxNorm is often used for the exchange of information; however, it may not be available for export and import by end users.Grouping Value Set: Medication Clinical Drug 2.16.840.1.113762.1.4.1010.4 Medication Clinical General Drug (2.16.840.1.113883.3.88.12.80.17)Medication Clinical Brand-specific Drug (2.16.840.1.113762.1.4.1010.5) (RxNorm). Grouping Value Set: Clinical Substance 2.16.840.1.113762.1.4.1010.2 Medication Clinical Drug (2.16.840.1.113762.1.4.1010.4) (RxNorm )Unique Ingredient Identifier - Complete Set (2.16.840.1.113883.3.88.12.80.20) (UNII)Substance Other Than Clinical Drug (2.16.840.1.113762.1.4.1010.9) (SNOMED CT?).?HL7 Comments/suggestions:I-K: Numerical References & ValuesInteroperability Need: Representing Units of Measure (For Use with Numerical References and Values) TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardThe Unified Code for Units of MeasureFinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): The case sensitive version is the correct unit string to be used for interoperability purposes. Per public comments received, there may be some limitations with UCUM in the laboratory domain remain unresolved. The abbreviations used for a few of the units of measure listed in the UCUM standard are currently on lists of prohibited abbreviations from the Institute for Safe Medication Practice (ISMP).Some abbreviations for units of measure include symbols which may be in conflict with other HL7 standards. Some abbreviations for units are nonstandard for human understanding.(For example, if a result for a White Blood Cell count is 9.6 x 103/μL, the UCUM recommendation for rendering this value in a legacy character application is 9.6 x 10*3/uL. Because the “*” is a symbol for multiplication in some systems.) This recommendation may result in errors either by the information system or the human reading the result.Some other abbreviations used in UCUM are not industry standard for the tests that use these units of measure.UCUM is a syntax for representing units of measure for use with numerical references and values. It is not an enumerated set of codes.Units Of Measure Case Sensitive 2.16.840.1.113883.1.11.12839 (most frequently used codes) Table of Example UCUM Codes for Electronic Messaging" published by the Regenstrief Institute, Inc. Value set is made available at and identified by the OID 1.3.6.1.4.1.12009.10.3.1HL7 Comments/suggestions:I-L: NursingInteroperability Need: Representing Nursing Assessments TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard for observationsLOINC?FinalProductionFeedback requestedNoFreeN/AStandard for observation valuesSNOMED CT?FinalProductionFeedback requestedNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): Assessments are represented as question/answer (name/value) pairs. They are not represented in other terminologies.LOINC? should be used for the assessment/observation questions and SNOMED CT? for the assessment/observation answers (value sets, choice lists).See LOINC projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:This topic was projected in 2016 ISA. Highlighted compares to what was projected.Interoperability Need: Representing Nursing InterventionsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard for observationsLOINC?FinalProductionFeedback requestedNoFreeN/AStandard for observation valuesSNOMED CT?FinalProductionFeedback requestedNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): LOINC? should be used for the assessment/observation questions and SNOMED CT? for the assessment/observation answers (value sets, choice lists).See LOINC projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:Interoperability Need: Representing Outcomes for Nursing TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard for observationsLOINC?FinalProductionFeedback requestedNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): Other ANA-recognized terminologies should be converted to LOINC? for comparison across health systems and/or transmission. See LOINC projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:This topic was projected in 2016 ISA. Highlighted compares to what was projected.Interoperability Need: Representing Patient Problems for Nursing TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard for observation valuesSNOMED CT?FinalProductionFeedback requestedNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): Other ANA-recognized terminologies should be converted to SNOMED CT? for comparison across health systems and/or transmission. Feedback requestedHL7 Comments/suggestions:This topic was projected in 2016 ISA. Highlighted compares to what was projected.Interoperability Need: Representing Nursing Interventions and Observations (Observations are Assessment Items)TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard for observation valuesSNOMED CT?FinalProductionFeedback requestedNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): Other ANA-recognized terminologies should be converted to SNOMED CT? for comparison across health systems and/or transmission. Feedback requestedHL7 Comments/suggestions:This topic was projected in 2016 ISA. Highlighted compares to what was projected.I-M: Patient Clinical “Problems” (i.e., conditions) Interoperability Need: Representing Patient Clinical “Problems” (i.e., Conditions) TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard for observationsLOINC?FinalProductionUknownNoFreeN/AStandard for observation valuesSNOMED CT?FinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): The use of SNOMED CT? for this interoperability need, codes should generally be chosen from three axes: Clinical finding, Situation with explicit context, and Event.Depending on the patient problem, more than one SNOMED CT? code may be required to accurately describe the patient problem (e.g., left leg fracture requires the use of two SNOMED CT? codes)SNOMED CT? supports the combination of codes (post-coordination) to generate new meaning. Codes from other axes can be used in post-coordination. The need to pick multiple codes may be seen as a disadvantage. This can be avoided if post-coordination is limited to the backend, exposing a single code for users to pick.See LOINC projects in the Interoperability Proving Ground.Problem 2.16.840.1.113883.3.88.12.3221.7.4Starter Set: CORE Problem List Subset urn:oid: 2.16.840.1.113762.1.4.1018.240HL7 Comments/suggestions:(Copied from 2016 ISA) Many systems capture/document conditions in other code sets – ICD-9/ICD-10. We suggest these other standards be recognized for current use (e.g., ICD-10) or as part of historical analysis/analytics/CDS (e.g., ICD-9). Similarly, for reporting HEDIS Quality Measures, SNOMED equivalents are not provided. Rather code sets such as ICD and CPT are used.I-N: Preferred Language Interoperability Need: Representing Patient Preferred Language (Presently)TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardRFC 5646FinalProductionFeedback requestedYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): RFC 5646 encompasses ISO 639-1, ISO 639-2, ISO 639-3 and other standards related to identifying preferred languageLanguage urn:oid:2.16.840.1.113883.1.11.11526 (based off RFC 4646. This will be updated to reflect RFC 5646)HL7 Comments/suggestions:I-O: ProceduresInteroperability Need: Representing Dental Procedures PerformedTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardCode on Dental Procedures and Nomenclature (CDT) FinalProductionYes$N/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): Feedback requestedFeedback requestedHL7 Comments/suggestions:Note that SNOMED-CT was removed compared to 2016 ISA.Interoperability Need: Representing Medical Procedures PerformedTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard SNOMED CT?FinalProduction78740381000YesFreeN/AStandard the combination of CPT-4/HCPCSFinalProduction Yes$N/AStandard ICD-10-PCSFinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): ICD-10-PCS is only for Inpatient Procedures. Outpatient Procedures are not coded in ICD-10-PCS.Feedback requested HL7 Comments/suggestions:I-P: Race and EthnicityInteroperability Need: Representing Patient Race and EthnicityTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardOMB standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, Oct 30, 1997FinalProduction762003619500YesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Code System Value Set(s):The CDC Race and Ethnicity Code Set Version 1.0, which expands upon and can be rolled up to 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 high-level race/ethnicity categories in the OMB Standard may be suitable for statistical or epidemiologic or public health reporting purposes but may not be adequate in the pursuit of precision medicine and enhancing therapy or clinical decisions.LOINC? provides observation codes for use in the observation / observation value pattern for communicating race and ethnicity.Race (5 codes): Race Category Excluding Nulls urn:oid:2.16.840.1.113883.3.2074.1.1.3Race (extended set, 900+codes): Race urn:oid:2.16.840.1.113883.1.11.14914Ethnicity: Ethnicity urn:oid:2.16.840.1.114222.4.11.837Ethnicity (extended set, 43 codes): Detailed Ethnicity urn:oid:2.16.840.1.114222.4.11.877HL7 Comments/suggestions:I-Q: ResearchInteroperability Need: Representing Analytic Data for Research Purposes TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardCDISC Controlled Terminology for Regulatory Standards Hosted by NCI-EVSFinalProductionYesFreeN/AStandardCDISC Controlled Terminology for CDISC Therapeutic Area Standards Hosted by NCI-EVSFinalProductionNoFreeN/AStandardCDISC Controlled Terminology for Medical Devices Hosted by NCI-EVSFinalProductionNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): Feedback requested Feedback requestedHL7 Comments/suggestions:I-R: Sexual Orientation and Gender IdentityInteroperability Need: Representing Patient Gender Identity TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard for observationsLOINC?FinalFeedback requestedFeedback requestedNoFreeN/AStandard for observation valuesSNOMED CT?FinalFeedback requestedFeedback requestedYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s):Collect 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.See LOINC projects in the Interoperability Proving Ground.Gender identity. LOINC? code: 76691-5 Male. SNOMED CT? code: 446151000124109 Female. SNOMED CT? code: 446141000124107 Female-to-Male (FTM)/Transgender Male/Trans Man. SNOMED CT? code: 407377005 Male-to-Female (MTF)/Transgender Female/Trans Woman. SNOMED CT? code: 407376001 Genderqueer, neither exclusively male nor female. SNOMED CT? code: 446131000124102 Additional gender category or other, please specify. HL7 Version 3 code: OTHChoose not to disclose. HL7 Version 3 code: ASKU HL7 Comments/suggestions:Interoperability Need: Representing Patient Sex (At Birth)TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard for observationsLOINC?FinalProduction95253302000NoFreeN/AStandard for observation valuesFor Male and Female, HL7 Version 3 Value Set for Administrative Gender; Unknown , HL7 Version 3 Null FlavorFinalProduction17145-3746500YesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) Collect 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.Precision medicine requires an increased focus to document granular, specific information about the patient that aids in targeted delivery of healthcare to the patient. There are other ways to determine gender outside of traditional approaches. [See Question 9, Section IV]See LOINC projects in the Interoperability Proving Ground.LOINC? code: 76689-9 Sex assigned at birthAdministrative Gender (HL7 V3) 2.16.840.1.113883.1.11.1ONC’s 2015 Edition certification requirements reference the following value set for birth sex that use a combination of HL7 Version 3 (V3) Standard value set for Administrative Gender and NullFlavor:(1) Male. M(2) Female. F(3) Unknown. nullFlavor UNKHL7 Comments/suggestions:Interoperability Need: Representing patient-identified sexual orientationTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard for observationsLOINC?FinalFeedback requestedFeedback requestedNoFreeN/AStandard for observation valuesSNOMED CT?FinalFeedback requestedFeedback requestedYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): Collect 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.See LOINC projects in the Interoperability Proving Ground.LOINC? code: 76690-7 Sexual orientationONC’s 2015 Edition certification requirements reference the following value set for sexual orientation. Codes from (i) through (iii) are SNOMED CT? and (iv) through (vi) are from HL7 Version 3:(i) Lesbian, gay or homosexual.38628009(ii) Straight or heterosexual. 20430005(iii) Bisexual. 42035005(iv) Something else, please describe. nullFlavor OTH(v) Don’t know. nullFlavor UNK(vi) Choose not to disclose. nullFlavor ASKUHL7 Comments/suggestions:I-S: Social Determinants [See Questions 10 and 11, Section IV]Interoperability Need: Representing Financial Resource Strain TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardLOINC?FinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): See LOINC projects in the Interoperability Proving Ground.LOINC? code 76513-1 LOINC? answer list ID LL3266-5HL7 Comments/suggestions:Interoperability Need: Representing Level of EducationTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardLOINC?FinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): See LOINC projects in the Interoperability Proving Ground.LOINC? code 63504-5 LOINC? answer list ID LL1069-5HL7 Comments/suggestions:Interoperability Need: Representing StressTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardLOINC?FinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): See LOINC projects in the Interoperability Proving Ground.LOINC? code 76542-0 LOINC? answer list LL3267-3HL7 Comments/suggestions:Interoperability Need: Representing DepressionTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardLOINC?FinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): See LOINC projects in the Interoperability Proving Ground.LOINC? code 55757-9 LOINC? code 44250-9 (with LOINC? answer list ID LL358-3LOINC? code 44255-8 (with LOINC? answer list ID LL358-3)LOINC? code 55758-7 (with applicable UCUM unit of measure)HL7 Comments/suggestions:HL7 CQI WG Comments (Sept 23, 2016):We recommend changing applicable value set to only LOINC? observation codes belonging to LOINC? panels44249-1 - This encompasses all questions and answers in the standard PHQ-9 assessment, and the PHQ score.69724-3 – PHQ-455757-9 – PHQ-2Interoperability Need: Representing Physical ActivityTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardLOINC?FinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): See LOINC projects in the Interoperability Proving Ground.LOINC? code 68515-6 LOINC? code 68516-4With applicable UCUM unit of measureHL7 Comments/suggestions:Interoperability Need: Representing Alcohol UseTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardLOINC?FinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): See LOINC projects in the Interoperability Proving Ground.LOINC? codes 72109-2, LOINC? code 68518-0 (with LOINC? answer list ID LL2179-1)LOINC? code 68519-8 (with LOINC? answer list ID LL2180-9)LOINC? code 68520-6 (with LOINC? answer list ID LL2181-7)LOINC? code 75626-2HL7 Comments/suggestions:Interoperability Need: Representing Social Connection and IsolationType Standard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardLOINC?FinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): See LOINC projects in the Interoperability Proving Ground.LOINC? code 76506-5,LOINC? code 63503-7 (with LOINC answer list ID LL1068-7)LOINC? code 76508-1LOINC? code 76509-9LOINC? code ?76510-7LOINC? code ?76511-5 (with LOINC answer list ID LL963-0)LOINC? code 76512-3HL7 Comments/suggestions:Interoperability Need: Representing Exposure to Violence (Intimate Partner Violence)TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardLOINC?FinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): See LOINC projects in the Interoperability Proving Ground.LOINC? code 76499-3 LOINC? code 76500-8 (with LOINC? answer list ID LL963-0)LOINC? code 76501-6 (with LOINC? answer list ID LL963-0)LOINC? code 76502-4 (with LOINC? answer list ID LL963-0)LOINC? code 76503-2 (with LOINC? answer list ID LL963-0)LOINC? code 76504-0HL7 Comments/suggestions:I-T: Tobacco Use (Smoking Status) [See Question 12, Section IV] Interoperability Need: Representing Patient Tobacco Use (Smoking Status) Observation Result Values or Assertions TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard for observationsLOINC?FinalProduction673103238500NoFreeN/AStandard for observation valuesSNOMED CT?FinalProduction723904635500YesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): There are limitations in SNOMED CT? for this interoperability need, which include not being able to capture severity of dependency, level of use, quit attempts, lifetime exposure, and use of e-Cigarettes. LOINC? includes codes that support recording smoking status in the CDC’s preferred (and sometimes required) responses (e.g. Tobacco smoking status NHIS[76691-5]) and other kinds of observations (e.g. Have you smoked at least 100 cigarettes in your entire life [PhenX] [63581-3] or How old were you when you first started smoking cigarettes every day [PhenX] [63609-2].See LOINC projects in the Interoperability Proving Ground. LOINC? code 72166-2 “Tobacco smoking status NHIS”Current Smoking Status urn:oid:2.16.840.1.113883.11.20.9.38ONC’s 2015 Edition certification requirements reference the following value set for smoking status. Codes from SNOMED CT? :(1) Current every day smoker. 449868002(2) Current some day smoker. 428041000124106(3) Former smoker. 8517006(4) Never smoker. 266919005(5) Smoker, current status unknown. 77176002(6) Unknown if ever smoked. 266927001(7) Heavy tobacco smoker. 428071000124103(8) Light tobacco smoker. 428061000124105HL7 Comments/suggestions:Combines what was in 2016 ISA in the main section and projected for inclusion. Highlighted comparison against bothI-U: Unique Device Identification Interoperability Need: Representing Unique Implantable Device Identifiers TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardUnique device identifier as defined by the Food and Drug Administration at 21 CFR 830.3FinalProductionYesFreeN/AImplementation SpecificationHL7 Harmonization Pattern for Unique Device Identifiers FinalProductionNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): Per the FDA, Unique Device Identification system will be phased in over several years, with the final compliance date of September, 2020.See UDI projects in the Interoperability Proving Ground. Feedback requestedHL7 Comments/suggestions:(Copied from 2016 ISA) We note that the UDI regulation is actually not an interoperability standard and should not be listed as such. Rather it defines what a UDI is and prescribes the need for capturing and presenting such data. There is ongoing confusion about how and when to communicate UDI, and we are concerned that there is a rush to implement UDI without full consideration of all relevant uses and requirements. At a minimum, all care related and downstream-related uses need to be considered together to ensure appropriate data capture and communication can occur. The HL7 Harmonization Pattern for Unique Device Identifiers has recently undergone an update, while a project has been established to fully define the various interoperability use cases where HL7 needs to provide further guidance on when and how to communicate UDI using V2, C-CDA, and/or FHIR in particular. We further note that additional requirements have emerged to not only be able to communicate the UDI carrier (the human readable formatted string under the barcode on the device), but also the individual UDI components represented in the UDI carrier. This particularly requires CCDA updates as it currently is not formally capable of doing so. Therefore, while per the definition of Standards Process Maturity one could state the document is “final”, the impression that all the necessary standards and implementation guides are in place is not accurate. Additionally, we expect non-HL7 standards to be able to communicate the UDI carrier and/or the UDI components as well, which should be reflected here. As a minimum, we suggest describing these gaps in the Limitations, Dependencies, and Preconditions for Consideration section until the relevant implementation guides emerge. In addition, it will be important to consider the applicability of unique device identification to non-implanted mobile healthcare devices and general consumer devices performing healthcare functions (e.g., smartphones). There is a definite need to capture the chain of data custody from the originating device as the data flows from device to other HIT including EHRs. The concept of both hardware and software as “devices” and as “authors/actors” is already supported in HL7 standards such as V2, C-CDA and FHIR, so these capabilities should be extended to support device identification for mobile health. A key question is whether UDI, or something like it, should be assigned to such devices and/or to each medical app that is installed on such devices? It has also been suggested that UDI-DI 22| should be updated for each major revision to medical app software, and UDI-PI should be updated for each minor software revision. It is too soon to say definitively whether UDI is the appropriate standard, given the current focus of UDI on implanted devices, but the need for an interoperable standard to identify mobile devices exists. See also suggestions for Data Provenance, which device identification would support. If UDI is found to be appropriate for mobile device/app identification, it should be represented consistently across Standards as will be proposed in the HL7 document: “Harmonization Pattern for Unique Device Identifiers.” As we develop the use cases and supporting implementation guidance for interoperability, we suggest separating at least the use cases focusing on logistics (from manufacturer to provider) from the clinical use (implantation and/or monitoring and actual use) flows where UDI needs to be exchanged. While there is a connection point, requirements may vary, as well as keep the guidance more manageable.Suggest to not fully repeat this.I-V: Vital SignsInteroperability Need: Representing Patient Vital Signs TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardLOINC?FinalProductionYesFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): See LOINC projects in the Interoperability Proving Ground.Vital Sign Result urn:oid:2.16.840.1.113883.3.88.12.80.62HL7 Comments/suggestions:(Copied from 2016 ISA) Propose to add HL7 Privacy and Security Healthcare Classification System [HCS] – HL7 HL7 and its Security and Community Based Collaborative Care (CBCC) Work Groups recommend that the ISA include the normative HL7 Privacy and Security Healthcare Classification System [HCS] because it encompasses vocabulary for the confidentiality Code that is required for use in: All CDA Implementation Guides at the Document Header, and may be used at the Section level because it is required in the base CDA R2 standard; The IHE XDS Soap Headers required by Meaningful Use, which must include at least the confidentialityCode and may include other HCS vocabulary for e.g., purpose of use and obligationsThe Direct XDR/XDM option for Meaningful Use, which must include at least the confidentialityCode and may include other HCS vocabulary for e.g., purpose of use and obligations; and Data Segmentation for Privacy, which, like all CDA profiles, requires confidentialityCode at the Document Header, recommends it at the Section level, recommends inclusion of a Privacy Marking section for security labels pertaining to the entire Document, and recommends inclusion in Privacy Annotations or Security Labels at the CDA Entry Level. In addition, it is used in the draft FHIM Privacy and Security Architecture Framework, which is updating the expired HL7 Security and Privacy Domain Analysis Model. For these reasons, the HL7 and its Security and CBCC Work Groups support the ISA recommending increasing the adoption level to at least 61% to 80% adoption and to indicate that the specification has been adopted indirectly because DS4P, Exchange, and Direct XDR/XDM are adopted in regulation. These recommendations are captured below in an ISA table.Interoperability Need: Representing privacy and security classification of healthcare information TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardHL7 Privacy and Security Healthcare Classification System [HCS]Final(Normative)ProductionYes since required in DS4P and optional in XD*FreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedITI-3 p. 63 Use of Sensitivity tags expose the nature of the sensitivity and should be used only when the end-to-end confidentiality of the tags can be assured.HL7 Comments/Suggestions:(Copied from 2016 ISA) HL7 and its Security and Community Based Collaborative Care (CBCC) Work Groups recommend that the ISA include the normative HL7 Role Based Access Control Catalog for purposes of enabling trading partners to exchange interoperable role information in patient consent directives and trust policies, and to enable access control systems to enforce data segmentation. This standard is based on ASTM E 1986 roles and maps these to well understood healthcare information objects to create coded RBAC permissions, which can be shared with trading partners that require recipients to comply with the sender’s access control policies. This approach is used in the Authorization Framework used for Exchange where roles of recipients are matched to determine permission of the resources requested/disclose.Interoperability Need: Representing role based access control TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardHL7 Role Based Access Control CatalogFinalProductionto the extent used in MU Exchange FreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Near term enhancement: HL7 Security and CBCC WGs are balloting an update to the RBAC Catalog to include Attribute Based Access Control codes for clearances, which leverage the HL7 Healthcare Classification System security labels, to enable data segmentation. Conveyance of role and clearances in attribute and authorization certificates must be encrypted.Section II: Content/Structure Standards and Implementation SpecificationsII-A: Admission, Discharge, and TransferInteroperability Need: Sending a Notification of a Patient’s Admission, Discharge and/or Transfer Status to Other ProvidersTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardHL7 2.5.1 (or later) ADT messageFinalProduction495306032500NoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: 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.See HL7 V2 projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:(Copied from 2016 ISA) We appreciate the updates made to the 2016 ISA to focus on a minimum standard threshold. We should take this opportunity to consider this an area of focus where further implementation guidance, beyond the minimally required standards. We understand that the topic of event notification may provide an area of focus to establish these, where working with IHE may be beneficial.Reiterate our concern that without implementation guides this is not a helpful reference given the implementation variances in ADT messages.Interoperability Need: Sending a Notification of a Patient’s Admission, Discharge and/or Transfer Status to the Servicing PharmacyTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardNCPDP SCRIPT Standard, Implementation Guide, Version 10.6FinalProductionNo$NoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The “Census Message” transaction allows for long-term and post-acute care settings to notify the servicing pharmacy of a patient’s admission, discharge and/or transfer status. See NCPDP projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.II-B: Care PlanInteroperability Need: Documenting Patient Care Plans TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard HL7 Clinical Document Architecture (CDA?), Release 2.0, Final Edition FinalProduction723901651000YesFreeNoImplementation Specification HL7 Implementation Guide for CDA? Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1Balloted DraftPilot Feedback requestedYesFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedHL7 Comments/suggestions:(Copied from 2016 ISA) We are concerned that the level of granularity for the use case may give the wrong impression on available standards. While the C-CDA has the ability communicate care plans data, in the rapidly evolving shift from FFS to value based payment models that require tight coordination across providers, static exchange of such care plans can work for simple use cases, but not for those patients where tight coordination is most critical. The ISA does not reflect the understanding that much more work is required to get to an approach to address the more complex virtual coordination across providers and the standards needed for that process. This will drive the need to have more advanced standards than what we have today. In summary, the current line item gives a false sense of comfort in a very challenging area, which should be reflected in the limitations, or by adjusting the title.Suggest we adjust somewhat given the Cancer use case now being included, but still keeps this one very wide where C-CDA is not necessarily well suited to address all.Interoperability Need: Documenting, Planning and Summarizing Care Plans for Patients with CancerTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard HL7 Clinical Document Architecture (CDA?), Release 2.0, Final EditionFinalProductionNoFreeNoImplementation Specification HL7 CDA? R2 Implementation Guide: Clinical Oncology Treatment Plan and Summary, Release 1Balloted DraftPilot Feedback requestedNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See CDA projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.II-C: Clinical Decision Support Interoperability Need: Shareable Clinical Decision SupportTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool Availability1-StandardHL7 FHIR Profile: Quality, Release 1Balloted DraftPilot62230-190500NoFreeYes2-Standard HL7 Cross-Paradigm Specification: Clinical Quality Language, Release 1, STU Release 1.1Balloted DraftProductionNoFreeYes3-Standard HL7 Version 3 Standard: Decision Support Service, Release 2.Balloted DraftPilotNoFreeNo3-Implementation Specification HL7 Implementation Guide: Clinical Decision Support Knowledge Artifact Implementation Guide, Release 1.3, Draft Standard for Trial Use.Balloted DraftPilotFeedback requestedNoFreeNo1-Emerging Implementation Specification HL7 FHIR Implementation Guide: Clinical Quality Framework (CQF on FHIR), Release?Balloted DraftPilot62230-190500NoFreeYesLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See FHIR projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:(Copied from 2016 ISA) HL7 Implementation Guide: Clinical Decision Support Knowledge Artifact Implementation Guide, Release 1.3. Draft Standard for Trial Use. We suggest marking this with an Adoption Level of Low (one bullet).We suggest the Implementation Maturity be set to Production. We are aware of at least two companies that have been using this specification as the basis of production-level artifacts: Motive Medical Intelligence (contact: Julie Scherer) and Evinance (contact: Chad Armstrong), while others may be implementing this as well (Copied from 2016 ISA) We suggest adding another standard: Arden Syntax V2.10, with a Implementation Maturity of Production. We also suggest noting in the Limitations, Dependencies, and Preconditions for Consideration that Arden has the “curly braces” problem of not having a standard data model specificationInteroperability Need: Provide Access to Appropriate Use CriteriaTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityEmerging Implementation Specification HL7 FHIR Implementation Guide: Clinical Quality Framework (CQF on FHIR), Release?Balloted DraftPilot62230-190500NoFree YesEmerging Implementation Specification HYPERLINK "" IHE: Guideline Appropriate Ordering(GAO)Balloted DraftPilotFeedback requestedNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: IHE: Guideline Appropriate Ordering (GAO) specification is being incorporated into the CQF content listed above it. See FHIR and IHE projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.Interoperability Need: Communicate Appropriate Use Criteria with the Order and Charge to the Filling Provider and Billing System for Inclusion on Claims.TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityEmerging Implementation Specification HYPERLINK "" IHE: Clinical Decision Support OrderAppropriateness Tracking (CDS-OAT)Balloted DraftPilotFeedback requestedNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See IHE projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.II- D: Clinical Quality MeasurementInteroperability Need: Sharing Quality Measure Artifacts for Quality Reporting InitiativesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool Availability1-StandardHL7 V3: Representation of the Health Quality Measures Format (eMeasure), DSTU Release 2.1Balloted DraftPilotNoFreeYes2-StandardHL7 FHIR Profile: Quality, Release 1Balloted DraftPilot62230-190500NoFreeYes3-Standard HL7 Cross-Paradigm Specification: Clinical Quality Language, Release 1, STU Release 1.1Balloted DraftProductionNoFreeYes1-Implementation SpecificationHL7 V3 Implementation Guide: Quality Data Model (QDM)-based Health Quality Measure Format (HQMF), Release 1 – US RealmBalloted DraftPilotNoFreeYes1-Emerging Implementation SpecificationHL7 Version 3 Implementation Guide: Clinical Quality Language (CQL)-based Health Quality Measure Format (HQMF), Release 1 - US RealmBalloted DraftPilot81915571500NoFreeNo2-Emerging Implementation Specification HL7 FHIR Implementation Guide: Clinical Quality Framework (CQF on FHIR), Release?In DevelopmentPilot81915571500NoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See FHIR projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:General Comment to HL7 Policy Committee: we recommend making an overarching comment on the ISA regarding FHIR, FHIR structure and maturity as a whole, and ALSO make FHIR-related comments within specific sections (like we are doing below).HL7 CQI WG Comments (September 22, 2016):HQMF: Agree with naming it here; Implementation Maturity should be “Production” (not Pilot); Adoption level is correct; other elements are correct; Roadmap note to be included in the Limitations, Dependencies, Preconditions box: HQMF is expected to go to normative in 2017; While HQMF will still be in use, we expect that systems may eventually transitioned it to FHIR Clinical ReasoningFHIR Profile: Quality: We agree with naming it here and current content; however we are requesting that this particular document be renamed from “FHIR Profile: Quality” to “FHIR Profile: Quality (QI-Core)”. Also, the URL link takes people to the STU Comment site. The URL should be corrected to take people to the QI-Core site. CQL: agree with naming it here and current content; The URL takes people to the STU Comment site. It should be corrected and take people to the CQL document (not the STU comment site).QDM-based HQMF: Agree with naming it here; The name should be modified to “Release 1.4 DSTU 4 (based on HQMF 2.1)”; Implementation maturity and Adoption level are correct; Federally required should be changed to “yes” since this is required by a federal program (Medicare) and the definition of this column includes “…adopted in regulations, referenced as a federal program requirement, or referenced in a federal procurement….”; Also, the URL takes people to the wrong site. It should be corrected and take people to the QDM-Based HQMF document.Emerging – CQL-based HQMF: agree with naming it here; name should be “Release 1 DSTU 1” and with content; Also, the URL is taking people to the HL7 Standards Master Grid, and not to the CQL-based HQMF document. URL should be corrected. Roadmap note to be included in the Limitations, Dependencies, Preconditions box: CQL-baser HQMF major release 2 expected in 2017Emerging – CQF on FHIR: agree with naming it here and with content; Roadmap note to be included in the Limitations, Dependencies, Preconditions box: The CQF on FHIR will be transitioned to FHIR Clinical ReasoningAddition: We recommend adding FluentPath as an emerging standard, in development, pilot status, one-dot adoption, not required, free of charge, no test.II-E: Clinical Quality ReportingInteroperability Need: Reporting Aggregate Quality Data to Federal Quality Reporting InitiativesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest 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 1Balloted DraftProductionYesFreeYesEmerging Implementation Specification HL7 CDA? R2 Implementation Guide: Quality Reporting Document Architecture - Category III (QRDA I) DSTU Release2 (US Realm)In DevelopmentPilotYesFreeYesLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See CDA and QRDA projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:HL7 CQI WG Comments (Sept 22, 2016):CDA: Agree with naming it here and with contentQRDA Cat III: Agree with naming it here; the ballot reference name should be corrected to “HL7 Implementation Guide for CDA? Release 2: Quality Reporting Document Architecture – Category III (QRDA III) Release 1 DSTU Release 1” Emerging - QRDA Cat III: Agree with naming it here and with content; name should be changed to “DSTU Release 3” rather than “DSTU Release 2”; also, Federally required should be changed to No (can’t mandate something that is in development…); finally, since we are completing this ballot cycle the resolution of comments, and expect to publish a new version – which we expect it will be called “QRDA III Release 1.1” – perhaps ONC should consider calling it that way No additional items recommended to be added as emerging standards/implementation guides`Interoperability Need: Reporting Patient-level Quality Data to Federal Quality Reporting Initiatives TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard HL7 Clinical Document Architecture (CDA?), Release 2.0, Final EditionFinalProduction NoFreeNoImplementation SpecificationHL7 CDA? R2 Implementation Guide: Quality Reporting Document Architecture - Category I (QRDA I) DSTU Release 3 (US Realm)Balloted DraftProductionYesFreeYesEmerging Implementation Specification HL7 CDA? R2 Implementation Guide: Quality Reporting Document Architecture - Category I (QRDA I) DSTU Release 3 (US Realm)In DevelopmentPilotYesFreeYesLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See CDA and QRDA projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:HL7 CQI WG Comments (Sept 22, 2016):CDA: Agree with naming it here and with contentQRDA Cat I: Agree with naming it here; the name should be “Release 1 DSTU 3”; other content correctEmerging - QRDA Cat I: Agree with naming it here; the name should be “Release 1 DSTU 4” (right now the name is identical to the one listed above); the URL should be corrected to go to the HL7 site for DSTU Release 4 (not 3, as it is currently set to go to); other content correctNo additional items recommended to be added as emerging standards/implementation guidesII-F: Data Provenance Interoperability Need: Establishing the Authenticity, Reliability, and Trustworthiness of Content Between Trading Partners.TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityImplementation Specification HYPERLINK "" HL7 CDA? Release 2 Implementation GuideData Provenance, Release 1 - US RealmBalloted DraftPilot577852222500NoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration:This implementation specification is focused on data provenance representation for CDA R2 implementations and the use of CDA templates.See CDA projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.II-G: Drug Formulary & BenefitsInteroperability Need: The Ability for Pharmacy Benefit Payers to Communicate Formulary and Benefit Information to Prescribers SystemsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityImplementation Specification NCPDP Formulary and Benefits v3.0FinalProductioncentercenterYes$NoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: NCPDP Formulary and Benefits v3.0 does not provide real-time patient-level benefit information.The NCPDP Real Time Prescription Benefit Inquiry (RTPBI) is an alternative in development that should be monitored as a potential emerging implementation specification. Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse?(e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:II-H: 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 LevelFederally RequiredCostTest Tool AvailabilityImplementation SpecificationNCPDP 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. Allows the pharmacist to notify the prescriber about the status of a prescription in three cases: (1) To notify the prescriber of a dispensed prescription, (2) to notify the prescriber of a partially dispensed prescription, and (3) to notify a prescriber of a prescription not dispensed. See NCPDP projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:(Copied from 2016 ISA) We suggest adding a provision that when using a mobile device connected to an EHR these standards apply as the EHR generates the transactions. It is not clear, and NCPDP may have further information, when a mobile device is used for e-prescribing whether the same or different standards are used.Interoperability Need: A Prescriber’s Ability to Grant a Refill Request to the PharmacyTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityImplementation SpecificationNCPDP SCRIPT Standard, Implementation Guide, Version 10.6FinalProductionYes$YesLimitations, 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. Allows the pharmacist to request approval for additional refills of a prescription beyond those originally prescribed. See NCPDP projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions: Interoperability Need: Allows the Pharmacy to Respond to Prescriber with a Change on a New PrescriptionTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityImplementation SpecificationNCPDP SCRIPT Standard, Implementation Guide, Version 10.6 FinalProductionFeedback requested Yes$YesLimitations, Dependencies, and Preconditions for Consideration:Applicable Security Patterns for Consideration:The RX message allows a Pharmacist to request a change of a new prescription or a “fillable” prescription.See NCPDP projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse (e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transactionHL7 Comments/suggestions: Interoperability Need: Cancellation of a PrescriptionTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityImplementation SpecificationNCPDP SCRIPT Standard, Implementation Guide, Version 10.6FinalProductionFeedback requestedYes$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. Notifies the pharmacy that a previously sent prescription should be cancelled and not filled.Send the prescriber the results of a prescriptions cancellation request.See NCPDP projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:Interoperability Need: Pharmacy Notifies Prescriber of Prescription Fill Status TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityImplementation Specification NCPDP SCRIPT Standard, Implementation Guide, Version 10.6FinalProductionFeedback requestedYes$YesLimitations, 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. Allows the pharmacist to notify the prescriber about the status of a prescription in three cases: (1) To notify the prescriber of a dispensed prescription, (2) to notify the prescriber of a partially dispensed prescription, and (3) to notify a prescriber of a prescription not dispensedSee NCPDP projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:Interoperability Need: A Prescriber’s Ability to Obtain a Patient’s Medication History TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityImplementation SpecificationNCPDP SCRIPT Standard, Implementation Guide, Version 10.6FinalProduction857255270500Yes$YesLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Both the “Medication History Request” and “Medication History Response” transactions need to be implemented for interoperability purposes. Both the prescriber and the receiving pharmacy or pharmacy benefits manager (PBM) must have their systems configured for the transaction in order to facilitate successful exchange. See NCPDP projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:Interoperability Need: Allows Prescriber to Respond to a Prior Authorization for a Medication Electronically to the Payer/Processor.TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityImplementation Specification NCPDP SCRIPT Standard, Implementation Guide, Version 10.6FinalProductionNo$NoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See NCPDP projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:Interoperability Need: Prior Authorization Cancel RequestTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityImplementation Specification NCPDP SCRIPT Standard, Implementation Guide, Version 10.6FinalProductionNo$NoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See NCPDP projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:II-I: Family health history (clinical genomics)Interoperability Need: Representing Family Health History for Clinical GenomicsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard HL7 Version 3 Standard: Clinical Genomics; PedigreeBalloted DraftProduction704853619500YesFreeNoImplementation Specification HL7 Version 3 Implementation Guide: Family History/Pedigree Interoperability, Release 1Balloted DraftProductionNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: There is no available vocabulary to capture family genomic health history. Further constraint of this standard and implementation specification may be required to support this interoperability needAccording to HIMSS, the following value sets may be considered:Gene Identifier: HGNC Value SetTranscript Reference Sequence Identifier: NCBI vocabularyDNA Sequence Variation Identifier: NCBI vocabularyDNA Sequence Variation: HGVS nomenclatureHL7 Comments/suggestions:Interoperability Need: Representing Patient Family Health History Observations TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardLOINC?FinalProduction723901841500FreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Value Set(s) and Starter Set(s): See LOINC projects in the Interoperability Proving Ground.Problem Type 2.16.840.1.113883.3.88.12.3221.7.2?(LOINC? code system)HL7 Comments/suggestions:II-J: Images Interoperability Need: Medical Image Formats for Data Exchange and DistributionTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard Digital Imaging and Communications in Medicine (DICOM)FinalProductionNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Use Image Acquisition Technology Specific Service/Object Pairs (SOP) ClassesFeedback requestedHL7 Comments/suggestions:Interoperability Need: Format of Medical Imaging Reports for Exchange and DistributionTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest 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 requestedSecure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:Interoperability Need: Format of Radiology Reports for Exchange and Distribution TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityImplementation Specification IHE Management of Radiology Report Templates (MRRT)Balloted DraftPilotFeedback requestedNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See IHE projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.II-K: LaboratoryInteroperability Need: Receive Electronic Laboratory Test ResultsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest 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 2012Balloted DraftProductionYesFreeYesEmerging Implementation Specification HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Results Interface Implementation Guide, Release 1 DSTU Release 2 - US RealmBalloted 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.See HL7 V2 projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:Unclear why LRI R1 dropped to one bullet for Adoption Level considering 2014 Edition still includes a criterion for it, while OPPS will drive it further with need for structured data support.While LRI may not be used, HL7 V2 is used widely for this purpose. At least it should be noted that perhaps V2.5.1 is not widely used as the base where LRI is not used, V2.3.1 + V2.4 + V2.5.1 should be about get to at least 3-4 bullets worth (as paper reports would stand in the way of getting to five).Should include Lab EHR-S IG to clarify sender/receiver responsibilities to achieve end-to-end interoperability.Interoperability Need: Ordering Labs for a Patient TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest 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 RealmBalloted 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.Note that the implementation specification has been harmonized with the most current suite of Lab US Realm Implementation Guides and is scheduled for update in the HL7 January 2017 Ballot CycleSee HL7 V2 projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:Interoperability Need: Support the Transmission of a Laboratory’s Directory of Services to Health IT. TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard HL7 2.5.1FinalProductionNoFreeNoImplementation Specification HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework, Release 2, DSTU Release 2Balloted DraftProduction 692157493000NoFreeNoLimitations, 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.Note that the current version has been harmonized with the most current suite of Lab US Realm Implementation Guides and is scheduled for update in the HL7 January 2017 Ballot CycleSee HL7 V2 projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:II-L: Medical Device Communication to Other Information Systems/Technologies Interoperability Need: Transmitting Patient Vital Signs from Medical Devices to Other Information Systems/TechnologiesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityImplementation SpecificationIHE-PCD (Patient Care Device Profiles)FinalProductionNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration:Feedback requestedRecommend adding the link to the guidance developed by FDA CDRH and CBER: Design Considerations and Pre-Market Submission Recommendations for Interoperable Medical Devices to the footnote on page 68 See IHE projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.II-M: 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 LevelFederally RequiredCostTest 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 YesFreeNoImplementation Specification HL7 Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton), Release 4.FinalProduction YesFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedHL7 Comments/suggestions:II-N: Patient Preference/ConsentInteroperability 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 LevelFederally RequiredCostTest Tool AvailabilityImplementation Specification IHE Basic Patient Privacy Consents (BPPC)FinalProduction NoFreeYes – OpenLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: These profiles operate in conjunction with the IHE XDS, XCA, and XDR profiles IHE BPPC may not support management of patient privacy across governmental jurisdictions which may have different regulations regarding access to patient data by providers, patients, governmental entities, and other organizations.Along with security tokens and consent documents, security labels that are the critical third part of the Attribute-Based-Access-Control and SLS should be mentioned as well. Security Labels are used in CDA, FHIR, as well as the IHE Document Sharing (e.g. XDS), as described on the FHIR security page at IHE projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication. Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery. Authentication Enforcer – centralized authentication processes. Authorization Enforcer – specified policies access control. Credential Tokenizer – encapsulate credentials as a security token for reuse (examples – SAML, Kerberos). Assertion Builder – define processing logic for identity, authorization and attribute statements. User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.Patient Consent Information - Identifies the patient consent information that may be required before data can be accessed.HL7 Comments/suggestions:(Copied from 2016 ISA) We suggest that in reference to security tokens, IUA (OAuth), HEART and SMART should be mentioned. The FHIR security page does so at: fhir.github.io/security.html (Copied from 2016 ISA) Along with security tokens and consent documents, security labels that are the critical third part of the Attribute-Based-Access-Control and SLS should be mentioned as well. Security Labels are used in CDA, FHIR, as well as the IHE Document Sharing (e.g. XDS), as described on the FHIR security page at fhir.github.io/security-labels.htmlII-O: Public Health Reporting Interoperability Need: Reporting Antimicrobial Use and Resistance Information to Public Health AgenciesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest 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.FinalProduction628652286000YesFreeNoEmerging Implementation Specification HL7 Implementation Guide for CDA Release 2 – Level 3: NHSN Healthcare Associated Infection (HAI) Reports Release 2, DSTU Release 2.1Balloted DraftPilotNoFreeNoLimitations, 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.See CDA projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:Interoperability Need: Reporting Cancer Cases to Public Health AgenciesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool Availability1-Standard HL7 Clinical Document Architecture (CDA?), Release 2.0, Final EditionFinalProductionYesFreeNo2-Implementation Specification HL7 Implementation Guide for CDA? Release 2: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1 - US RealmBalloted DraftProductionYesFreeYes1-Emerging Implementation SpecificationHL7 CDA ? Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1, DSTU Release 1.1 – US RealmBalloted DraftPilot YesFreeNoEmerging Implementation Specification IHE Quality, Research, and Public Health Technical Framework Supplement, Structured Data Capture, Trial ImplementationBalloted DraftPilot679458636000NoFreeNoEmerging Implementation Specification HL7 FHIR DSTU 2, Structured Data Capture (SDC) Implementation GuideBalloted DraftPilotNoFreeNoLimitations, 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. Some jurisdictions may not support cancer case reporting at this time. See CDA projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:Interoperability Need: Case Reporting to Public Health AgenciesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool Availability1- Implementation Specification IHE Quality, Research, and Public Health Technical Framework Supplement, Structured Data Capture, Trial ImplementationBalloted DraftPilotNoFreeNo1-Implementation Specification IHE IT Infrastructure Technical Framework, Volume 1 (ITI TF-1): Integration Profiles, Section 17: Retrieve Form for Data Capture (RFD)FinalProductionNoFreeYes2-StandardHL7 electronic Initial Case Report HL7 C-CDA STU: HL7 Version 3 Clinical Document Architecture (CDA), Release 2 format.Balloted DraftPilotNoFreeNo2-Standard Fast Healthcare Interoperability Resources (FHIR), DSTU 2Balloted DraftPilotNoFreeNo2- Emerging Implementation Specification HL7 FHIR DSTU 2, Structured Data Capture (SDC) Implementation GuideBalloted DraftPilotNoFreeNo2 – Emerging StandardHL7 FHIR STU 3In DevelopmentPilotN/ANoFreeNoLimitations, 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.Structured Data Capture Implementation Guide does not currently restrict vocabulary to standard vocabulary setsSome additional implementation guides related to public health reporting follow. Reporting is often captured under a specialized registry with associated standards when not specified as a separate measure. These include:Early Hearing Detection and Intervention (EHDI)Office of Populations Affairs (OPA) Family Planning Reporting IHEProfileSee FHIR projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:Interoperability Need: Electronic Transmission of Reportable Lab Results to Public Health AgenciesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest 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 CertificationFinalProduction762001270000YesFreeYesEmerging 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.1Balloted DraftPilotFeedback requestedNoFreeNoLimitations, 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.Note the Public Health Profile as specified in the HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Results Interface Implementation Guide, Release 1 DSTU Release 2 - US Realm is harmonized with the Lab US Realm suite of Implementation Guides and improves on the ELR emerging implementation specification. Both are scheduled for revision in the HL7 January 2017See HL7 V2 projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:Note that the adoption level for V2.5.1 has been appropriately dropped as many have adopted the ELR guide.Interoperability Need: Sending Health Care Survey Information to Public Health AgenciesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard HL7 Clinical Document Architecture (CDA?), Release 2.0, Final EditionFinalProduction72390952500NoFreeNoImplementation Specification HL7 Implementation Guide for CDA? R2: National Health Care Surveys (NHCS), Release 1 - US Realm Balloted DraftPilotYesFreeNoLimitations, 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.See CDA projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:Interoperability Need: Reporting Administered Immunizations to Immunization RegistryTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard HL7 2.5.1FinalProduction425453873500YesFreeNoImplementation SpecificationHL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.4FinalProductionYesFreeYesImplementation Specification HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5FinalProductionYesFreeYesLimitations, 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.HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5 – Addendum is also available.See HL7 V2 projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:Interoperability Need: Reporting Syndromic Surveillance to Public Health (Emergency Department, Inpatient, and Urgent Care Settings)TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard HL7 2.5.1FinalProductioncentercenterYesFreeNoImplementation SpecificationPHIN Messaging Guide for Syndromic Surveillance: Emergency Department and Urgent Care Data Release 1.1 and Conformance Clarification for EHR Certification of Electronic Syndromic Surveillance, Addendum to PHIN Messaging Guide for Syndromic Surveillance?FinalProductionYesFreeYesEmerging Implementation Specification PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Care Settings, Release 2.0 and Erratum to the CDC PHIN 2.0 Implementation Guide, August 2015; Erratum to the CDC PHIN 2.0 Messaging Guide, April 2015 Release for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Care SettingsFinalPilotYesFreeNoLimitations, 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.An Erratum to the CDC PHIN 2.0 Implementation Guide was issued in August, 2015. Implementers should refer to this guide for additional information and conformance guidance. See HL7 V2 projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse?(e.g., – SAML, Kerberos).User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:II-P: Representing clinical health information as a “resource”[See Question 13, Section IV]Interoperability Need: Representing Clinical Health Information as “Resource”TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard Fast Healthcare Interoperability Resources (FHIR), DSTU 2Balloted DraftPilotNoFreeYesEmerging StandardHL7 FHIR STU 3In DevelopmentPilotN/ANoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: HL7 defines a “resource” as an entity that: has a known identity (a url) by which it can be addressed; identifies itself as one of the types of resource defined in the FHIR specification; contains a set of structured data items as described by the definition of the resource type; and, has an identified version that changes if the contents of the resource changeSee FHIR projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:(Copied from 2016 ISA) While we clearly support the adoption of FHIR as it will be able to support a variety of emerging use cases enabling data access for viewing, decision support, etc. at a more granular data element level, heretofore more challenging, albeit it not impossible, with earlier standards. This is further recognized by the substantial support from the industry to develop and adopt FHIR. However, the description of the use case / interoperability is not clear why there is a need to represent clinical information as a “resource”. The ability to, e.g., query more granular data or enable RESTful service access to individual data elements within the Common Clinical Data Set (where “data element” effectively equates to individual concepts represented in the CCDS) seem to be the real underlying use cases and as such should be recognized and clarified. We suggest that the description of FHIR note the following limitations: The need for profiles to enable FHIR to (1) fully represent the semantics of many interoperability scenarios given FHIR resources’ focus on the 80/20 rule and (2) define restrictions that enable semantic interoperability, e.g., for value set bindings. Without such profiles and implementation guides we will experience the same widely disparate use of the base V2, V3 / CDA standards where implementation guides were not available. The need of underlying clinical data models such as could be provided by the Clinical Information Modeling Initiative (CIMI) for clearly establishing detailed semantics using FHIR and the inter-relationship among these detailed clinical modelsII-Q: Research Interoperability Need: Submission of Analytic Data to FDA for Research PurposesTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardCDISC Study Data Tabulation Model (SDTM)FinalProduction6226317996900YesFreeYesStandardCDISC Analysis Dataset Model (ADaM)FinalProduction6226318368000YesFreeN/AStandardCDISC Operational Data Model (ODM)FinalProduction6226318326800NoFreeYesStandardCDISC Dataset-XML (ODM-Based)FinalProduction5038818285500NoFreeN/AStandardCDISC Define-XML (ODM-Based)FinalProduction7413818244300NoFreeN/AStandardCDISC Standard for the Exchange of Non-clinical Data (SEND)FinalProduction6226318203100YesFreeN/AStandardStudy Data Tabulation Model Implementation Guide for Medical Devices (SDTMIG-MD)FinalProduction6226318752300NoFreeN/AStandardTherapeutic Area Standards (to complement the aforementioned CDISC foundational standards that apply across all therapeutic areas)FinalProduction6223022847600NoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration:Feedback Requested Feedback requestedHL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.Interoperability Need: Pre-population of Research Forms from Electronic Health RecordsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardCDISC Clinical Data Acquisition Standards Harmonization (CDASH)FinalProduction7810510287000NoFreeN/AStandardCDISC Shared Health And Research Electronic Library (SHARE)FinalProduction7810513462000NoFreeN/AImplementation SpecificationIHE-RFD (Retrieve Form for Data Capture)FinalProduction7112011874500NoFreeN/AImplementation Specification IHE Quality, Research, and Public Health Technical Framework Supplement, Structured Data Capture, Trial ImplementationBalloted DraftPilotNoFreeNoImplementation Specification IHE Quality, Research, and Public Health Technical Framework Supplement, Structured Data Capture, Trial ImplementationBalloted DraftPilotNoFreeNoImplementation SpecificationIHE-CRD (Clinical Research Document)Balloted DraftProduction685809969500NoFreeN/AImplementation SpecificationIHE-XUA (Cross-Enterprise User Assertion)FinalProduction781056032500NoFreeN/AImplementation SpecificationIHE-ATNA (Audit Trail and Node Authentication)FinalProduction660407302500NoFreeN/AImplementation SpecificationIHE-DEX (Data Element Exchange)Balloted DraftPilot5905514224000NoFreeN/AImplementation SpecificationHL7 FHIR DSTU 2, Structured Data Capture (SDC) Implementation GuideBalloted DraftPilot7112010096500NoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See IHE projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.Interoperability Need: Integrate Healthcare and Clinical Research by Leveraging EHRs and other Health IT Systems while Preserving FDA’s RequirementsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardIHE- RFD (Retrieve Form for Data Capture)FinalProduction711206604000NoFreeN/AStandardHL7 Clinical Document Architecture (CDA?), Release 2.0, Final EditionFinalProduction6416818448000NoFreeN/AStandardCDISC Clinical Data Acquisition Standards Harmonization (CDASH)FinalProduction6416818089300NoFreeN/AStandardCDISC Operational Data Model (ODM)Final Production7810510160000NoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Stakeholders should review 21CFR11 for more details. See IHE projects in the Interoperability Proving Ground.Feedback requested HL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.Interoperability Need: Integrate Healthcare and Clinical Research by Leveraging EHRs and other Health IT Systems while Preserving FDA’s Requirements TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardCDISC Protocol Representation Model (PRM)FinalProductionNoFreeYesStandardCDISC Study/Trial Design Model (SDM)Final ProductionNoFreeN/AImplementation SpecificationIHE-RPE (Retrieve Protocol for Execution)Balloted DraftProductionNoFreeN/AImplementation SpecificationIHE-CPRC (Clinical Research Process Content)Balloted DraftProductionNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See IHE projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.Interoperability Need: Submit Adverse Event Report from an Electronic Health Record to Drug Safety RegulatorsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityImplementation Specification IHE-RFD (Retrieve Form for Data Capture)FinalProductionNoFreeN/AImplementation SpecificationIHE-DSC (Drug Safety Content)Balloted DraftPilotNoFreeN/AImplementation SpecificationIHE- CPRC (Clinical Research Process Content)Balloted DraftProductionNoFreeN/AStandard CDISC Protocol Representation Model (PRM)FinalProductionNoFreeYesLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See IHE projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.Interoperability Need: Complete Disease Registry Forms and Submit to Reporting Authority (ACC)TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardCDISC Clinical Data Acquisition Standards Harmonization (CDASH)FinalProduction7175513335000NoFreeN/AImplementation Specification IHE-RFD (Retrieve Form for Data Capture)FinalProduction6413518351500NoFreeN/AImplementation Specification HL7 Clinical Document Architecture (CDA?), Release 2.0, Final EditionFinalProduction6413518034000NoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See IHE projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.Interoperability Need: Registering a Clinical TrialTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandardCDISC Clinical Trial Registry (CTR-XML)Balloted DraftPilot6223018097500NoFreeN/AStandardCDISC Operational Data Model (ODM)FinalPilot6223018415000NoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration:Feedback requestedFeedback requestedHL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.II-R: Segmentation of sensitive information Interoperability Need: Document-Level Segmentation of Sensitive Information TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard HL7 Clinical Document Architecture (CDA?), Release 2.0, Final EditionFinalProduction 679452413000NoFreeNoImplementation Specification Consolidated HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1FinalPilotYesFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See CDA projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:(Copied from 2016 ISA) We suggest that the Advisory increase the maturity measures for the normative Consolidated HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 to: Implementation Maturity = Production at header and XDAdoption Level = 61% to 80% adoption Regulated = yes, as it is named in the 2015 Edition Health IT Certification Criterion at § 170.315(b)(7) and § 170.315(b)(8) The rationale for the higher adoption level is that for C-CDA transmission, document level DS4P is required in the C-CDA General Header. We would agree that data segmentation at the section level is still very much at the early pilot stage, but the Interoperability Need does indicate “document-level”. To avoid confusion when indicating a higher adoption level is to include in the Limitations, Dependencies, etc., a clear statement that this is only at the C-CDA General Header level and NOT at the section level.Add to LimitationsSuite of conformance tests developed by ONC DS4P projectAdd to Applicable Security Patterns for Consideration:Access Control systems must ensure that only authorized users are able to access the DS4P Privacy Marking section or any Privacy Annotations that include HCSII-S: Summary care record Interoperability Need: Support a Transition of Care or Referral to Another Health Care Provider TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest 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)Balloted DraftProductionYesFreeYesEmerging Implementation SpecificationHL7 Implementation Guide for CDA? Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), DraftStandard for Trial Use, Release 2.1Balloted DraftPilot Feedback requestedYesFreeNoLimitations, 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.See CDA and CCDA projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:HL7 Comments/suggestions:(Copied from 2016 ISA) HL7 recommends that the ISA include the normative HL7 Privacy Consent Directive CDA IG to enable interoperable and computable consents expressed as structured HL7 privacy and security vocabulary, BPPC, and as XACML policies. This standard is the only specification available for encoding consent rules that can be enforced by data segmentation. The BPPC cannot meet these criteria, and yet is also able to be encapsulated in the Consent Directive CDA as unstructured content, as a Consent URI, as an XACML rule, or as an externally reference document. The HL7 Consent Directive IG enables an interoperable “glide path”, as coined by John Halamka, for trading partners at various levels of maturity to support patient preferences as end user develop capabilities to consume and computably enforce these consent directives. The HL7 Security and CBCC WGs recommend that ONC consider that by including the DS4P in 2015 Edition Health IT Certification Criterion they make it incumbent on § 170.315(b)(7) outbound implementers to be capable of manually or computably transforming patient preferences into security labeling on the outbound CDAs and make it incumbent on § 170.315(b)(8) inbound implementers to parse these preferences into enforcing access control decisions. If the inbound implementer receives unstructured consent directives or references to external location of patient agreed to BPPC consent directive templates, then these implementers have an additional discovery, retrieve, and manually parse these unstructured patient preferences. This does not scale. The only available means for automating the generation and consumption of patient consent directives in CDA based exchanges is to use the HL7 Consent Directive CDA IG. It is also important to note that Data Provenance is very important for mobile health, e.g., for data that flows from mobile devices into EHRs and PHRs. It will be critical to capture where the data came from (e.g., the user, device, and the app) and to understand the data quality. Even the specific level of the software that produced the data may need to be tracked. CDA DPROV may not be the appropriate standard for mobile health if CDA is not the container by which the data is exchanged. There are other standards, such as FHIR Provenance resource, that need to be evaluated. HL7’s Mobile Health WG is currently developing a framework for consumer apps that includes “Data authenticity, Provenance, and Associated Metadata” in its requirements.Interoperability Need: TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardHL7 Implementation Guide for CDA?, Release 2: Consent Directives, Release Final Note in process of being published as NormativeProductionImplemented in Prince George’s County and in other SAMHSA Consent2Share Operational installations.NoFreeYes, SAMHSA Consent2Share has conformance testing toolsLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedAs with any transaction related to contracts, policies, consent directives, access control mechanisms need to be in place to enforce sender’s security, privacy, and trust policies.HL7 Comments/Suggestions:(Copied from ISA) HL7 recommends that the ISA include the HL7 Data Provenance CDA IG Draft Standard for Trial Use at the pilot and lowest adoption level as this is the only available specification that constrains the CDA, C-CDA, and DS4P to ensure that trading partners can establish Provenance policies as to the key metadata needed to establish the authenticity, reliability, and trustworthiness of the CDA content they exchange. HL7 views this as a current and steadily increasing business need as healthcare “consumer” systems deal with the proliferation of copies, extracts, and aggregation of CDA content the WGs anticipate them receiving, and these systems’ need to develop automated “integration” rules such that, e.g., trusted content can be automatically integrated while less reliable content can be manually reviewed or sequestered.Our recommendations are captured in the Advisory table below.Interoperability Need: TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardHL7 Data Provenance CDA IG Draft Standard for Trial Use(official link is challenged, this link can be used internally while we get the right link)Final DSTUPilots – ONC DPROVnoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedApplication of the DPROV IG constraints may enforce inclusion of sensitive information such as the provide type, id, and role, which may disclose protected information. In addition, since the DPROV IG inherits both the C-CDA General Header and the DS4P CDA constraints, the same precautions recommended for DS4P and XD* regarding protected security labels pertains.Section III: Standards and Implementation Specifications for Services III-A: “Push” Exchange Interoperability Need: An Unsolicited “Push” of Clinical Health Information to a Known Destination Between Individuals and SystemsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool Availability1- StandardApplicability Statement for Secure Health Transport v1.1 (“Direct”)FinalProduction YesFreeYes2 - Emerging StandardApplicability Statement for Secure Health Transport v1.2FinalProductionYesFreeYes1, 2, 3 - Implementation Specification IG for Direct Edge ProtocolsFinalProductionYesFreeYes1, 2 - Implementation Specification IG for Delivery Notification in DirectFinalProductionYesFreeYes1, 2, 3 - Implementation SpecificationXDR and XDM for Direct Messaging SpecificationFinalProductionYesFreeYes3 – StandardIHE-XDR (Cross-Enterprise Document Reliable Interchange)FinalProductionYesFreeYes4 - Emerging StandardFast Healthcare Interoperability Resources (FHIR) DSTU 2Balloted DraftPilotcentercenterNoFreeNo3, 4 - Emerging Implementation Specification IHE-MHD (Mobile Access to Health Documents Balloted DraftPilot NoFreeNoLimitations, 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. The leading trust communities to enable communication amongst the most users include DirectTrust (for provider messaging and consumer-mediated exchange) and NATE (for consumer-mediated exchange).The reference to FHIR for this interoperability need is in relation to the transport services that are conformant to the “RESTful FHIR API”The MHD supplement is based on FHIR DSTU1.1. The IHE MHD committee is currently working to update the MHD profile and planning to release it to implementers in first quarter calendar year 2016.See Direct, FHIR, and IHE projects in the Interoperability Proving Ground.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 messageSecure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.HL7 Comments/suggestions:(Copied from 2016 ISA) Add the following to the Applicable Security Patterns for Consideration:Patient Consent Information - Identifies the patient consent information that:May be required to authorize any exchange of patient information May be required to authorized access and use of patient information May be required to be sent along with disclosed patient information to advise the receiver about policies to which end users must comply Security Labeling – the health information is labeled with security metadata necessary for access control by the end user.(Copied from 2016 ISA) The adoption level for Direct raises a question whether this reflects the adoption by software developers to have it available, or the actual use. If the intent is to indicate adoption by software developers we would agree with this assertion, but if it is to reflect actual use we understand this to be lower. This variance should be clarified. (Copied from 2016 ISA) We suggest that where a specification is not (yet) formally owned by an SDO to maintain such specification that it is highlighted. Specifically, we understand that Direct is not yet formally owned by a particular organization to ensure ongoing maintenance and updates. This should not disqualify the specification from inclusion, but does contribute to the transparency considering the risks around sustainability, governance, and other maintenance and updates.Interoperability Need: An Unsolicited “Push” of Clinical Health Information to a Known Destination Between SystemsTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool Availability1- Standard SOAP-Based Secure Transport Requirements Traceability Matrix (RTM) version 1.0 specificationFinalProduction YesFreeYes1- StandardApplicability Statement for Secure Health Transport v1.1 (“Direct”)FinalProduction YesFreeYes2 - Emerging StandardApplicability Statement for Secure Health Transport v1.2FinalProductionYesFreeYes2- Implementation Specification IHE-XDR (Cross-Enterprise Document Reliable Interchange)FinalProduction NoFreeYes1 - Implementation Specification NwHIN Specification: Messaging PlatformFinalProduction NoFreeNo1- Implementation Specification NwHIN Specification: Authorization FrameworkFinalProduction 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.“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. The leading trust communities to enable communication amongst the most users include DirectTrust (for provider messaging and consumer-mediated exchange) and NATE (for consumer-mediated exchange).See Direct and IHE projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:Interoperability Need: Push Communication of Vital Signs from Medical Devices TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard ISO/IEEE 11073 Health informatics - Medical / health device communication standardsFinalPilotNo$NoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: ISO/IEEE 11073 is a suite of standards for various medical devices. Feedback requestedHL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.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 LevelFederally RequiredCostTest Tool Availability1- Standard HL7 Version 3 Standard: Decision Support Service, Release 2.Balloted DraftPilotNoFreeNo1- Implementation Specification HL7 Implementation Guide: Decision Support Service, Release 1.1, US Realm, DraftStandard for Trial Use Balloted DraftPilotNoFreeNo1- Standard QICore/QuICK, DraftStandard for Trial UseBalloted DraftPilotNoFreeNo1- Standard CQL, Draft Standard for Trial UseBalloted DraftPilotNoFreeNo1- Standard CDS on FHIR, Draft Standard for Trial UseBalloted DraftPilotNoFreeNo2-Emerging Implementation Specification IHE- GAO (Guideline Appropriate Ordering)Balloted DraftPilotNoFreeNo3-Emerging Implementation SpecificationIHE-CDS-OAT (Clinical Decision Support – Order Appropriateness Tracking)Balloted DraftPilotNoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See IHE projects in the Interoperability Proving Ground.Feedback requestedHL7 Comments/suggestions:(Copied from 2016 ISA) We should note that the OAT standard is not appropriate to be referenced in Section III as it is an HL7 V2, message based implementation profile addressing the communication of relevant AUC data from the ordering provider through the imaging center to the revenue management system that generates a claim. Rather it should be in section II perhaps under Imaging.(Copied from 2016 ISA) We suggest that HL7 V3 Standard: Decision Support Service, Release 2 should be marked Production for Implementation Maturity production – there are several instances of production-level uses of this standard, including for OpenCDS (), the Immunization Calculation Engine (ICE), and the Veterans Health Administration. Consequently, we suggest marking the Adoption Level at least medium-low.(Copied from 2016 ISA) We suggest replacing the IHE-GAO specification with the HL7 GAO FHIR specification, which underwent draft standard balloting in January 2016 and is undergoing ballot reconciliation, thus representing the most current version. This specification will be implemented as a “knowledge module” of the HL7 Clinical Decision Support on FHIR specification.(Copied from 2016 ISA) We note that, as CMS comes out with clear guidance on exactly what data is to be communicated from the AUC mechanism through the ordering provider to the imaging center for the claim to CMS, that both the GAO and CDS-OAT profiles need to be updated to reflect that clarification.Interoperability 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 LevelFederally RequiredCostTest Tool Availability1-Standard HL7 Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2.FinalProduction centercenterYesFreeNo1-Implementation Specification HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1.FinalProduction YesFreeNo1-Implementation Specification HL7 Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton), Release 4.FinalProduction YesFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedHL7 Comments/suggestions:III-C: Image Exchange Interoperability Need: Exchanging Imaging Documents Within a Specific Health Information Exchange Domain TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool Availability1-Implementation Specification IHE Cross Enterprise Document Sharing for Images (XDS-I.b)FinalPilotNoFreeYes1,2-Implementation Specification IHE-PDQ (Patient Demographic Query)FinalProduction NoFreeNo1,2-Implementation Specification IHE-PIX (Patient Identifier Cross-Reference)FinalProductionNoFreeNo2-Emerging Implementation Specification IHE – MHD-I (Mobile Access to Health Documents for Imaging)Balloted 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.See IHE projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:Interoperability Need: Exchanging Imaging Documents Outside a Specific Health Information Exchange DomainTypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityImplementation Specification IHE Cross Community Access for Imaging (XCA-I)FinalPilotNoFreeYesImplementation Specifications the combination of IHE-XCPD (Cross-Community Patient Discovery) and IHE-PIX (Patient Identifier Cross-Reference)FinalProduction 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.See IHE projects in the Interoperability Proving Ground.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos)..HL7 Comments/suggestions:III-D: Healthcare Directory, Provider Directory Interoperability Need: Listing of Providers for Access by Potential Exchange Partners TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool Availability1-Implementation Specification IHE IT Infrastructure Technical Framework Supplement, Healthcare Provider Directory (HPD), Trial ImplementationBalloted DraftPilotcentercenterNoFreeYes2-Emerging StandardFast Healthcare Interoperability Resources (FHIR), DSTU 2Balloted DraftPilot641358953500NoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The IHE IT Infrastructure Technical Framework Supplement, Healthcare Provider Directory (HPD), Trial Implementation was proposed, but not adopted for CEHRT 2015. The Health IT community has recognized the value of the underlying data elements and structure of that standard. The standard has met with limited adoption due to other concerns with the API. Work is underway in FHIR workgroups to reconcile FHIR resources with the data requirements of Provider/Healthcare Directories in order to offer a Healthcare Directory resource as part of FHIR. Resources are in various stages of maturity. Please refer to the FHIR website for updates on specific profiles and their progress.See IHE and FHIR projects in the Interoperability Proving GroundFeedback requestedHL7 Comments/suggestions:III-E: Public Health ExchangeInteroperability Need: Query/Response for Immunization Reporting and Exchange TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityImplementation Specification HYPERLINK "" EHR-IIS Interoperability Enhancement Project Transport Layer Protocol Recommendation Formal Specification, Version 1.2FinalProductioncentercenterNoFreeNoImplementation SpecificationIIS Standard WSDLFinalProduction698507429500NoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedHL7 Comments/suggestions:Was included in projected section of 2016 ISA. Highlighting compares with what was projected.III-F: Publish and Subscribe Interoperability Need: Publish and Subscribe Message Exchange TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool Availability1-Implementation Specification NwHIN Specification: Health Information Event Messaging Production SpecificationFinalProduction 641356794500NoFreeNo2-Emerging Implementation Specification IHE Document Metadata Subscription (DSUB), Trial Implementation Balloted DraftPilot NoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See IHE projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).Assertion Builder – define processing logic for identity, authorization and attribute statements.User Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:III-G: Query Interoperability Need: Query for Documents Within a Specific Health Information Exchange Domain TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool Availability1-Implementation Specification IHE-XDS (Cross-enterprise document sharing)FinalProduction NoFreeYes1,2-Implementation Specification IHE-PDQ (Patient Demographic Query)FinalProduction NoFreeYes1,2-Implementation Specification IHE-PIX (Patient Identifier Cross-Reference)FinalProductionNoFreeYes2- Emerging Implementation Specification IHE – MHD (Mobile Access to Health Documents)Balloted 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.The MHD supplement is based on FHIR DSTU1.1. The IHE MHD committee is currently working to update the MHD profile and planning to release it to implementers in first quarter calendar year 2016.See IHE projects in the Interoperability Proving Ground.Secure Communication – create a secure channel for client-to- serve and server-to-server communication.Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.Authentication Enforcer – centralized authentication processes.Authorization Enforcer – specified policies access control.Credential Tokenizer – encapsulate credentials as a security token for reuse? (e.g., – SAML, Kerberos).Message Interceptor Gateway – provide a single entry point solution for centralization of security enforcement for incoming and outgoing XML WebService messages.System Authentication - The information and process necessary to authenticate the systems involvedUser Authentication – The identity information and process necessary verify the user’s identityUser Role – identifies the role asserted by the individual initiating the transaction.Purpose of Use - Identifies the purpose for the transaction.Patient Consent Information - Identifies the patient consent information that:May be required to authorize any exchange of patient informationMay be required to authorized access and use of patient informationMay be required to be sent along with disclosed patient information toadvise the receiver about policies to which end users must complySecurity Labeling – the health information is labeled with security metadataHL7 Comments/suggestions:Interoperability Need: Query for Documents Outside a Specific Health Information Exchange Domain TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool Availability1-Implementation SpecificationIHE-XCA (Cross-Community Access) FinalProduction NoFreeNoImplementation Specificationsthe combination of IHE-XCPD (Cross-Community Patient Discovery) and IHE-PIX (Patient Identifier Cross-Reference)FinalProduction 80645-5397500NoFreeNoImplementation SpecificationNwHIN Specification: Patient DiscoveryFinalProduction 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.See IHE projects in the Interoperability Proving Ground.System Authentication - The information and process necessary to authenticate the systems involved User Authentication – The information and process necessary to authenticate the end userUser Details - identifies the end user who is accessing the dataUser Role - identifies the roles and clearances asserted by the individual initiating the transaction for purposes of authorization. E.g., the system must verify the initiator’s claims and match them against the security labels for the functionalities that the user attempts to initiate and the objects the user attempts to access.Purpose of Use - Identifies the purpose for the transaction, and for the purposes for which the end user intends to use the accessed objectsPatient Consent Information - Identifies the patient consent information that may be required before data can be accessed.May be required to authorize any exchange of patient informationMay be required to authorized access and use of patient informationMay be required to be sent along with disclosed patient information toadvise the receiver about policies to which end users must complyQuery Request ID - Query requesting application assigns a unique identifier for each query request in order to match the response to the original query.Security Labeling – the health information is labeled with security metadata necessary for access control by the end user.HL7 Comments/suggestions:Should include Carequality Document Query IG.Can we offer Commonwell standards? I.e., are they open for use, even if not part of Commonwell?Interoperability Need: Data Element Based Query for Clinical Health Information TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityStandard Fast Healthcare Interoperability Resources (FHIR), DSTU 2 Balloted DraftPilot3810063500NoFreeNoEmerging StandardHL7 FHIR STU 3In DevelopmentPilotN/ANoFreeNoLimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: The following URL provides links to relevant FHIR resources FHIR Resources are in various stages of maturity. Please refer to the FHIR website for updates on specific profiles and their progress.See FHIR projects in the Interoperability Proving Ground.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 transaction.Purpose of Use - Identifies the purpose for the transaction.Patient Consent Information - Identifies the patient consent information that may be required before data can be accessed.May be required to authorize any exchange of patient informationMay be required to authorized access and use of patient informationMay be required to be sent along with disclosed patient information toadvise the receiver about policies to which end users must complySecurity Labeling – the health information is labeled with security metadata necessary for access control by the end user.Query Request ID - Query requesting application assigns a unique identifier for each query request in order to match the response to the original query.HL7 Comments/suggestions:III-H: Resource Location Interoperability Need: Resource Location Within the US TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelFederally RequiredCostTest Tool AvailabilityImplementation Specification IHE IT Infrastructure Technical Framework Supplement, Care Services Discovery (CSD), Trial ImplementationBalloted DraftPilotcentercenterNoFreeYes Limitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: See IHE projects in the Interoperability Proving Ground.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 transaction.Purpose of Use - Identifies the purpose for the transaction.HL7 Comments/suggestions:HL7 Comments/Suggestions:(Copied from 2016 ISA) HL7 recommends that the ISA include the HL7 PASS Access Control Service Functional Model, which passed the October 2015 normative ballot after a 2 year DSTU period and is now undergoing ballot reconciliation and expected to pass. This standard specifies the access control functionalities required for interoperable exchange of health information including conveyance of Obligations to which end users much comply, e.g., to support data segmentation. Our recommendations are captured in the proposed table below.TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardFinalPilotNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedHL7 Comments/Suggestions:(Copied from 2016 ISA) HL7 recommends that the Advisory include the normative HL7 PASS Security Labeling Service Functional Model, which specifies the technology agnostic services required to implement an Access Control System capable of segmenting health information both for access and use by users within the trust domain and for disclosure to end users outside of a trust domain. HL7 considers SLS to be widely adopted because it describes current Access Control processes that have a long history of use. Currently many Access Control Systems apply Confidentiality and Purpose of Use security labels in XD* metadata for Exchange and Direct XDR/XDM or as values for the Confidentiality attributes on all CDA Headers and Sections. Where Confidentiality or Purpose of Use security labels are used to enforce the policies represented by these labels, especially jurisdictional laws such as 42 CFR Part 2, HITECH Self-pay, and Title 38 Section 7332 or state laws more stringent than HIPAA.Our recommendations are captured in the proposed table below.TypeStandard/Implementation SpecificationStandards Process MaturityImplementation MaturityAdoption LevelRegulatedCostTest Tool AvailabilityStandardHL7 PASS Security Labeling Service Functional ModelFinalProductionNoFreeN/ALimitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration: Feedback requestedFeedback requestedSection IV: Questions and Requests for Stakeholder FeedbackAs with the previous Interoperability Standards Advisories (ISA), posing questions has served as a valuable way to prompt continued dialogue with stakeholders to improve the ISA. Your feedback on the questions posed below is critical and we encourage answers to be submitted as part of the current public comment process. GeneralFor each standard and implementation specification there are six assessment characteristics, for which detailed information has been received and integrated. However, some gaps remain. Please help complete information that is missing or noted “feedback requested . Additionally, assessing the adoption and maturity of standards is an ongoing process, so please continue to provide feedback if you believe something has changed or is not correct.The table beneath the standards and implementation specifications includes limitations, dependencies, and preconditions. Given the enhancements made, please comment on accuracy and completeness and where information gaps remain, forward applicable content. For the Implementation Maturity characteristic for the standards and implementation specifications, ONC plans to publish a link, where available, to published maturity assessments based on known published criteria. Please help identify any publications that are publically available and provide the hypertext links to those resources.Answer”For the Adoption Level characteristic for the standards and implementation specifications, ONC plans to publish reference annotations or links to publicly available documentation known about adoption levels for listed standards. Please help identify any publications that are publicly available and provide the hypertext links to those resources.Answer:For the Test Tool Availability characteristic for the standards and implementation specifications, ONC plans to publish references, where available, a to the publicly available test tool. Please help identify any publicly available test tools.Answer:Section I: Vocabulary/Code SetWithin the Section I tables, Value Sets have been selected to substitute for what otherwise references Security Patterns in Sections II and III. Please review and provide feedback on placement, accuracy and the completeness of the selected value sets. HL7 Answer: (Specifically focusing on completeness of the set of standards)For subsection I-D: Functional Status/Disability, the Health Information Technology Standards Committee recommends using SNOMED?/LOINC? observation paring for this interoperability need. Do you support this approach? HL7 Answer:For subsection I-H: Industry and Occupation, there continues to be varied opinion on the standards or implementation specifications to be sited in these areas. Please review and provide feedback on what should be included and/or whether these areas should be removed.HL7 Answer:For subsection I-R: Sexual Orientation and Gender Identity, Interoperability Need: Representing patient sex (at birth), what are the appropriate genetic identifiers or gender determinants (e.g., gonadal sex, karyotype sex) for potential inclusion in the ISA.HL7 Answer:For subsection I-S: Social Determinants please help identify the adoption level of LOINC? for each of the Interoperability Needs.HL7 Answer:Are there additional psychosocial Interoperability Needs with corresponding standards that should be included in the ISA?HL7 Answer:For subsection I-T: Tobacco Use (Smoking Status), because of the current limitations, what surveys, instruments or tools are being used to collect tobacco use information that is more complete that the current coding methodologies?HL7 Answer:Section II: Content / StructureFor the existing interoperability need, “representing clinical health information as a resource”, public comments expressed this may not be the best language to describe this area. Please provide feedback on whether or not this is correct or recommend alternative language that better describes this interoperability need. HL7 Answer:Opinions vary in the way (messaging vs. transport) the ISA should represent FHIR. Please review and provide feedback on the manner FHIR should be represented.HL7 Answer:Appendix I: Sources of Security StandardsAre there other authoritative sources for Security Standards that should be included in Appendix I?HL7 Answer:Appendix I – Sources of Security Standards and Security Patterns[See Question 15, Section IV]In this Draft 2017 Interoperability Standards Advisory, a structure to capture necessary security patterns associated with interoperability needs is represented (see Section III-A and III-F for examples). 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.Security Pattern Catalog : 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): ISO IT Security techniques – evaluation criteria for IT security, ISO/EC 15408 series: 21089:2004(en) -Health informatics — Trusted end-to-end information flows: Special Publication: 800-63-2. Electronic Authentication Guideline. August 2013. PUB 202. SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions. August 2015. SP 1800-a-e. Securing Electronic Health Records on Mobile Devices. July 2015. ExecSummary.pdf and Fair Information Practice Principles (FIPPs). Security regulations that are specific to healthcare: Special Publication 800-30, rev 1:?? OpenID Connect 1.0 2.0 Access (UMA) Profile of OAuth 2.0 - Cybersecurity Standards:? - Consistent Time – Audit Trail and Node Authentication – Enterprise User Authentication - Cross-Enterprise User Assertion (XUA) (XUA)IHE – Document Digital Signature – Basic Patient Privacy Consents -- – Document Encryption – Access Control II - Revision HistorySummary Level Description of Changes between the 2016 ISA and the Draft 2017 ISA ISA AreaSummary Level Description of Revision HistoryRevision History, ExpandedTable of ContentsMinor changes were made. Additions were made to the Table of Contents reflecting additions of subsections, removal of a section, etc.Executive SummaryThis section was bined into a new section called “Introduction to the Draft 2017 Interoperability Standards Advisory”Introduction to the Draft 2017 Interoperability Standards AdvisoryNew information added to the 2017 Draft ISA is explained.This section describes the major differences between 2016 and 2017.Discussion on how ONC is placing the ISA online and making it more interactiveDescribes the move away from the concept of “Best Available”Describes the addition of “Applicable Starter Sets.”.Discussion about observation and observation values as now reflected in the ISA.In the Limitations, Dependencies, and Preconditions for Consideration field, there will now be links to the Interoperability Proving Ground that will point to projects using the referenced standard(s).ScopeEnhanced the description of the scope. Content from other sections were moved into this section.PurposeAdditional information was added.A discussion about anticipated use of the ISA by stakeholders and how it relates to regulation.The Draft 2016 Interoperability Standards AdvisoryThis section was removed. Contents of this section were moved into other areas.ISA StructureName changed from Sections of the Sections. Updates to the content were made.Changes were made in the following descriptions of the characteristics”Standards Process Maturity - added “In Development”Implementation Maturity - added links to published maturity assessments to known published criteria about that standards (if known and/or available)Adoption Levels - links will be provided, when available, of known documentation about adoption levels for the listed standards or implementation specificationsCosts – Where known, estimated costs for access will be given.Test Tool Available – Where available, at link will be provided to the publicly available test tools.Projected Additions to the ISAThis section was removed for the Draft 2017 ISA. Likely will be used for the Final 2017 ISA.Advanced the Projected Additions in 2016 ISA into the appropriate sections and subsections in the Draft 2017 ISA.Questions and Requests for Stakeholder FeedbackThe questions were updated.The questions offered, were structured to solicit feedback on changes made to the Draft 2017 ISA and to assist in addressing recommendations where disposition is pending. These are found within Section IV.Revision HistoryUpdates were made to the Revision History content as needed. Routine updates to the Revision History content.Responses to Comments Requiring Additional ConsiderationAn appendix has been added to indicate those comments unable to be represented in the current Draft 2017 ISA released, e.g., more time and/or consideration needed. The current state of the Draft 2017 ISA reflects substantive amount of the Public Comments yet several remain, e.g., more exploration required, more time to properly address; potential redirection to SDOs, etc.Additions/Enhancements/Deletions by Sub-section Between the 2016 ISA and the Draft 2017 ISA Section DescriptionAddedEnhancedDeletedI-A: AllergiesUnder the Interoperability Need: “Representing patient allergic reactions” added a standard, Applicable Value Set(s) and Starter Set(s), and clarifying notes.AddedI-A: AllergiesUnder the Interoperability Need: “Representing patient allergens: food substances” several applicable Value Sets and Starter Sets were added.EnhancedI-B Encounter DiagnosisUnder the Interoperability Need: “Representing patient medical encounter diagnosis” additional information was provided in the Limitations, Dependencies, and Preconditions for Considerations field.EnhancedI-B: Encounter DiagnosisUnder the Interoperability Need: “Representing patient medical encounter diagnosis” a starter set was provided Applicable Value Set(s) and Starter Set(s) field.EnhancedI-B: Encounter DiagnosisUnder the Interoperability Need: “Representing patient dental encounter diagnosis” the standard SNOWMED was deleted.DeletedI-B: Encounter DiagnosisUnder the Interoperability Need: “Representing patient dental encounter diagnosis” the standard SNOWDENT was added. AddedI-C: Family Health HistoryAn additional Interoperability Need: ” Representing patient family health history observations” and corresponding standard was added. AddedI-D: Functional Status/DisabilityUnder the Interoperability Need: Representing patient functional status and/or disability a note in the Limitations, Dependencies, and Preconditions for Considerations field was added.EnhancedI-I: Lab testsUnder the Interoperability Need: “Representing laboratory tests” some additional information was provided in the Limitations, Dependencies, and Preconditions for Considerations field.EnhancedI-K: Numerical References & ValuesUnder the Interoperability Need: “Representing units of measure (for use with numerical references and values)” some edits were made to the information in the Limitations, Dependencies, and Preconditions for Considerations field.EnhancedI-L: Nursing“Nursing” subsection was added.AddedI-L: NursingFive interoperability needs along with corresponding standards and other information was added.AddedI-M: Patient Clinical “Problems” (e.g., conditions)Under the Interoperability Need: “Representing patient clinical “problems” (i.e., conditions)” LOINC? was added along with the Applicable Value Sets and Starter Sets and information in the Limitations, Dependencies, and Preconditions for Considerations field.AddedI-O: ProceduresUnder Interoperability Need “Representing medical procedures performed” additional information was added in the Limitations, Dependencies, and Preconditions for Considerations field.EnhancedI-P: Race and EthnicityAdditional Applicable Value Sets were given.EnhancedI-Q: ResearchAdded the subsection “Research” with corresponding Interoperability Need, standards, implementation specifications, and other informationAddedI-R: Sexual Orientation and Gender IdentityThe subsection name had changed.EnhancedI-R: Gender Identity, Sex and Sexual Orientation LOINC? was added to three Interoperability Needsalong with the Applicable Value Set(s) and Starter Set(s) and other notes in the Limitations, Dependencies, and Preconditions for Considerations field.AddedI-S: Social DeterminantsAdded the subsection “Social Determinants” with corresponding Interoperability Needs, standards and other information.AddedI-T: Tobacco Use (Smoking Status)LOINC? standard was added along with information in the Limitations, Dependencies, and Preconditions for Considerations field and the Applicable Value Set(s) and Starter Set(s).AddedII-A: Admission, Discharge, and TransferAdded Interoperability Need “Admission, discharge and/or transfer status to the servicing pharmacy” with corresponding standard.AddedII-B: Care PlanAdded the Interoperability Need: “Establishing the authenticity, reliability, and trustworthiness of content between trading partners” with corresponding standard and related information.AddedII-C: Clinical Decision SupportAdded two additional Interoperability Needs with corresponding Implementation Specifications and other related information.AddedII-D: Clinical Quality MeasureCreated a new subsection “Clinical Quality Measure” with one Interoperability Need and corresponding standards, implementation specifications and related information.AddedII-E: Clinical Quality ReportingUnder the Interoperability Need: “Reporting Aggregate Quality Data to Federal Quality Reporting Initiatives” added an Emerging Implementation Specification.AddedII-F: Data ProvenanceAdded subsection “Data Provenance” with an Interoperability Need, corresponding standard and other related information.AddedII-H: Electronic PrescribingAdded three Interoperability Needs with related standards and other information.AddedII-H: Electronic PrescribingModified the names of some of the original Interoperability Needs and made some edits to the information. EnhancedII-I: Family Health HistoryAdded one Interoperability Need along with corresponding standard and other related information.AddedII-J: ImagesAdded one Interoperability Need along with corresponding standard and other related information. AddedII-L: Medical Device Communication to Other Information Systems/TechnologiesCreated a new subsection II-J: Medical Device Communication to Other Information Systems/Technologies with an Interoperability Need, corresponding standard and other related information. AddedII-Q: ResearchAdded the subsection “Research” along with seven Interoperability Needs including corresponding standards, implementation specifications, and other related informationAddedIII-A: “Push” ExchangeAdded an Interoperability Need with corresponding standard and other related information.AddedIII-B: Clinical Decision Support ServicesUnder the Interoperability Need; “Providing patient-specific assessments and recommendations based on patient data for clinical decision support” three standards were added.AddedIII-D: Healthcare Directory, Provider Directory Name of subsection changed. EnhancedIII-D: Healthcare Directory, Provider Directory Additional information was added to the Limitations, Dependencies, and Preconditions for Considerations field.EnhancedIII-E: Public Health ExchangeNew subsection was added along with an Interoperability Need, corresponding standards and other related information.EnhancedOld IV: Projected Additions to ISAMost of the proposed additions in the 2016 ISA were added to their respective areas in this draft and the section was deleted from the Draft 2017 ISA. DeletedIV: Questions and Requests for Stakeholder FeedbackQuestions have been updated.EnhancedAppendix IName changed and also sources of Security Standards and Security Patterns were updated.AddedAppendix IIRevision History updated.AddedAppendix IIIUpdated the Comments Regarding Additional Considerations.AddedAppendix III – Responses to Comments Requiring Additional Consideration ONC has reviewed all of the comments that were submitted as part of the public comments process and has incorporated many of the recommendations into this current version. In some cases, feedback provided may have been out of scope of the ISA or where additional exploration may be needed for consideration in future ISA drafts. To acknowledge these areas, and recognize the time and effort required for stakeholders to submit thoughtful public comments,?ONC has attempted to address as many of these recommendations as possible in the statements below. What is provided reflects a mix of new and pending considerations received as part of the 2016 ISA and 2017 ISA development process. Overarching Several comments were received during the 2016 and 2017 ISA review around inclusion of EHR Functional Model elements within the ISA. ONC will explore, with stakeholder and Health IT Standards Committee feedback whether or not this is feasible and if these should be included in future updates.As described in the executive summary, the scope of the ISA has been limited to clinical health IT interoperability needs. As we work to update the ISA, we will explore adding various purposes to its scope. At this time, payment and administrative standards will not be included.? CMS maintains a list of standards for this purpose that can be referenced: , the ISA does not attempt to represent how these standards can help support providers in meeting legal requirements for maintaining patient health records for their business needs.Several commenters suggested addition of use case development and management of information flows. Doing so would not be in alignment with the purpose of the ISA and is not addressed. We received requests to include standards related to transfer on pregnancy, birth information, newborn nursery, newborn screening, and related topics.? ONC will continue to explore inclusion of these standards for future ISA updates. We also received requests to include standards for preventive health schedules. ?ONC may need additional information in this area, but will explore inclusion of these in future ISA updates. Requests were made to distinguish between “eligible providers” for Meaningful Use and “non-eligible providers”. The ISA focuses on the representation of standards and implementation specifications that can be used to achieve interoperability needs.Specific requests were received during the 2016 and 2017 ISA review regarding variance in adoption level for specific settings. We will continue to work with these organizations to evolve the way adoption levels are reflected and substantiated. The ISA does not directly address primary and secondary use but is beginning to add standards related to research interoperability needs.The ISA does not currently address “end-to-end chain of trust”, health record capture, retention, auditing, or other standards associated with this concept.? Similar to functional models, ONC will explore inclusion in future ISA updates. ONC does not plan to provide more granularity on implementation maturity levels at this time. Nor does ONC intend to provide a direct assessment as to the “readiness” of standards to be used within the ISA. Instead, the current characteristics are provided to allow for stakeholders to make their own informed decisions as to whether a standard or implementation specification will meet their needs. ONC does not currently have the capacity to publish testing results surrounding how well standards support interoperability needs identified in the ISA. ONC encourages other organizations to build upon the information provided in the ISA to provide additional value such as this. ?ONC does not intend to provide contact information for each of the SDOs with standards referenced within the ISA. However, a URL for each standard or implementation specification is provided, which may provide contact information or at least a link to the SDO home page whereby stakeholders could contact the SDO if needed. ONC has received and is pursuing interests to enhance the distinction of certain information as well as enhanced capability. Representative interests include:Ability to filter standards by those required in regulation.Ability to filter standards by any of the characteristics ONC captures on them.Ability to add an “Accredited SDO” characteristic to each standard.? Also, an “Audited Standard” characteristic.Addition of characteristics showing the extent standards are backwards compatible to the previous versions and also showing how compatible standards are to comparable standards.Addition of Privacy Patterns and StandardsAddition of specific FHIR Profiles for specific interoperability needsAbility to provide detailed criteria related to how we break the tie between two standards. Additionally, showing the score between the two standards.? Making the ISA not only the platform for listing the standards but also getting feedback on them as far as adoption levels, ease of implementation, links to successful pilots or implementation, and other information (part of what is driving the interactive, dynamic ISA we are developing for December) Section IONC will continue to monitor areas where a known standard has not yet become evident (e.g.., industry and occupation, and functioning status/disability, etc.) and will attempt to include relevant standards in future ISA updates. Section IIONC will consider adding implementation guides, such a best practices for documenting referrals to community resources, if deemed appropriate, in future ISA updates. ONC will follow progress on projects related to care planning, and include resulting standards and implementation specifications in future ISA updates. ONC will continue to monitor industry activities surrounding genomic standards and current developments in FHIR profiles in this area. We will include them in future ISA updates as appropriate. ONC received comments around the IHE Radiology Domain’s Suite of Profiles, but at this time did not have enough information to warrant inclusion for many of them. ONC will continue to explore inclusion for future ISA updates.A request was received regarding adding Nutrition/Diet Orders and other related dietary implementation information. ONC will analyze for inclusion in future ISA updates.A request was received regarding inclusion of “legacy data standards”. ONC will continue to explore inclusion of this for future ISA updates.ONC will consider, for future ISA updates, adding “Privacy Patterns for Consideration”, but do not have sufficient information to provide these at this time. Section III:N/A ................
................

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

Google Online Preview   Download