Questions and Requests for Stakeholder Feedback

Comment

HL7 Comments to ONC on Proposed 2018 ISA

Health Level Seven (HL7) International welcomes the opportunity to submit comments related to the ONC Proposed 2018 Interoperability Standards Advisory (ISA). 

We appreciate ONC’s continued progress forward with each subsequent ISA edition and the forum to provide input to the Interoperability Standards Advisory in preparation of the 2018 ISA “Reference Edition”.  Based on input from HL7’s diverse Work Groups we offer: general considerations, responses to the questions ONC specifically raised, as well as detailed suggestions on both a number of already documented interoperability needs and additional interoperability needs.

HL7 ONC 2018 ISA Input - FINAL.pdf

HIMSS Response to ONC Proposed 2018 ISA

On behalf of the Healthcare Information and Management Systems Society (HIMSS), we are pleased to provide written comments to the Office of the National Coordinator for Health Information Technology (ONC) in response to their Request for Stakeholder Feedback to inform the creation of the 2018 Interoperability Standards Advisory (ISA). HIMSS appreciates the opportunity to leverage our members’ expertise in commenting on the Standards Advisory, and we look forward to continuing our dialogue with ONC on identifying, assessing, and determining the best available interoperability standards and implementation specifications. We feel that this effort will provide the necessary foundation for more rapidly advancing interoperability in our country.

HIMSS Response to ISA Request for Feedback_Nov 20 2017 FINAL.pdf

CAQH CORE Comments to ONC to 2018 ISA

Thank you for the opportunity to provide input for the 2018 Interoperability Standards Advisory (ISA). CAQH CORE appreciates that the ISA includes a description of standards, implementation specifications, operating rules and other utilities that support interoperability. Inclusion of Section V. Administrative Standards and Implementation Specifications in the 2018 ISA is especially welcome, as the convergence of administrative and clinical data is becoming increasingly important in managing both the cost and quality of healthcare.

CAQH CORE ISA Comment Letter 11.20.17.pdf

AHIMA Comments to ONC Proposed 2018 ISA

On behalf of the American Health Information Management Association (AHIMA), I am pleased to submit comments related to the ONC Proposed 2018 Interoperability Standards Advisory (ISA).

AHIMA_Comments-ONC2017InteropStdsAdvisory FINAL.pdf

AHIMA Comments to ONC Proposed 2018 ISA

On behalf of the American Health Information Management Association (AHIMA), I am pleased to submit comments related to the ONC Proposed 2018 Interoperability Standards Advisory (ISA).

AHIMA_Comments-ONC2017InteropStdsAdvisory FINAL.pdf

AHIMA Comments to ONC Proposed 2018 ISA

On behalf of the American Health Information Management Association (AHIMA), I am pleased to submit comments related to the ONC Proposed 2018 Interoperability Standards Advisory (ISA).

AHIMA_Comments-ONC2017InteropStdsAdvisory FINAL.pdf

EHR Association Comments to 2018 ISA

On behalf of the more than 30 members of the Electronic Health Record Association (EHRA), we are pleased to offer our input on the Interoperability Standards Advisory (ISA).

EHRA members serve the vast majority of hospitals and ambulatory care organizations that use electronic health records (EHRs) and other health information technology to deliver high quality, efficient care to their patients. The Association operates on the premise that the rapid, widespread adoption of health IT has and will continue to help improve the quality of patient care as well as the productivity and sustainability of the healthcare system.

We look forward to continuing to work with ONC and other stakeholders to advance interoperability and support patient care through the best use of electronic health records and other health information technology.

EHR Association Comments to 2018 Interoperability Standards Advisory.pdf

HIMSS Response to 2017 ISA Section VI Questions 3-7 and 16

The Healthcare Information and Management Systems Society (HIMSS) is pleased to submit these comments for consideration by ONC to update the Interoperability Standards Advisory (ISA). These comments are one set in a series of comments that HIMSS has provided on the content in the new web-based version of the ISA. For more information on previous comments, please visit the HIMSS website.

