Questions and Requests for Stakeholder Feedback

Updated questions for the 2019 Review and Comment Period

As with the previous iterations of the Interoperability Standards Advisory (ISA), posing questions has served as a valuable way to prompt continued dialogue with stakeholders for continuous improvement of the ISA. In addition to the questions and requests for feedback below, stakeholders are encouraged to review content within the sections and specific Interoperability Needs to provide feedback, or submit requests for new Interoperability Needs, as necessary. 

Historical questions and requests for stakeholder feedback have been moved for viewing history, but comments on and responses to these questions remain on this page, or may be included in comment letters received posted as comments elsewhere on the ISA.

  • 19-1: In what ways has the ISA been useful for you/your organization as a resource? ONC seeks to better understand how the ISA is being used, by whom, and the type of support it may be providing for implementers and policy-makers.
  • 19-2: Are there additional features or functionality ONC could make to the ISA website that would enhance the user experience?
  • 19-3: The adoption level, along with other informative characteristics about standards/implementation specifications, was introduced to the ISA in August, 2015, and currently represents ONC’s “best guess” at current adoption based on a number of factors. Is the adoption level characteristic as it stands valuable information for stakeholders, or should it be retired or replaced with other information?
  • 19-4. The specialty care/settings pages were added in 2019, and represent a collection of related Interoperability Needs that pertain to a particular setting or type of specialty care (i.e., pediatrics, treatment for opioid use disorder). Are there additional specialty care/settings specific collections that would be beneficial for inclusion? 

Comment

Submitted by Patrick Johnson on

Interoperability Standards Advisory: Annual Request for Comments

Please accept these comments on behalf of the American Academy of Pediatrics in response to a request for comments on the 2018 Interoperability Standards Advisory. Please let me know if you need any further information or need any clarification on these comments.

Sincerely,

Patrick Johnson
Director, Federal Advocacy
American Academy of Pediatrics

AAP Comments_2018 Interoperability Standards Advisory.pdf

Submitted by Anthracite on

Part III Standards for Privacy and Security of data

Consumer Access/Exchange of Health Information

Standards for Privacy and Security of Data

Recognizing these requirements are not possible to implemen at the moment does not mean that they should not be possible. There is an HL7 standard that addresses these issues except for the first bullet point. Methods for limiting what data may be exchanged and with whom should be available to patients.

  • Patients should have the option of allowing their data to be exposed on the Internet or not. One of the best ways to protect data from hacking is to be sure it is not exposed to the possibility of hacking.

  • Patient should be able to have granularity in specifying to whom their data may be sent. Sending their information to a physician in a healthcare system should not expose their data to every other physician in that healthcare system unless the patient specifies that broad permission is acceptable.

  • Patient should also be allowed to have granularity in what data is exchanged.

Thank you for your consideration.

Nancy E. Anthracite, MD
nanthracite@earthlink.net

Submitted by michael.decarl… on

BCBSA Comments on ONC Proposed 2018 ISA

The Blue Cross and Blue Shield Association (BCBSA) appreciates the opportunity to respond to ONC's request for stakeholder feedback related to the Proposed 2018 Interoperability Standards Advisory.  

We appreciate your consideration of our comments. If you have any questions or need additional information, please contact Michael DeCarlo at michael.decarlo@bcbsa.com.

BCBSA Comment Letter_ISA_10-1-18.pdf

Submitted by HIMSS on

HIMSS Response to October 2018 ONC Request for Feedback

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 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 the current ONC Requests for Feedback.

18-1. In what ways has the ISA been useful for you/your organization as a resource? ONC seeks to better understand how the ISA is being used, by whom, and the type of support it may be providing for implementers and policy-makers.

HIMSS membership includes individual, organizational and corporate members who are end-users that work to develop and implement interoperable solutions within their organizations. Below are some examples of the types of organizations that interact with the ISA, and their experiences with the resource:

  • One member, working for a network of outpatient, physical therapy facilities, shared that the ISA is referenced for interface needs. However, the standards listed in the ISA are not always available on their EHR developer site, limiting access to data to what the EHR system deems important to include in their interfaces.
  • One member, working with a solutions supplier providing services across the healthcare industry, shared that his organization has referenced the ISA for various integrations, using the information to determine which standards to adopt depending on the use case. It has also helped validate claims of external vendor partners that may push for a particular type of integration based on how widely adopted a standard may be.
  • Another member from an academic medical center cited the value of the ISA Reference Edition. This dated version of the ISA resource is helpful to reference in contract negotiations with vendors and other entities. While the continuous updates to the ISA have clear value to keep up with developments in the industry, the Reference Edition has clear value in the contractual landscape.

