Questions and Requests for Stakeholder Feedback

IHE USA's Comments on Section V of the 2017 ISA

On behalf of the IHE USA we are pleased to provide written comments to the Office of the National Coordinator for Health Information Technology (ONC) in response to the 2017 Interoperability Standards Advisory (ISA). IHE USA appreciates the opportunity to leverage our volunteers’ 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.

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

ISA Section V, Question 1: Based on public comment and Health Information Technology Standards Committee recommendations, the ISA is now an interactive web application.  What additional functionalities would make the ISA more useful as a resource?

Version Control: IHE USA appreciates the opportunity for timely feedback via the Web version and appreciates the inclusion of a Reference Edition as stated in the 2017 ISA:

“In December of each year, ONC will publish a static “Reference Edition” of the ISA that can be referenced in contracts, agreements, or as otherwise needed with certainty that the information will not change. For example, in December 2016, ONC will publish the 2017 ISA Reference Edition.”

IHE USA finds that it would be beneficial if ONC defines a plan for version control for web-based content. For example, how often will ONC update the web version of the document? IHE USA is concerned that important updates will not be communicated to implementers, and use of the Reference Edition will overshadow use of the more dynamic web version. ONC should share regular summaries of the changes made between versions to help the industry better understand the differences from the Reference Edition.

Clarification of “Federally Required”: IHE USA suggests it is valuable to include hyperlinks, when applicable, to the regulation associated with a federally required standard/implementation specification. However, based on the scope it is unclear as to whether the “Federally Required” characteristic is obligatory for federal agencies only or should be applied to commercial implementers as well. IHE USA suggests clarification on requirements for commercial uses.

Updates to Webpage Navigation: Currently the “Home” button navigates to Section I of the 2017 ISA. IHE USA suggests that the button should navigate to the Introduction section to the ISA.

Maintenance of User Comments: IHE USA is pleased with the opportunity to register and comment directly within the ISA. However, we want to ensure that these comments will be clearly marked as User Comments, rather than official ISA content. Our organization is also curious as to whether users are notified when an additional comment or update is added following his/her comment. Also, with the new Web-based version, one needs to make sure the list of comments by stakeholders is maintained. One may use the comments for education, direction, or even for strategy in institutions, and being able to retrieve past comments will be important. ONC may want to consider adding search features for comments. ONC may also want to capture more demographics from users leaving comments to better sort through feedback. For example, filters and queries of comments by topic, keyword, author, or institution/organization type may be valuable for users. For commenters not interested in disclosing this information, an anonymous option should be considered.

Use Cases: Links to use cases would be helpful information to include with Interoperability Needs to highlight their value. A standardized Use Case format would be helpful to the industry. The current hyperlinks to the Interoperability Proving Ground (IPG) can be expanded to better serve these needs. This resource has room for improvement in its organization and query functions. The IPG is broad in the resources listed and can benefit from improved categorization.

ISA Section V, Question 2: In what ways has the ISA been helpful?  What are ways in which the ISA could be improved to add value to nationwide standards adoption and use?

Leveraging Others to Highlight ISA Value: ISA is only useful to the extent that it has actual “usage” (being read and followed). Driving of usage could be increased if ONC participates in targeted outreach to other organizations to link “into” the ISA. IHE USA suggests that ONC should work in collaboration with other organizations to further align standards to better highlight the ISA tool within their communities. HIMSS, HL7, IHE, ASTM, CDISC, NLM, IHTSDO and other organizations that have standards referenced by ISA are a few of the organizations that ONC should target to help with ISA promotion. Partnerships with other federal agencies (CDC, OCR, OIG, FDA) would also help to highlight the value that ISA adds to improved healthcare interoperability.

Promoting Case Studies and Success Stories: ONC can better demonstrate the ISA’s value by providing examples of the uses of the different standards and the benefits of implementation. IHE USA suggests adding a resource page to highlight these examples or adding an open comment area focused on sharing the value of the ISA. White papers and blog posts can be leveraged to highlight the value as well. Key industry initiatives for standards and interoperability testing, such as the IHE North American Connectathon, would also be helpful to highlight.

Marketing the ISA: As the ISA expands, ONC may need to consider the intended audience. New stakeholders may be less technical than the current audience and may not have the bandwidth to interpret the document appropriately for implementation. ONC may want to consider using a marketing consultant to better reach these audiences.