Please find comments below as related to specific questions outlined in the ISA’s Section VI.

In Questions 3-7 of Section VI, ONC requests feedback on the six characteristics for the standards listed in the Interoperability Needs throughout the ISA. Below is feedback HIMSS has provided on characteristics for some of the Interoperability Needs and related standards. The following comments are recommendations for information to include for Limitations/Dependencies/Preconditions and/or Applicable Value Sets for a variety of Interoperability Needs.

Feedback on I-A: Representing Patient Allergies and Intolerances; Environmental Substances: ONC requested feedback on the adoption level of Unique Ingredient Identifier (UNII) for this Interoperability Need. HIMSS suggests assigning an adoption level of 4 as seen on the representation of Food Substances Interoperability Need. UNII has been included in specifications since HITSP and is listed in C-CDA as an option for representing substances.

Feedback on I-F: Representing Imaging Diagnostics, Interventions and Procedures: For Applicable Value Sets, HIMSS suggests the creation of procedure-specific value sets for LOINC, organized by domains, to be included in this section.

Feedback on I-O: Representing Medical Procedures Performed: HIMSS suggests the creation of procedure-specific value sets for SNOMED CT codes.

Feedback on I-U: Defining a Globally Unique Device Identifier: HIMSS does not believe that an identifier such as UDI needs a value set or starter set. For example, the National Provider Identifier (NPI) or individual person identifiers of various kinds (SSN, Drivers License) do not use value sets.

Feedback on II-B: Domain or Disease-Specific Care Plan Standards: For C-CDA 2.1 in general, HIMSS suggests an adoption level of 3. This standard is required in certification, Meaningful Use Stage 3 and MACRA. However, not all EHRs are capable of meeting this requirement to date. Specifically the C-CDA Care Plan Document likely has a lower adoption for either 1 or 2, since it is a newer document type with fewer implementations. HIMSS also recommends the addition of the following clarifying text to the Limitations/Dependencies/Preconditions: “The Personal Advance Care Plan Document is for the domain of patient-authored goals, priorities and preferences, including but not limited to Advance Directives.”

Feedback on II-F: Establishing the Authenticity, Reliability, and Trustworthiness of Content Between Trading Partners: HIMSS suggests adding the HL7® FHIR® Provenance Resource as an emerging standard to this Interoperability Need, since it is a Standard for Trial Use and is at FHIR® maturity level 3. This resource leverages the W3C Provenance specification to represent HL7® support of provenance throughout its standards. It is explicitly modeled as functional capabilities in ISO/HL7 10781 EHR System Functional Model Release 2 and ISO 21089 Trusted End-to-End Information Flows. Mappings are provided within this Resource.

Feedback on II-U: Support a Transition of Care or Referral to Another Health Care Provider: In response to ONC’s request for feedback on “Applicable Security Patterns”, HIMSS does not believe any "applicable security patterns" need to be assigned to content standards like C-CDA, as they would vary depending on how the document is transmitted or shared. For example, the patterns would be different if C-CDA is pushed via Direct, or downloaded by a patient through a portal, or queried using an IHE document registry/repository. A security pattern makes more sense listed for the Services such as III-A "Push Exchange”, which ONC already includes.

The following feedback is related to Section VI’s question on sources included in Appendix I, listed below.

16. Are there other authoritative sources for Security Standards that should be included in Appendix I?

Before discussing the sources included for the security standards within the ISA, HIMSS believes greater organization of this Appendix would significantly increase the value of the information included in this section. The current sources, while incredibly important, lack any clear delineation as to how they should be leveraged. Some method of categorization should be added to the Appendix, defining the purposes for the sources included. The NIST Cybersecurity Framework provides categories for the standards included within that document (specifically in Tables 2 and 3). HIMSS suggests that ONC review this Table for potential options to better organize Appendix I.