Conversations around the uses of the ISA led to dialogue that revealed that many of our members still were not aware of the ISA. Once introduced to the resource, they identified value that the resource could potentially bring to the work within their organizations. HIMSS continues to promote the ISA in many of its interoperability resources, and encourages the ONC to continue to explore marketing and awareness building opportunities to the health IT ecosystem with other federal agencies and non-profit organizations.

Beyond these uses by our members, they have also discussed additional items of value in their use of the ISA. Specifically, HIMSS would like to acknowledge the expansion of Security standards and resources included in the ISA. Alignment of interoperability standards with the key security considerations will only grow in importance as more stakeholders are impacted by this landscape, and updating this information will be important in enhancing the value of the ISA. Additionally, members voiced the importance of embedding as many links to additional resources as possible. Inclusion of additional linked resources in this manner serves as an important element in the user experience of the ISA.

18-2. Over the course of 2018, some new functionality has been added to the ISA, with more enhancements expected through 2018 and 2019. Are there additional features or functionality that would enhance the user experience?

HIMSS appreciates the addition of the ISA Updates tab as well as the notification options. While the ISA Updates tab provides information about major changes to the ISA and the notifications are helpful to know when updates have been made to the ISA and in which sections they occurred, it is still unclear what specific updates are made. Once in the Updates section, there is no indication as to whether a standard was added or changed, or additional limitations were provided. Furthermore, if a person is not subscribed to notifications, they have no way to know the information has changed. Additional versioning in the notes would help in recognizing what has changed. This may be achieved by adding tabs to reference previous dated versions of the Interoperability Need. It may also be helpful to include a “Last Updated” date on each Interoperability Need page.

There are a number of places within the ISA where navigation links are broken. For example, the left sidebar index has been reordered alphabetically. However, some of the forward/background options below each Interoperability Need page do not navigate to the next Interoperability Need listed in the index order.

The left sidebar index should be optimized with some additional functionalities. Currently the scroll is synchronized for the main ISA body as well as the index sidebar. Allowing the index sidebar to scroll separately from the body would enhance user experience. ONC may also want to consider adding the page-to-page navigation at both the bottom and top of the page.

HIMSS urges ONC to consider adding more filters for users to leverage in exploring the ISA. A valuable function would be the ability to filter by the Federal Regulation or Requirement. It is helpful having links to which standards are federally required, but it would also be helpful to search across all the standards required for a specific regulation. This would give more power to health systems as they explore and negotiate adding products from EHR systems/vendors.

Many HIMSS members agreed that it would be beneficial if ONC added a section that highlighted real examples of interoperability in action to demonstrate the value of leveraging the ISA. When users have examples and platforms to discuss the implementation of recommended standards, they can learn from other’s implementations and engage in dialogue to improve on those experiences. Any opportunity to tie the use of these standards to improved clinical and administrative outcomes may provide leverage to organizations to pursue adoption of those efforts. This modification will also make the ISA more understandable to stakeholders with less technical background and enable them to better understand and implement standards-based health IT solutions.

While the Interoperability Proving Ground (IPG) offers a home for examples of real-world efforts and provides a number of resources across the ISA, they do not always provide clear information on the value and challenges of leveraging these standards. Expanding this information either in the IPG or within another prominent area of the ISA, could serve as a resource and marketing opportunity for the use of the ISA. Some examples to consider:

Again, as the conversation of functionality continued, members voiced that while much of the functionality exists in the ISA, it is not clearly highlighted for users to leverage. There is a paragraph in the beginning of the ISA Introduction that discusses some of the ways to engage with the ISA. This paragraph could be highlighted as its own section or subsection to educate users. Adding this functionality into the marketing activities for the ISA would be helpful as well.

18-3. Is the existing ISA format used for listing standards and implementation specifications applicable for listing Models and Profiles?  Are there additional or different attributes that should be collected for them?  Are there additional models and/or profiles that should be listed? Are models and profiles useful for inclusion in the ISA?