Removal of “Best Available”: As stated in earlier comments, IHE USA believes that the removal of “best available” is detrimental to the nationwide adoption and use of interoperability standards. Adding language that indicates these are current and emerging standards for serious consideration would help highlight the role of these standards and specifications in reaching interoperability objectives.

Expansion on the Security Appendix: The Security Appendix lacks any categories or explanation for the resources listed, and is large and overwhelming to navigate. This list needs to be vetted and better organized. IHE USA plans to review the Appendix in future ISA reviews with a focus on how this Appendix can be improved, and will offer further comment.

Mobile Health: IHE USA suggests that ONC explore the addition of mobile health as a specific section including standards that may differ for the mobile health environment. It may be beneficial to add a section on gaps or differences in standards unique to the mobile space.

ISA Section V, Question 8: Are there additional Social Determinant Interoperability Needs with corresponding standards that should be included in the ISA?

IHE USA supports the inclusion of Social Determinants of Health (SDOHs) as valuable data elements that should be captured and integrated to not only improve the care provided but also help improve and address healthcare costs. In a comparison of SDOHs outlined by the National Academy of Sciences to SDOHs currently listed in the ISA, we noted a few gaps that could be addressed within the ISA.

• Country of Origin/Birth: Currently there are no Interoperability Needs capturing this information, and IHE USA believes this SDOH may be relevant for a number of scenarios. For instance, inclusion of this information can assist in identifying potential cultural or language considerations in treatment or care. Such data may be pertinent in outbreak situations. This information can also be applicable to those serving overseas.
• Dietary Patterns: ISA currently does not include an Interoperability Need to capture SDOH data for dietary behaviors, including but not limited to diet, nutrition, obesity and eating disorders. Exploration and inclusion of standards related to this topic would be valuable.
• Neighborhood and Community Compositional Characteristics: More granular location information beyond zip codes should be explored to assist in the capture of social determinants related to community and neighborhood demographics. Geocoding, census tracts, carrier-route codes, and zip+4 are all potential data sets that should be considered to capture more granular patient information.
• Substance Abuse and Behavioral Health: IHE USA commends ISA on the inclusion of specific Interoperability Needs for alcohol and tobacco use, but feels that an Interoperability Need for Substance Abuse would be beneficial to capture other substances’ use/abuse (illicit or otherwise). IHE USA would like to highlight the importance of standards related to Behavioral Health issues (including Substance Abuse). We understand the challenges around these sensitive data elements and we support ONC’s continued collaboration with the Substance Abuse and Mental Health Services Administration (SAMHSA) to further advance these standards.

Some of the Interoperability Needs in the ISA are relevant but could be expanded to capture more granular information.

• Employment: It is important that the ISA capture Industry and Occupation standards (Section I-H). However, no data set within this Interoperability Need is available for employment status (i.e. full time, part time, unemployed), which could be pertinent data to the individual’s care.
• Negative Mood/Affect: We commend ISA for including an SDOH Interoperability Need for Depression (Section I-S), but feel that this Need can be expanded to include the capture of individual anxiety issues.
• Tobacco Use/Exposure: The current SNOMED CT codes used for this Interoperability Need are interpretative and ambiguous. LOINC may offer some more granular options to use: (LOINC codes 64572-1; 64570-5; 68536-2; 68535-4; 82769-1; 81228-9)
• Exposure to Violence: IHE USA commends ONC on the inclusion of Violence within the SDOHs listed in the ISA, but suggests expanding the title of the Interoperability Need to include “Exposure to Violence and Abuse”. Inclusion of abuse is more encompassing of patient exposures that may relate to their health, including emotional and sexual abuse. The current LOINC codes for this Interoperability Need also use the term “abuse”.

We appreciate the opportunity to submit comments on the 2017 ISA.  Our comments are intended to recognize the importance of each stakeholder’s role in advancing standards-based interoperability and health information exchange, and ensuring that each domain is invested in overcoming the inherent challenges, while further enhancing health IT’s pivotal role in enabling healthcare transformation.