For the sources included in the Appendix, HIMSS has identified some opportunities to expand and update the current list. HIMSS would first like to prioritize the following sources as we believe their inclusion is important to addressing the health IT security landscape.

HIMSS would also like to suggest the inclusion of the following sources.

  • AAMI TIR57: Principles for medical device security—Risk management
  • ASTM E1869-04:2014 Standard Guide for Confidentiality, Privacy, Access, and Data Security Principles for Health Information Including Electronic Health Records
  • ASTM E-31. https://www.astm.org/COMMIT/E31standardseducation.pdf
  • ONC Guide Privacy and Security of Health Information: https://www.healthit.gov/sites/default/files/pdf/privacy/privacy-and-security-guide.pdf
  • ISO/IEC 27002:2013 Information technology — Security techniques — Code of practice for information security controls (second edition) http://www.iso27001security.com/html/27002.html
  • HITRUST Common Security Framework: https://hitrustalliance.net/content/uploads/2014/05/HITRUSTCSF-2014-v6_0-Executive-Summary-and-Introduction-FINAL.pdf
  • Validated FIPS 140-1 and FIPS 140-2 Cryptographic Modules http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm
  • ISO 13485 FDA's Unique Device Identification UDI
  • ISO 14971: Medical devices -- Application of risk management to medical devices
  • ISO/AWI 81001 Health software and health IT systems safety, effectiveness and security
  • ISO/TR 11633 Health informatics -- Information security management for remote maintenance of medical devices and medical information systems
  • ISO 27799:2008 Health informatics - Information security management in health using ISO/IEC 27002
  • ISO 20429 Principles and guidelines for protection of PHI (working draft)
  • ISO/IEEE 11073 “Personal Health Data (PHD) Standards”
  • IEEE: “Building Code for Medical Device Software Security”
  • IEC 62304: Medical device software -- Software life cycle processes
  • IEC/FDIS 82304-1 “Health software - Part 1: General requirements for product safety”
  • NIST Special Publication 800-185. SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash. http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf
  • NIST Special Publication 800-188 (2nd DRAFT). De-Identifying Government Datasets. http://csrc.nist.gov/publications/drafts/800-188/sp800_188_draft2.pdf
  • NIST Special Publication 800-184. Guide for Cybersecurity Event Recovery. http://csrc.nist.gov/publications/drafts/800-188/sp800_188_draft2.pdf
  • NIST Special Publication 1800-4c. Mobile Device Security. https://nccoe.nist.gov/publication/draft/1800-4c/#t=MDSHowTo%2FCover%2FCover.htm
  • NIST Special Publication 1800-8C. Securing Wireless Infusion Pumps In Healthcare Delivery Organization. https://nccoe.nist.gov/sites/default/files/library/sp1800/hit-infusion-pump-nist-sp1800-8c-draft.pdf
  • NIST Special Publication 1800-3c. Attribute Based Access Control. September 2015 https://nccoe.nist.gov/sites/default/files/library/sp1800/abac-nist-sp1800-3c-draft.pdf
  • NIST Special Publication 800-121 Revision 2. Guide to Bluetooth Security. http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-121r2.pdf
  • NIST Special Publication 800-178. A Comparison of Attribute Based Access Control (ABAC) Standards for Data Service Applications Extensible Access Control Markup Language (XACML) and Next Generation Access Control (NGAC). November 2016 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-178.pdf
  • NIST Special Publication 800-66 “An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule” http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-66r1.pdf 
  • NISTIR 7497, Security Architecture Design Process for Health Information Exchanges (HIEs) (September 2010) https://www.nist.gov/healthcare/security/health-information-exchange-hie-security-architecture
  • IEC 80001 series:
    • IEC 80001-1:2010 “Application of risk management for IT-networks incorporating medical devices -- Part 1: Roles, responsibilities and activities”
    • IEC/TR 80001-2-1:2012 “Application of risk management for IT-networks incorporating medical devices -- Part 2-1: Step by Step Risk Management of Medical IT-Networks; Practical Applications and Examples”
    • IEC/TR 80001-2-2:2012 “Application of risk management for IT-networks incorporating medical devices -- Part 2-2: Guidance for the communication of medical device security needs, risks and controls”
    • IEC/TR 80001-2-3:2012 “Application of risk management for IT-networks incorporating medical devices -- Part 2-3: Guidance for wireless networks”
    • IEC/TR 80001-2-4:2012 “Application of risk management for IT-networks incorporating medical devices -- Part 2-4: General implementation guidance for Healthcare Delivery Organizations”
    • IEC/TR 80001-2-5:2014 “Application of risk management for IT-networks incorporating medical devices -- Part 2-5: Application guidance -- Guidance for distributed alarm systems”
    • ISO/TR 80001-2-6:2014 “Application of risk management for IT-networks incorporating medical devices -- Part 2-6: Application guidance -- Guidance for responsibility agreements”
    • ISO/TR 80001-2-7:2015 “Application of risk management for IT-networks incorporating medical devices -- Application guidance -- Part 2-7: Guidance for healthcare delivery organizations (HDOs) on how to self-assess their conformance with IEC 80001-1”
    • IEC/DTR 80001-2-8 “Application of risk management for IT-networks incorporating medical devices -- Part 2-8: Application guidance -- Guidance on standards for establishing the security capabilities identified in IEC 80001-2-2”
    • IEC/NP TR 80001-2-9 “Application of risk management for IT-networks incorporating medical devices -- Part 2-9: Application guidance -- Guidance for use of security assurance cases to demonstrate confidence in IEC/TR 80001-2-2 security capabilities”
  • The following NIST documents provide standards and best practices for general security areas.
    • NIST SP 800-12, An Introduction to Information Security
    • NIST SP 800-14, Generally Accepted Principles and Practices for Securing Information Technology Systems
    • NIST SP 800-37 “Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach”
    • NIST SP 800-39, Managing Information Security Risk: Organization, Mission, and Information System View
    • NIST SP 800-40, Guide to Enterprise Patch Management Technologies
    • NIST SP 800-41, Guidelines on Firewalls and Firewall Policy
    • NIST SP 800-64, Security Considerations in the System Development Life Cycle
    • NIST SP 800-65, Integrating IT Security into the Capital Planning and Investment Control Process
    • NIST SP 800-70 National Checklist Program for IT Products: Guidelines for Checklist Users and Developers
    • NIST SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities
    • NIST SP 800-88 Guidelines for Media Sanitization
    • NIST SP 800-94, DRAFT Guide to Intrusion Detection and Prevention Systems (IDPS)
    • NIST SP 800-100, Information Security Handbook: A Guide for Managers
    • NIST SP 800-122, Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)
    • NIST SP 800-154, DRAFT Guide to Data-Centric System Threat Modeling
    • NIST SP 800-161, Supply Chain Risk Management Practices for Federal Information Systems and Organizations
  • The following documents provide important guidance on Vulnerability, Threat and Incident Management.
    • NIST SP 800-51, Guide to Using Vulnerability Naming Schemes
    • NIST 800-61 Computer Security Incident Handling Guide
    • NIST SP 800-83, Guide to Malware Incident Prevention and Handling
    • NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response
    • NIST Special Publication 800-150.Guide to Cyber Threat Information Sharing. October 2016 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-150.pdf
    • NIST SP 800-184, DRAFT Guide for Cybersecurity Event Recovery
  • The following documents provide guidance on encryption and key management.
    • NIST SP 800-57 Recommendation for Key Management
    • NIST SP 800-113, Guide to SSL VPNs
  • The following documents provide guidance for workforce development.
  • This NIST guidance document is not a standard but it addresses something government agencies, NIST included, have been researching for the past five years. Lightweight cryptography has applications for mobile devices, Internet of Things, and other devices/computers with limited processing power. http://csrc.nist.gov/publications/nistbul/itlbul2017-06.pdf
  • With the increased adoption of HL7® FHIR® and APIs by the industry, we would also suggest inclusion of the following standards:
    • IHE – Internet User Authorization (IUA): This security profile is used with HTTP REST and leveraged in all IHE FHIR® profiles. http://wiki.ihe.net/index.php/Internet_User_Authorization
    • SMART on FHIR® also offers stricter security architecture.
    • The HEART Working Group: This initiative by the OAuth community has developed privacy and security specifications that enable an individual to control the authorization of access to RESTful health-related data sharing APIs, and to facilitate the development of interoperable implementations of these specifications by others.