As a first step to improve this section of the ISA, HIMSS recommends adding specific definitions for what ONC means when they refer to Models and Profiles, as these terms are leveraged in other ways within the health IT industry. For example, standards development organizations such as IHE use the word “profile” to mean “a precise definition of how standards can be implemented to meet specific clinical needs.” The “Profile” content of the Models and Profiles section is function-focused, while the other ISA sections are more akin to the use of the word “Profile” as IHE defines it. HIMSS recommends that ONC explicitly define the Models and Profiles section and state its purpose and expected use. Given that the information included seems more educational, ONC may want to consider moving this entire section under the Educational Resources section.

In regards to the attributes provided for these Models and Profiles, the functional models and profiles and informational models serve a different purpose than the standards and implementation specifications in the rest of the ISA (Section 1-3). Therefore, applying the same attributes from Sections 1-3 to these Models and Profiles is not appropriate. These are more conceptual reference models providing information to understand how these standards are built. One example of the inappropriateness of the attributes is with the row labels. Currently, “Implementation Specification” is used to describe the models/profiles in the tables. This name is not appropriate here since these Models and Profiles are not implementation specifications, and HIMSS suggests simply identifying them as a Functional Model or Informational Model.

18-4. Are there additional informative or educational resources that can be provided to help stakeholders better understand the ISA, health IT standards, interoperability, etc? (Refer to Appendix II for current resources provided)

HIMSS appreciates the work ONC has done to bolster the Security resources included in the Appendix. However, with the wide breadth of resources included, if there are any educational resources that can be provided as a foundation to Appendix I, HIMSS recommends adding them. ONC may want to review the HIMSS Privacy & Security Toolkit as an educational resource for inclusion. NIST may be able to provide such resources for consideration.

Also, as mentioned in Question 18-3, HIMSS requests that ONC consider moving the Functional and Informational Models and Profiles to Appendix II. This section aligns better with the information those models and profiles provide. In addition to the current models listed, Domain Analysis Models would be a helpful addition to Appendix II.

Additional Feedback

During our review of these four questions, HIMSS encountered additional items to share as feedback. Throughout the ISA, all links to https://htct.hhs.gov and its related pages are currently unusable due to the certificate having expired. Please update these hyperlinks. ONC may consider improving their alignment with other standards sources. For example, it would be beneficial if the work of the CMS Data Element Library (DEL) was reconciled with the ISA. Establishing the ISA as a repository of standards across all agencies within the Department of Health and Human Services (HHS) would be of value and assist end users with obtaining comprehensive education and guidance. In the same spirit as the recommendation regarding the CMS DEL, HIMSS urges ONC to also consider how the ISA will be leveraged to document and align with the forthcoming US Core Data for Interoperability (USCDI) data elements. Once those are finalized, will these data classes be tracked within the ISA?

HIMSS would also like to suggest a core set of IHE Profiles to be included in the ISA as they provide FHIR-based APIs as methods of accessing data through currently deployed information-sharing infrastructures like XDS/XCA and Direct. The current widespread use of these infrastructures is well documented in the HIMSS Interoperability Initiatives Environmental Scan. This core set of FHIR-based IHE Profiles includes:

  • Mobile access to Health Documents (MHD) - defines a FHIR interface for document sharing (e.g., HL7 CDAs), including, optionally, providing a FHIR proxy to an XDS/XCA environment. The Argonaut Document Access Implementation Guide is simplified implementation of this option.
  • Mobile Cross-Enterprise Document Data Element Extraction (mXDE) - defines a method of exposing data elements (represented as FHIR resources) extracted from documents (e.g., CDAs) that have been shared, for example, via FHIR or XDS.
  • Patient Demographics Query for Mobile (PDQm) – Defines FHIR Patient resource query capabilities to establish expected baseline search capabilities. The query capabilities defined are equivalent to those described in the HL7 v2-based IHE PDQ profile.
  • Query for Existing Data for Mobile (QEDm) - supports queries for clinical data elements, including observations, allergy and intolerances, conditions, diagnostic results, medications, immunizations, procedures, encounters and provenance by making the information widely available to other systems within and across enterprises.