We welcome the opportunity to meet with you and your team to discuss our comments in more detail. Please feel free to contact Joyce Sensmeier, President, IHE USA at 312-915-9281, or  Celina Roth, Sr. Manager, IHE USA, at 312-915-9213, with questions or for more information.

Thank you for your consideration.

Sincerely,

HIMSS Response to 2017 ISA Section V, Questions 1, 2 and 8

HIMSS appreciates the opportunity to provide comments in this new interactive ISA resource and is currently working with its members to review the updates to the new web-based version. In the spirit of the ONC’s new ongoing review process for the ISA, HIMSS will continue to review and submit comments on an ongoing basis. More comments addressing other elements of this resource are forthcoming. Please find comments below as related to specific questions outlined in the ISA’s Section V.

ISA Section V, Question 1: Based on public comment and Health Information Technology Standards Committee recommendations, the ISA is now an interactive web application.  What additional functionalities would make the ISA more useful as a resource?

Version Control: HIMSS appreciates the opportunity for timely feedback via the Web version and appreciates the inclusion of a Reference Edition as stated in the 2017 ISA:

“In December of each year, ONC will publish a static “Reference Edition” of the ISA that can be referenced in contracts, agreements, or as otherwise needed with certainty that the information will not change. For example, in December 2016, ONC will publish the 2017 ISA Reference Edition.”

HIMSS finds that it would be beneficial if ONC defines a plan for version control for web-based content. For example, how often will ONC update the web version of the document? HIMSS is concerned that important updates will not be communicated to implementers, and use of the Reference Edition will overshadow use of the more dynamic web version. ONC should share regular summaries of the changes made between versions to better understand the differences from the Reference Edition.

Clarification of “Federally Required”: HIMSS suggests it is valuable to include hyperlinks, when applicable, to the regulation associated with a federally required standard/implementation specification. However, based on the scope it is unclear as to whether the “Federally Required” characteristic is obligatory for federal agencies only or should be applied to commercial implementers as well. HIMSS suggests clarification on requirements for commercial uses.

Updates to Webpage Navigation: Currently the “Home” button navigates to Section I of the 2017 ISA. HIMSS suggests that the button should navigate to the Introduction section to the ISA.

Maintenance of User Comments: HIMSS is pleased with the opportunity to register and comment directly within the ISA. However, we want to ensure that these comments will be clearly marked as User Comments, rather than official ISA content. Our organization is also curious as to whether users are notified when an additional comment or update is added following his/her comment. Also, with the new Web-based version, one needs to make sure the list of comments by stakeholders is maintained. One may use the comments for education, direction, or even for strategy in institutions, and being able to retrieve past comments will be important. ONC may want to consider adding search features for comments. ONC may also want to capture more demographics from users leaving comments to better sort through feedback. For example, filters and queries of comments by topic, keyword, author, or institution/organization type may be valuable for users. For commenters not interested in disclosing this information, an anonymous option should be considered.

Use Cases: Links to use cases would be helpful information to include with Interoperability Needs to highlight their value. A standardized Use Case format would be helpful to the industry. The current hyperlinks to the Interoperability Proving Ground (IPG) can be expanded to better serve these needs. This resource has room for improvement in its organization and query functions. The IPG is broad in the resources listed and can benefit from improved categorization.

ISA Section V, Question 2: In what ways has the ISA been helpful?  What are ways in which the ISA could be improved to add value to nationwide standards adoption and use?

Leveraging Others to Highlight ISA Value: ISA is only useful to the extent that it has actual “usage” (being read and followed). Driving of usage could be increased if ONC participates in targeted outreach to other organizations to link “into” ISA. HIMSS suggests that ONC should work more with other organizations working to further align standards to better highlight the tool within their communities. HIMSS, HL7, IHE, ASTM, CDISC, NLM, IHTSDO and other organizations that have standards referenced by ISA are a few organizations that ONC should target to help with ISA promotion. Partnerships with other federal agencies (OCR, OIG, FDA) would also help to highlight value that ISA adds to improved healthcare interoperability.

Promoting Case Studies and Success Stories: ONC can better demonstrate the ISA’s value by providing examples of the uses of the different standards and the benefits of implementation. HIMSS suggests adding a resource page to highlight these examples or adding an open comment area focused on sharing value of the ISA. White papers and blog posts can be leveraged to highlight the value of the ISA and interoperability. Key initiatives for standards and interoperability testing, such as the IHE North American Connectathon, would also be helpful to highlight.