Furthermore, we recommend ensuring the sources included reflect the most up to date and streamlined information. See below for suggested edits.

HIMSS Response to 2017 ISA Section V, Questions 9-14

The Healthcare Information and Management Systems Society (HIMSS) is pleased to submit these comments for consideration by ONC to update the Interoperability Standards Advisory (ISA). These comments are one set in a series of comments that HIMSS has and will prepare to review the updates to the new web-based version of the ISA. More comments addressing other elements of this resource are forthcoming. For more information on previous comments, please visit the HIMSS website.

Please find comments below as related to specific questions outlined in the ISA’s Section V.

ISA Section V, Question 9. For consideration of a new subsection Representing Birth and Newborn Data Sets-Please comment on the feasibility and maturity of birth and newborn datasets, including the IHE Newborn Discharge Summary, that can be transferred between mother, newborn and pediatric medical home records.

HIMSS agrees that the creation of this subsection within Section I of the ISA is feasible and can leverage the IHE Newborn Discharge Summary (IHE NDS) to identify relevant datasets to include in the Interoperability Need. The IHE NDS Profile specifies relevant code systems, such as SNOMED CT and LOINC used for Data Element and Value definitions. The IHE NDS profile is currently in Trial Implementation and eligible for testing at the IHE North America Connectathon. Based on this profile, HIMSS proposes the following standards and characteristics to be captured in the Interoperability Need [see attached table].