Two additional IHE Profiles also warrant consideration:

  • Mobile Care Services Discovery (mCSD) (including HPD) – defines a comprehensive Provider Directory including Organization, Location, Services, and Practitioners.
  • Internet User Authorization - defines a plugable basic OAuth interaction to enable app and user authorization. Intended to be enhanced based on use-case analysis.

HIMSS Response to ISA Oct 2018.pdf

Submitted by CAQHCORE on

CAQH CORE Comments on 2018 Interoperability Standards Advisory

18-2. Over the course of 2018, some new functionality has been added to the ISA, with more enhancements expected through 2018 and 2019. Are there additional features or functionality that would enhance the user experience?

  1. Given the availability of multiple industry standards for a specific function, adoption rates are an important criterion for entities when evaluating potential standards. ONC is urged to consider identifying and utilizing sources to verify the adoption rates included in the ISA. The CAQH Index provides an industry-wide resource on annual trends in adoption rates for the administrative transaction standards and implementation specifications.
  1. The online resource for the ISA could be made more user friendly through improved labeling of content such as additional structure options for “type” as previously recommended.

18-4. Are there additional informative or educational resources that can be provided to help stakeholders better understand the ISA, health IT standards, interoperability, etc.?

CAQH CORE maintains a host of free implementation tools to support operating rule adoption on its website. Additionally, CAQH CORE offers regular educational webinars which are archived on our site to drive greater industry awareness of the value of operating rules in collaboration with leading healthcare organizations.

(Above content is an except of the full CAQH CORE Comment Letter).

CAQH CORE ISA Comment Letter 10.01.18.pdf

Submitted by HIMSS on

Feedback on December 2017 Updates

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 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 the new Interoperability Needs that have been added to the ISA as part of the December 2017 Recent ISA Updates.

Section II Care Plan: Documenting and Sharing Medication-Related Care Plans by Pharmacists

HIMSS would like to ensure that the scope of this Interoperability Need includes the perspective of the patient in any care planning. The patient’s wishes need to be clearly stated for all involved in the care plan and such goals need to be center-stage within the patient’s electronic medical record. The pharmacist needs to have access to documentation related to Shared Decision Making, which relates to the Patient’s Wishes and the Patient’s Treatment Plans.

Both for inpatient and ambulatory care, the pharmacist’s plan often takes into account the patient’s at-home medications and over-the-counter medications purchased in the pharmacy. Adding the pharmacy benefit management information to view, download and transmit requirements for the patient, and providing patient specific costs at the point of care both to the provider and the patient can greatly influence purchasing and adherence behavior.

Section II Clinical Quality Measurement and Reporting: Reporting Aggregate Quality Data to Federal Quality Reporting Initiatives

HIMSS commends ONC for including QRDA Level III data to support the reporting of aggregate data to assist in the review of patient populations. HIMSS encourages the adoption of standards that decrease the administrative burden of quality measurement and we support ONC’s efforts to endorse and inform the industry on best practices to ease the burden of data collection.

Section II Images: Format of Radiation Exposure Dose Reports for Exchange and Distribution

HIMSS agrees that the use of DICOM for formatting these reports is an important standard to use, but would also highlight the benefits of PDFs in the workflow as well for physicians and patients interested in only viewing the report. RSNA and IHE provide profiles that include the workflows for PDF in correlation with DICOM. These profiles are included on the following Interoperability Needs.

HIMSS recommends that these Interoperability Need solutions be referenced via a link to ensure readers know where they can crosswalk to similar resources within the ISA.

HIMSS agrees with the adoption level for the standards on this interoperability need. While DICOM adoption is high through many areas of the industry, radiation exposure is a newer topic with currently lower adoption. However, we anticipate that demand is increasing for standards around this and anticipate that adoption level will soon need to be adjusted.

HIMSS applauds the inclusion of this Interoperability Need as information and tracking of radiation dose becomes more prevalent and of interest to empowered patients seeking to be engaged in discussions about treatment plans. Furthermore, new legislation starting in 2020 via the Protecting Access to Medicare Act (PAMA) will require consulting the Appropriate Use Criteria (AUC) before ordering advanced diagnostic imaging services. It is anticipated that documentation on and verification of consulting the AUC will become part of the workflow for the exam order. Incorporating these criteria in these reports would streamline information provided to the patient as explanation for the diagnostic services performed.

All radiation tracking should be available to patients under the view, download, transmit, open API requirements along with the accompanying patient specific education.