Marketing the ISA: As the ISA expands, ONC may need to consider the intended audience. New stakeholders may be less technical than the current audience and not have the bandwidth to interpret the document appropriately for implementation. ONC may want to consider using a marketing consultant to better reach these audiences.

Removal of “Best Available”: As stated in earlier comments, HIMSS believes that the removal of “best available” is detrimental to the nationwide adoption and use of interoperability standards. Adding language that indicates these are current and emerging standards for serious consideration would help highlight the role of these standards and specifications in reaching interoperability objectives.

Expansion on the Security Appendix: The Security Appendix lacks any categories or explanation for the resources listed, and is large and overwhelming to navigate. This list needs to be vetted and better organized. HIMSS plans to further review this Appendix in future ISA review with a focus on how this Appendix can be improved.

Mobile Health: HIMSS suggests that ONC explore the addition of mobile health as a specific section including standards that may differ for mobile health. It may be beneficial to add a section of gaps or differences in standards unique to the mobile environment.

ISA Section V, Question 8: Are there additional Social Determinant Interoperability Needs with corresponding standards that should be included in the ISA?

HIMSS supports the inclusion of Social Determinants of Health (SDOHs) as valuable data elements that should be captured and integrated to not only improve the care provided but also help to improve and address healthcare costs. In a comparison of SDOHs outlined by the National Academy of Sciences to SDOHs currently listed in the ISA, we noted a few gaps that could be addressed within the ISA.

• Country of Origin/Birth: Currently there are no Interoperability Needs capturing this information, and HIMSS believes this SDOH may be relevant for a number of scenarios. For instance, inclusion of this information can assist in identifying potential cultural or language considerations in treatment or care. Such data may be pertinent in outbreak situations. This information can also be applicable to those serving overseas.
• Dietary Patterns: ISA currently does not include an Interoperability Need to capture SDOH data for dietary behaviors, including but not limited to diet, nutrition, obesity and eating disorders. Exploration and inclusion of standards related to this topic would be valuable.
• Neighborhood and Community Compositional Characteristics: More granular location information beyond zip codes should be explored to assist in the capture of social determinant related to community and neighborhood demographics. Geocoding, census tracts, carrier-route codes, and zip+4 are all potential data sets that should be considered to capture more granular patient information.
• Substance Abuse and Behavioral Health: HIMSS commends ISA on the inclusion of specific Interoperability Needs for alcohol and tobacco use, but feels that an Interoperability Need for Substance Abuse would be beneficial to capture other substances’ use/abuse (illicit or otherwise). HIMSS would like to highlight the importance of standards related to Behavioral Health issues (including Substance Abuse). We understand the challenges around these sensitive data elements and we support ONC’s continued collaboration with the Substance Abuse and Mental Health Services Administration (SAMHSA) to further advance these standards.

Some of the SDOH Interoperability Needs in the ISA are relevant but could be expanded to capture more granular information.

• Employment: It is important that the ISA capture Industry and Occupation standards (Section I-H). However, no data set within this Interoperability Need is available for employment status (i.e. full time, part time, unemployed), which could be pertinent data to the individual’s care.
• Negative Mood/Affect: We commend ISA for including an SDOH Interoperability Need for Depression (Section I-S), but feel that this Need can be expanded to include the capture of individual anxiety issues.
• Tobacco Use/Exposure: The current SNOMED CT codes used for this Interoperability Need (Section I-T) are interpretative and ambiguous. LOINC may offer some more granular options to use: (LOINC codes 64572-1; 64570-5; 68536-2; 68535-4; 82769-1; 81228-9)
• Exposure to Violence: HIMSS commends ONC on the inclusion of Violence within the SDOHs listed in the ISA (Section I-S), but suggests expanding the title of the Interoperability Need to include “Exposure to Violence and Abuse”. Inclusion of abuse is more encompassing of patient exposures that may relate to their health, including emotional and sexual abuse. The current LOINC codes for this Interoperability Need also use the term “abuse”.