Additionally, HIMSS encourages ONC to explore the value within other IHE profiles that can be leveraged for the creation of Interoperability Needs related to birth and newborn data. Some IHE profiles for consideration include Antepartum Profiles, Labor and Delivery Profiles, Perinatal Workflow and Postpartum Visit Summary. These profiles close the loop for full maternity care interoperability.

When proposing these datasets, HIMSS finds it important to point out the challenges that may arise in the implementation of birth record standards. In 2014, the Minnesota Department of Health reported results from its “Minnesota e-Birth Records Project: Assessing Readiness for e-Birth Records Standards”. The results suggested that the Minnesota Department of Health and area hospitals support the adoption of e-birth records standards, but lack the readiness to fully test and implement these standards. Four factors contribute to this lack of readiness, including 1) the lack of policies to support using e-birth records standards for the collection of civil and medical information, 2) the lack of incentives to promote implementation, 3) unavailable birth registration data in the EHR and structured data formats, and 4) the lack of testing with multiple EHR products. The complete findings and recommendations from this study can be viewed here and may help in the creation of this Interoperability Need.

ISA Section V, Question 10: The way FHIR is represented has changed in the ISA based on public feedback. Please provide feedback on whether this is a better way to reference FHIR within Interoperability Needs.

HIMSS supports the ISA’s representation of HL7 FHIR within the Interoperability Needs. Its inclusion as a “data element based query” is an improvement from the previous description of “representing data as resources.” HIMSS also agrees with the inclusion of HL7 FHIR within Interoperability Needs within Section II. Since HL7 FHIR is a broad standard covering content, query format, transport, provenance and security, HIMSS anticipates that over time the number of Interoperability Needs referencing HL7 FHIR will grow as the applicable HL7 FHIR resources reach higher maturity levels.