Section II Public Health Reporting: Reporting Death Records to Public Health Agencies

HIMSS encourages ONC to ensure that any public health reporting requirements be harmonized to registries that are also collecting such information.

While not federally required, the CDC strongly supports the use of the IHE specification, IHE Quality, Research and Public Health Technical Framework Supplement Vital Records Death Reporting (VRDR) R 3.1, listed in this Interoperability Need. HIMSS suggests that ONC make a note that highlights this federal support as it may be an important consideration in the implementation of the standards.

HIMSS also encourages the reporting of this data to regional/state health information exchanges (HIE). Having this data available at the point of the HIE can provide value to physicians and population health professionals. This is a potential use case that ONC may consider exploring in future versions.

Section II Public Health Reporting: Reporting Newborn Screening Results to Public Health Agencies

As stated in the above interoperability need, HIMSS encourages ONC to ensure that any public health reporting requirements be harmonized to registries that are also collecting such information, as to decrease the administrative burdens on providers.

HIMSS recommends adding the IHE specification for Newborn Admission Notification Information (NANI). CDC supports the use of this standard for newborn reporting. While this profile is focused on notifications rather than screening, it contains elements that are important for inclusion with this interoperability need.

Also, the EHDI standard “HL7 Version 2.6 Implementation Guide: Early Hearing, Detection and Intervention (EHDI) Results Release 1” is actually referenced by an IHE profile dedicated to this Interoperability Need. HIMSS recommends that the language be updated to read “IHE Early Hearing Detection and Intervention Profile available here” in lieu of including the HL7 standard alone.

Section V CMS Interoperability Standards for Provider to Provider Communication: Durable Medical Equipment/Home Health Agency Document Request

HIMSS recognizes that this is a huge area of opportunity and appreciates ONC’s inclusion in the ISA. We request the addition of clarity on the reason or indication for the durable medical equipment (DME). DME has the potential for fraud and abuse, so the reason for, and the duration of equipment needs to be clear to all involved. Alternative treatments and previous methods of treatment, which did not lead to the desired outcome, may also need to be communicated, as well as the medical necessity of the DME. In other words, previous treatment attempts should be included in the current DME request.

Section V CMS Interoperability Standards for Provider to Provider Communication: Durable Medical Equipment/Home Health Agency Order Submission

HIMSS recommends that the reason or indication for the order should be included as part of the DME Order. Medical necessity should also be addressed either in the order or in a comment field of the order to ensure stakeholder alignment on the patient’s needs.

General Comments

HIMSS appreciates the time ONC is taking to ensure complete review and consideration of every recommendation and recognizes that more updates are planned for the 2018 edition of the ISA. In 2017 the HIMSS ISA Task Force recommended a new section be added to the ISA. This recommendation included the top use cases, the standards recommended and the inclusion of an educational section. This section should serve as a primer on standards and policies relevant for consumer-mediated exchange and encourage new industry stakeholders supporting patient access. HIMSS requests an update on the progress of adding this section to the ISA.

Submitted by IHEUSA on

IHE USA's Response to 2017 ISA Section VI Questions 3-7 and 16

IHE USA 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 and IHE USA 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 IHE USA 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 IHE USA 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. IHE USA 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, IHE USA 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: IHE USA suggests the creation of procedure-specific value sets for SNOMED CT codes.

Feedback on I-U: Defining a Globally Unique Device Identifier: IHE USA 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, IHE USA 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. IHE USA 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: IHE USA 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”, IHE USA 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, IHE USA 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). IHE USA suggests that ONC review this Table for potential options to better organize Appendix I.

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

IHE USA 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.

IHE USA ISA Comments Section VI Q 3-7 and 16_2017_11_20F.pdf

Submitted by patient_EHR_support on

Commentary from an emergency room physician

These comments were shared with us today from an Emergency Room Physician at a major medical facility:

"We are a global city, have people coming in from all over the world. And we can’t access their medical records. That kind of interoperability would be great. Even from within the region, we never have all their information. People had imaging studies done but we don’t want the redundancies. If I had access to her studies today, and the ER radiologist could read it. Interoperability is critical, especially for emergency care.” People come in with huge records and being able to access them would be so important. Having done this for 25 years, I’ve seen great changes compared to what we used to have. But knowing the technology and what we could have, it is frustrating."