We appreciate the opportunity to submit comments on the 2017 ISA.  Our comments are intended to recognize the importance of each stakeholder’s role in advancing standards-based interoperability and health information exchange, and ensuring that each domain is invested in overcoming the inherent challenges, while further enhancing health IT’s pivotal role in enabling healthcare transformation. For more information on HIMSS's mission, please see the attached formal cover letter accompanying these comments. 

IHE USA's Comments on Section V, Questions 9-13 of the 2017 ISA

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

IHE USA 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, IHE USA proposes the following standards and characteristics to be captured in the Interoperability Need [see attached table[CK1] ].

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

Proposed Standards and Characteristics for “Representing Birth and Newborn Data Sets”

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

IHE USA 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.” IHE USA 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, IHE USA 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, IHE USA 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, IHE USA 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, IHE USA suggests listing the following test tool: https://www.hl7.org/fhir/validation.html. IHE USA 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, IHE USA 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.

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

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

IHE USA 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, IHE USA 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, IHE USA suggests ONC work with each standard body to identify the best/preferred tool(s) to test interoperability needs listed in ISA.

Lastly, IHE USA 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, IHE USA 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, IHE USA recommends that the aforementioned three specifications be referenced via hyperlink in both Subsections II-P and III-E.

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

New Addition to Subsection II-R (Public Health Reporting) [CK2]

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.

IHE USA recommends that Interoperability Need “Reporting Birth Defects to Public Health Agencies” in Subsection II-R be rephrased and expanded to “Reporting Newborn Birth, Health and Death to Public Health Agencies”. IHE USA has provided the attached information as a suggested expansion of the standards and specifications included in this section.

[CK1]When submitting in the ISA text box, the below table will not be included (to avoid formatting issues). It will only be included in the attachments.

[CK2]This will be submitted in the Comment Box on the Subsection II-R webpage. https://www.healthit.gov/isa/node/1106

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.

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.

• NIST Cybersecurity Framework, Version 1.1: https://www.nist.gov/cyberframework/draft-version-11
  • While HIMSS recognizes that this is a Draft version of the Framework, Version 1.0 currently listed in the ISA, this Draft version provides a lot more detail on the standards and their implementation than Version 1.0.
• US-CERT. Information Sharing Specifications for Cybersecurity https://www.us-cert.gov/Information-Sharing-Specifications-Cybersecurity : 
• HIPAA (Version 5010) Transactions. X12 EDI Transaction Sets. See X12N (Insurance) http://www.x12.org/x12org/docs/editransactions.pdf
  • These are basic HIPAA transactions that are essential to reimbursement. These may be outside of the scope of ISA, with its focus on clinical uses of interoperability. However, if categorization is introduced into Appendix I, this source could be listed as an additional source for consideration for administrative purposes.
• The FDA has documents on Cybersecurity Guidance that should be considered for this Appendix.
  • FDA: “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices: Guidance for Industry and Food and Drug Administration Staff”, October 2, 2014, https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm356190.pdf
  • FDA: “Postmarket Management of Cybersecurity in Medical Devices: Guidance for Industry and Food and Drug Administration Staff”, December 28, 2016, https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm482022.pdf

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.
  • NIST SP 800-50, Building an Information Technology Security Awareness and Training Program
  • Draft NIST SP 800-181 “NICE Cybersecurity Workforce Framework (NCWF), National Initiative for Cybersecurity Education (NICE)”, http://csrc.nist.gov/publications/drafts/800-181/sp800_181_draft.pdf  
• 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.

• NIST Special Publication: 800-63-2. Electronic Authentication Guideline. August 2013 should be removed and replaced with NIST Digital Authentication Guideline, Special Publication 800-63-3.
• NIST 800-53 is listed twice. One iteration should be removed to streamline the list.
• The language “HIPAA Security regulations that are specific to healthcare” seems to be a redundant statement as HIPAA, by definition, is specific to healthcare. HIMSS suggests adjusting the language to “HIPAA Security Rule and Tools”.
• The reference and link to NIST 1800-a-e “Securing Electronic Health Records on Mobile Devices” is incorrect, the correct title should read: NIST 1800-1 “DRAFT Securing Electronic Health Records on Mobile Devices” with the link to: http://csrc.nist.gov/publications/PubsDrafts.html#SP-1800-1

Comments from Quest Diagnostics

Thank you for the opportunity to provide comments.

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.

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 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 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).