Furthermore, HIMSS agrees with the current representation of HL7 FHIR in relation to the maturity levels identified (at pilot level with low levels of adoption). This guidance is accurate in conveying that HL7 FHIR has promise for its role in assisting interoperability, but still has a long way to go before reaching higher maturity. Lastly, HIMSS recommends that the ISA provide information on compatibility issues between different releases of HL7 FHIR such as STU 3 and DSTU 2. For example, under what conditions can users who adopted HL7 FHIR STU 3 seamlessly exchange clinical data with the users who adopted HL7 FHIR DSTU 2?

ISA Section V, Question 11: Subsection II-G: Diet and Nutrition was added. Please review and provide comment about the accuracy of the attributes.

When available, the ISA should provide a hyperlink to Test Tools available for any listed standard (within this Interoperability Need and elsewhere in the ISA). For the HL7 FHIR standard listed as an Emerging Specification, HIMSS suggests listing the following test tool: https://www.hl7.org/fhir/validation.html. HIMSS also suggests sharing the following publicly available HL7 FHIR servers for testing: http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing.

In addition to hyperlinking within each Interoperability Need, HIMSS would also like to recommend the creation of a separate Appendix within the ISA with a list of all test tools that are available and referenced throughout the document to allow better navigation through the various test tools available to implementers.

ISA Section V, Question 12: Subsection II-K: Healthy Weight was added. Please review and provide comment about the accuracy of the attributes.

HIMSS agrees with using the IHE profile "IHE Quality, Research and Public Health Technical Framework Supplement – Healthy Weight (HW)" for exchanging information on healthy weight and with the details for the six characteristics and considerations associated with this profile. HIMSS recommends that the following standards be added to the Interoperability Need that the aforementioned IHE profile is based upon:

  • HL7® Version 2.5.1 Standard
  • HL7 CDA® R2 Standard

ISA Section V, Question 13: Subsection II-P: Patient Identification Management was added. Please review and provide comment about the accuracy of the attributes.

HIMSS would like ONC to expand its description to provide clarity on the intended purpose of this Interoperability Need. When the ISA refers to Patient Identification Management (PIM), does this need aim to address patient identity proofing, patient identity matching, or both issues? More information on the purpose of this Interoperability Need would be helpful to implementers.

HIMSS also suggests including the specifications listed in Subsection III-E: Patient Identification Management (“IHE-PDQ (Patient Demographic Query)” and “IHE-PIX (Patient Identifier Cross-Reference)”) within Section II’s Interoperability Need. Though there are elements of both content and services within the need of Patient Identification Management, it seems appropriate to list all standards and specifications within one Interoperability Need. If ONC would like to keep these separate, HIMSS recommends (hyper)linking to the other Interoperability Need so implementers are aware of all standards and specifications needed to address this topic.

In relation to the standards listed, the generic ADT content listed in Section II included fields beyond those needed to accomplish Patient Identification Management. There may be an opportunity to provide specific details in the Limitations, Dependencies, and Preconditions section.

In regards to the Test Tools for the HL7 2.5.1 ADT Message, HIMSS suggests ONC work with each standard body to identify the best/preferred tool(s) to test interoperability needs listed in the ISA.

Lastly, HIMSS supports the further exploration of unique health safety identifiers, which would greatly enhance and help to resolve interoperability issues.

 

ISA Section V, Question 14: Subsection III-E: Patient Identification Management was added. Please review and provide comment about the accuracy of the attributes.

As discussed in the previous question, HIMSS recommends that Implementation Specifications “IHE-PDQ (Patient Demographic Query)” and “IHE-PIX (Patient Identifier Cross-Reference)” be listed in Subsection II-P together with the standard “HL7 2.5.1 (or later) ADT message” since both the base standard and implementation specifications are required for representing content and structure related to PIM. If these specifications are kept separate, HIMSS recommends that the aforementioned three specifications be referenced via hyperlink in both Subsections II-P and III-E.

HIMSS further recommends that the adoption level of the aforementioned IHE profiles be updated to “Level 5” to represent the widespread adoption and use of these standards in local, regional and state exchanges.

Question 9 Interoperability Need Table_HIMSS.pdf