Section VI: Questions and Requests for Stakeholder Feedback

Printer Friendly, PDF & Email

*Thank you for all of your feedback. Some responses require additional time and consideration to implement within the ISA and may not yet be reflected in the web or 2018 Reference Edition. ONC will continue to review and make enhancements to the ISA content, functionality and process based on your feedback, and pose new questions for 2018 in Summer 2018.*


Updated questions for the 2017 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. Your feedback on the questions posed below is critical and we encourage answers to be submitted as part of the current comment process.

General

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

17-2. Over the course of 2017, various new functionality has been added to the ISA to make it a more interactive and useful resource (e.g., print-friendly pages, change notifications, advanced search functionality, etc). Are there additional features or functionalities that would enhance the overall experience? 

17-3. An Appendix II has been added that includes educational and informational resources as recommended by the Health IT Standards Committee/2017 ISA Task Force. Are there other topics and/or existing resources which would be helpful to include in this area to increase stakeholder understanding of health IT interoperability issues? 

Section I:  Vocabulary/Code Set/Terminology Standards

17-4. Are there additional Interoperability Needs (with corresponding standards) that represent specific sociodemographic, psychological, behavioral or environmental domains that should be included in the ISA?

Section II:  Content / Structure Standard and Implementation Specifications

17-5. A new interoperability need, Reporting Birth Defects to Public Health Agencies was added to Section II-R: Public Health Reporting.  Please review and provide comment about the accuracy of the attributes.

Section III: Standards and Implementation Specifications for Services

17-6. A new subsection, III-J: Consumer Access/Exchange of Health Information has been added, with four interoperability needs. Please review and provide comment about the accuracy of the attributes. ONC also seeks suggestions for additional consumer access related interoperability needs for inclusion, as well as other known standards or Open APIs that should be listed for existing consumer access interoperability needs. 

Section IV: Models and Profiles

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

Section V: Administrative Standards and Implementation Specifications

17-8. Please review the contents of the new Section V: Administrative Standards and Implementation Specifications and provide comments about the accuracy of any of the listed standards/specifications and attributes. 

17-9. Are there additional administrative-related interoperability needs that should be listed in this section? 

17-10. For Interoperability Need: Health Care Claims or Equivalent Encounter Information for Institutional Claims, feedback is requested on the update process for X12 standards, and how a more streamlined process can be implemented with greater industry engagement. Other improvement ideas are also encouraged to enhance the benefit of the transaction.

17-11. For Interoperability Need: Health Care Claims or Equivalent Encounter Information for Dental Claims, feedback is requested from the dental community on enhancements to the transaction to increase uptake on electronic transactions.

17-12. For Interoperability Need: Enrollment and Disenrollment in a Health Plan, feedback is requested on the use of the adopted enrollment transaction, its value to the industry, and any enhancements that could be made to increase utilization. 

17-13. For Interoperability Need: Electronic Funds Transfer for Payments to Health Care Providers – Professionals and Institutions, are there known barriers to the use of the EFT transaction based on contract concerns, excessive fees, enrollment constraints or other non-EDI issues? 

17-14. For Interoperability Need: Health Care Payment and Remittance Advice, feedback is requested on how the transaction or use by the submitter and/or receiver can be improved to enhance its use and increase the value of the transaction.

17-15. For Interoperability Need: Referral Certification and Authorization Request and Response for Dental, Professional and Institutional Services, feedback is requested to better understand the workflows that will increase adoption of this transaction. 

17-16. For Interoperability Need: Operating Rules to Support Eligibility and Claim Status Transactions (Phase II), feedback is requested on: a) the process for creating the operating rules; b) current adoption of the batch vs. real time rules for both providers and health plans; c) need for other operating rules that will improve adoption of the transactions. 

17-17. For Interoperability Need: Operating Rules for Electronic Funds Transfer (EFT) and Electronic Remittance Advice (ERA) for Payments and Reconciliation (Phase III), feedback is requested on other operating rules that will increase adoption and/or use of the standards for EFT and ERA.

 



Questions from December, 2016 ISA publication. 

As with the previous Interoperability Standards Advisories (ISA), posing questions has served as a valuable way to prompt continued dialogue with stakeholders to improve the ISA. Your feedback on the questions posed below is critical and we encourage answers to be submitted as part of the current public comment process. 

General

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?

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?

3. For each standard and implementation specification there are six assessment characteristics, for which detailed information has been received and integrated.  However, some gaps remain.  Please help complete information that is missing or noted “feedback requested”.  Additionally, assessing the adoption and maturity of standards is an ongoing process, so please continue to provide feedback if you believe something has changed or is not correct.

4. The table beneath the standards and implementation specifications includes limitations, dependencies, and preconditions.  Please comment on accuracy and completeness; where information gaps remain, forward applicable content.

5. For the Implementation Maturity characteristic for the standards and implementation specifications, ONC plans to publish a link, where available, to published maturity assessments based on known published criteria.  Please help identify any publications that are publicly available and provide the hypertext links to those resources.

6. For the Adoption Level characteristic for the standards and implementation specifications, ONC plans to include reference annotations or links to publicly available documentation known about adoption levels for listed standards.   Please help identify any publications that are publicly available and provide the hypertext links to those resources.

7. For the Test Tool Availability characteristic for the standards and implementation specifications, ONC plans to publish references, where available, a to the publicly available test tool. Please help identify any publicly available test tools.

Section I:  Vocabulary/Code Set

8. Are there additional Social Determinant Interoperability Needs with corresponding standards that should be included in the ISA?

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.

Section II:  Content / Structure

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.

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

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

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

Section III: Standards and Implementation Specifications for Services

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

Section IV: Models and Profiles

15. Is the traditional 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 profiles that should be listed? 

Appendix I: Sources of Security Standards

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

 

Comment

Permalink

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,

Permalink

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. 

Permalink

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”

Type

Standard

Implementation/

Specification

Standards

Process

Maturity

Implementation

Maturity

Adoption

Level

Federally

Required

Cost

Test Tool

Availability

Standard

LOINC®

Final

Production

 

No

Free

N/A

Standard

SNOMED CT®

Final

Production

 

No

Free

N/A

Limitations, Dependencies, and Preconditions for Consideration

Applicable Value Set(s) and Starter Set(s)

Required section specification in IHE NDS profile:

 

LOINC® code 57074-7

Labor and Delivery Process

LOINC® code 57075-4

Newborn Delivery Info from Newborn

LOINC:XXAdmissionPhysicalExam

Admission Physical Exam

LOINC® code 61145-9 (or 18776-5)

Patient Plan of Care

LOINC® code 10184-0

Hospital Discharge Physical

LOINC® code 11535-2

Hospital Discharge DX

LOINC® code 61148-3

Intake and Output

 

Some recommended section specification in IHE NDS profile (particularly from mom’s coded social history and others):

SNOMED® code 229819007

Smoking

SNOMED® code 160573003

ETOH (Alcohol) Use

SNOMED® code 364393001

Diet

SNOMED® code 425400000

Toxic Exposure

SNOMED® code 363908000

Drug Use

LOINC® code 11450-4

Problem List - Reported

                 

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.

Type

Standard

Implementation/

Specification

Standards

Process

Maturity

Implementation

Maturity

Adoption

Level

Federally

Required

Cost

Test Tool

Availability

Standard

HL7 Version 2.5.1 Implementation Guide: Birth & Fetal Death Reporting, Release 1 (US Realm)

Balloted Draft

Pilot

Image removed.

No

Free

Yes,

CDA Guideline Validation from NIST

Standard

HL7 CDA® R2 Implementation Guide: Ambulatory Healthcare Provider Reporting to Birth Defect Registries, Release 1 - US Realm

Balloted Draft

Pilot

Image removed.

No

Free

Yes,

CDA Guideline Validation from NIST

Implementation Specification

IHE Quality, Research and Public Health Technical Framework Supplement 10 Birth and Fetal Death Reporting-Enhanced (BFDR-E)

Balloted Draft

Pilot

Image removed.

No

Free

Yes

[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

Permalink

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.

Permalink

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Permalink

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.

Permalink

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

Permalink

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

Permalink

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

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

Permalink

General

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

Response: In general NCPDP does not use this document.

 

17-2. Over the course of 2017, various new functionality has been added to the ISA to make it a more interactive and useful resource (e.g., print-friendly pages, change notifications, advanced search functionality, etc). Are there additional features or functionalities that would enhance the overall experience?

Response: Consolidating some of the information as it pertains to NCPDP as indicated above.

 

17-3. An Appendix II has been added that includes educational and informational resources as recommended by the Health IT Standards Committee/2017 ISA Task Force. Are there other topics and/or existing resources which would be helpful to include in this area to increase stakeholder understanding of health IT interoperability issues?

Response: N/A

Section I: Vocabulary/Code Set/Terminology Standards

17-4. Are there additional Interoperability Needs (with corresponding standards) that represent specific sociodemographic, psychological, behavioral or environmental domains that should be included in the ISA?

Response: N/A

Section II: Content / Structure Standard and Implementation Specifications

17-5. A new interoperability need, Reporting Birth Defects to Public Health Agencies was added to Section II-R: Public Health Reporting. Please review and provide comment about the accuracy of the attributes.

Response: N/A

Section III: Standards and Implementation Specifications for Services

17-6. A new subsection, III-J: Consumer Access/Exchange of Health Information has been added, with four interoperability needs. Please review and provide comment about the accuracy of the attributes. ONC also seeks suggestions for additional consumer access related interoperability needs for inclusion, as well as other known standards or Open APIs that should be listed for existing consumer access interoperability needs.

Response: N/A

Section IV: Models and Profiles

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

Response: N/A

Section V: Administrative Standards and Implementation Specifications

17-8. Please review the contents of the new Section V: Administrative Standards and Implementation Specifications and provide comments about the accuracy of any of the listed standards/specifications and attributes.

Response: Refer to comments provided in Section V: Administrative Standards and Implementation Specifications

 

17-9. Are there additional administrative-related interoperability needs that should be listed in this section?

Response: No

 

17-10. For Interoperability Need: Health Care Claims or Equivalent Encounter Information for Institutional Claims, feedback is requested on the update process for X12 standards, and how a more streamlined process can be implemented with greater industry engagement. Other improvement ideas are also encouraged to enhance the benefit of the transaction.

Response: NCPDP and ASC X12 recently participated in the National Committee on Vital and Health Statistics’ (NCVHS) Workshop on the Predictability Roadmap for Updating and Adopting Standards and Operating Rules. NCVHS has not yet issued their initial summary report from the workshop but we encourage ONC to look to the outcomes from the NCVHS effort for ways to streamline the overall process.

 

17-11. For Interoperability Need: Health Care Claims or Equivalent Encounter Information for Dental Claims, feedback is requested from the dental community on enhancements to the transaction to increase uptake on electronic transactions.

Response: N/A

 

17-12. For Interoperability Need: Enrollment and Disenrollment in a Health Plan, feedback is requested on the use of the adopted enrollment transaction, its value to the industry, and any enhancements that could be made to increase utilization.

Response: N/A

 

17-13. For Interoperability Need: Electronic Funds Transfer for Payments to Health Care Providers – Professionals and Institutions, are there known barriers to the use of the EFT transaction based on contract concerns, excessive fees, enrollment constraints or other non-EDI issues?

Response: NCPDP has a Work Group that supports pharmacy industry needs involving EFT transactions. At this time, NCPDP has not received any feedback on barriers to using EFT transactions.

 

17-14. For Interoperability Need: Health Care Payment and Remittance Advice, feedback is requested on how the transaction or use by the submitter and/or receiver can be improved to enhance its use and increase the value of the transaction.

Response: Pharmacy industry utilizes this transaction regularly. NCPDP has a designated Work Group to address any concerns and/or needs from its members. NCPDP, in conjunction with ASC X12 has a procedure that documents how this transaction supports the NCPDP real-time transactions.

 

17-15. For Interoperability Need: Referral Certification and Authorization Request and Response for Dental, Professional and Institutional Services, feedback is requested to better understand the workflows that will increase adoption of this transaction.

Response: N/A

 

17-16. For Interoperability Need: Operating Rules to Support Eligibility and Claim Status Transactions (Phase II), feedback is requested on: a) the process for creating the operating rules; b) current adoption of the batch vs. real time rules for both providers and health plans; c) need for other operating rules that will improve adoption of the transactions.

Response: Refer to response above (V-E: Operating Rules to Support Administrative Transactions)

 

17-17. For Interoperability Need: Operating Rules for Electronic Funds Transfer (EFT) and Electronic Remittance Advice (ERA) for Payments and Reconciliation (Phase III), feedback is requested on other operating rules that will increase adoption and/or use of the standards for EFT and ERA.

Response: NCPDP has not received comments from its members that would affect adoption and/or use of either EFT and/or ERA.

Permalink

On behalf of the membership of the Pharmacy Health Information Technology Collaborative (Collaborative), we are pleased to submit comments for the advanced 2018 Interoperability Standards Advisory comment period.

The Collaborative has been involved with the federal agencies, including the Office of the National Coordinator (ONC), developing the national health information technology (HIT) framework since 2010. The Collaborative is supportive of the proposed standards for clinical health IT interoperability purposes.

Pharmacists provide patient-centered care and services, maintain various secure patient care records, and as part of the integrated health care team, they are directly involved with other health care providers and patients in various practice settings. Pharmacists are users of health IT and are especially supportive of interoperability standards incorporating HL7, SNOMED CT, LOINC, RxNorm, and NCPDP SCRIPT, and NCPDP Real Time Formulary and Benefits (currently under development). The Collaborative supports use of these particular standards which are important to pharmacists for allergy reactions, immunization historical and administered, immunization registry reporting, medications, medication allergies, patient problems, smoking status, reporting to public health agencies, clinical decision support services/knowledge artifacts, drug formulary checking, and electronic prescribing (including new versions).

The Collaborative recommends that consolidated CDA (C-CDA) Release 1.1 and 2.0 be included for the summary care record. For pharmacists providing patient care services, there have been joint NCPDP and HL7 standards development[1] and implementation guides work using C-CDA Release 1.1 and current work using C-CDA release 2.1 for Pharmacist eCare Plan[2].

[1] http://ncpdp.org/NCPDP/media/pdf/Pharmacist-eCare-Plan.pdf, accessed November 8, 2017.

[2] https://www.healthit.gov/techlab/ipg/node/4/submission/1376, accessed November 8, 2017.

The attached document are our comments regarding changes made to the final 2017 Interoperability Standards Advisory and the advance request for feedback regarding the 2018 Interoperability Standards Advisory that is in the development process. On behalf of the Pharmacy HIT Collaborative, thank you again for the opportunity to comment on the advanced 2018 Interoperability Standards Advisory.

 

Permalink

On behalf of American Medical Association (AMA) I appreciate the ability to comment on ONC's questions and requests for stakeholder feedback regarding the Interoperability Standards Advisory (ISA).

 

Section V: Administrative Standards and Implementation Specifications

17-8. Please review the contents of the new Section V: Administrative Standards and Implementation Specifications and provide comments about the accuracy of any of the listed standards/specifications and attributes.

The Administrative Standards Section requires introductory material that indicates the general applicability of the law, the regulatory authority, and the parties required to meet compliance.  The HIPAA laws were created with completely different goals and have requirements that differ greatly from EHR regulations, making the insertion of transactional information potentially confusing and/or misleading without appropriate overview. CMS has considerable information on their website that provides introduction to this content.  Important pieces to cover are:

  • Covered Entities
  • Business Associates
  • General Rules applicable to all administrative standards
    • All covered entity requirements (pursuant to 45 CFR 162.923)
    • Health plan requirements (pursuant to 45 CFR 162.925)
  • Enforcement (Both the potential for the secretary under the law and the active enforcement using the ASETT Resource maintained by HHS)


Additionally, the subsections for each transaction would be greatly enhanced with some general information as to the purpose of each transaction.  Currently, the page simply lists technical content and information about when and how it was developed.  In order to truly provide appropriate overview, a short overview and potential link to relevant information would be appropriate.  CMS has an overview site with information that can be leveraged at https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/Transactions/TransactionsOverview.html.

  • Use of the term standard throughout is not consistent with the governmental definition.  In the context of HIPAA, ASC X12 5010 is not a standard; it is a version of the entire set of standards (implementation guides for the transactions are the standards).  However, 5010 is the “standard” as it applies to ANSI, but is defined differently in the regulation. It is likely best for this resource to be consistent with the statutory definition as mandated in the HIPAA regulations.

837P Professional Claims

  • We believe that the statement that EHR content duplicates information in administrative claims information is a bit of an overstatement/mischaracterization. There may be some overlap in basic patient demographic information, but claims data is used for payment and is revenue-cycle-oriented – not clinical – in nature.
  • The language about testing seems a bit misleading.  If testing is conducted during implementation, then it is not really a test.  Testing by nature would occur before “implementation” as a standard.  As it is, there is no testing that occurs in advance of standards being named in regulation. We would also note that links to ASETT under “Test Tool Availability” appear to be broken throughout the ISA.

Eligibility for a Health Plan (Benefits and Coverage) – Request and Response (270/271)
 

  • In order to avoid confusion about the function of the transaction, we recommend listing the formal title of the transaction, which is Health Care Eligibility Benefit Inquiry and Response.  The current heading could be misinterpreted to be a transaction used by patients or providers prior to becoming subscribers/network members of a health plan.

Health Care Attachments to Support Claims, Referrals and Authorizations: 

The X12N 278 - Health Care Services Request for Review and Response (006020X315) transaction is listed as not being federally required. While this is true, the 5010 version of the Health Care Services Request for Review and Response is in fact mandated under federal law and regulation.  Despite this mandate, a large majority of industry participants are not using the transaction, which may be due to the lack of an attachment transaction.

Additionally, this section requires a significant amount of introductory material to help people accessing the site understand the various standards listed in the chart.

Global question for Section V: What is the source for the adoption level of the various standards and operating rules? We assume that the CAQH Index is being used for the adoption level of the standards; if this is correct, it would be appropriate to reference that source. However, the CAQH Index does not evaluate operating rule adoption, so we are curious how this is being determine.

17-10. For Interoperability Need: Health Care Claims or Equivalent Encounter Information for Institutional Claims, feedback is requested on the update process for X12 standards, and how a more streamlined process can be implemented with greater industry engagement. Other improvement ideas are also encouraged to enhance the benefit of the transaction.

The current X12 update process does not satisfactorily meet the needs of the industry to improve and update transactions in a manner that is expeditious, transparent, and adequately representative of all industry stakeholders.  The X12 process is not sufficiently agile to satisfactorily respond to the quickly evolving needs of the health care industry.  Specifically, the updated 5010 version of the initially mandated 4010 HIPAA transactions was named in regulation in 2008.  Since this date, there has yet to be a mandated update to the transaction sets. This has led many providers, payers, and other industry participants to develop work arounds or to stifle innovation that would help advance the industry.

In addition to the lack of timely updates, the X12 transaction development and approval process fails to facilitate adequate inclusion and representation of all industry participants.  The 7030 transaction set, which is presumably the next version for which X12 will seek a regulatory mandate, is currently undergoing public review.  This review process is hindered and compromised by X12’s reluctance to release the implementation guides under review in an easily accessible and digestible manner, primarily due to intellectual property concerns.  Regardless of the justification, the obstacles interfering with easy access to the draft guides have limited the “public” review to the same exact industry stakeholders willing to commit significant time, resources, and finances to participating in X12 technical transaction development. Essentially, the entities that created the draft guides for review are the exact same parties that are now reviewing and commenting on the materials during the “public” comment process.  Due to the significant resources needed to effectively participate in the X12 technical standard development process, physicians and their representatives often cannot justify the enormous cost and time needed to participate, thereby creating an atmosphere that fails to represent physician views and is primarily driven by health insurers, vendors, and clearinghouses (despite HIPAA’s initial goal of protecting physician time and resources from burdensome administrative activities).   

Once a new guide is recommended for publication and mandated under regulation, physicians and health insurers are required to make significant, costly system changes to incorporate the new transaction sets.  For example, CMS has indicated that the transition from version 4010 to version 5010 of the X12 transactions took 5 years and cost the agency approximately $700 million.  X12 has recently transitioned to a licensed system of collecting money from industry participants utilizing their guides.  As a result of this transition and the need to justify the annual licensure fees to physicians and health plans, X12 should consider developing a system that allows yearly changes to be made and included in the annual updates that are promised under their licensure agreements. 

17-13. For Interoperability Need: Electronic Funds Transfer for Payments to Health Care Providers – Professionals and Institutions, are there known barriers to the use of the EFT transaction based on contract concerns, excessive fees, enrollment constraints or other non-EDI issues?

The main issues limiting the usage of the standard EFT transaction were implementation of alternative payment methods, such as virtual credit cards, and the imposition of improper fees on the EFT standard.  The recent guidance on EFT and virtual credit cards included in the CMS FAQs (https://questions.cms.gov/faq.php?id=5005&rtopic=1851) offers significant clarification and enumeration of provider rights related to electronic payment and should support increased adoption of EFT. At this stage, adequate provider education about their specific rights and the rules placed on insurers and vendors by this guidance will be important.  Additionally, the development of an audit or other improved enforcement mechanisms to ensure that health plans are adhering to standards and operating rules will be essential.  

Another frequently reported barrier to providers’ adoption of standard EFT is the burdensome, tedious enrollment process. Providers must enroll in EFT separately with each health plan, and sometimes even with different products for the same health plan. This is extremely time consuming and administratively burdensome. Multi-payer ERA and EFT enrollment systems, such as CAQH’s EnrollHub, can help reduce provider burdens and facilitate increased adoption of EFT.

17-14. For Interoperability Need: Health Care Payment and Remittance Advice, feedback is requested on how the transaction or use by the submitter and/or receiver can be improved to enhance its use and increase the value of the transaction.

The recent guidance on EFT and ERA in the CMS FAQs (https://questions.cms.gov/faq.php?id=5005&rtopic=1851) offers significant clarification and enumeration of provider rights related to electronic payment and remittance advice and should support increased adoption of ERA. At this stage, adequate provider education about their specific rights and the rules placed on insurers and vendors by this guidance will be important.  Additionally, the development of an audit or other improved enforcement mechanisms to ensure that health plans are adhering to standards and operating rules will be essential.  

Providers often cite the burdensome, tedious enrollment process as a barrier to ERA adoption. Providers must enroll in ERA and EFT separately with each health plan, and sometimes even with different products for the same health plan. This is extremely time consuming and administratively burdensome. Multi-payer ERA and EFT enrollment systems, such as CAQH’s EnrollHub, can help reduce provider burdens and facilitate increased adoption of ERA.

In addition, lack of health plan compliance with the ERA standard discourages more widespread adoption of the transaction. For example, some health plans do not provide balanced ERAs, despite the fact that this represents noncompliance with the standard. Other compliance issues include not following the required ratio of one ERA to one EFT and inconsistent/noncompliant use of CARCs and RARCs (reason codes for payment reductions or denials).

Lack of full vendor automation of the ERA transaction also hinders adoption. To reap the full efficiency and return on investment of ERA, provider vendor systems should support auto-posting of remittance advice and automated reconciliation/reassociation with EFT payments. However, these functionalities are not included in many vendor systems today.

17-15. For Interoperability Need: Referral Certification and Authorization Request and Response for Dental,

Professional and Institutional Services, feedback is requested to better understand the workflows that will increase adoption of this transaction.

Industry adoption of the Health Care Services Review – Request for Review and Response is abysmally low – 18% according to the most recent CAQH Index – despite the fact that this is a HIPAA-mandated transaction. Given the fact that the authorization process is burdensome and costly for both providers and health plans, increased adoption of this transaction could offer significant administrative savings for the industry. One frequently cited barrier to adoption of the transaction is the lack of a mandated electronic clinical attachment standard. Without a standard mechanism to electronically exchange supporting clinical documentation between providers and health plans, the authorization process remains relegated to manual processes, such as telephone calls, faxes, and mail. While proprietary health plan portals may offer some advantages over these traditional methods, they require unique logins/passwords for each plan, as well as extensive re-entry of data from the EHR – both of which are burdensome to providers. Health plans’ investments in their existing portals represent another substantial barrier to widespread adoption of the X12 278 transaction.

Other challenges to increased adoption of the transaction relate to its current usage (or misusage, as it may be). Health plans often inappropriately use the “pended” status message in response to authorization requests, even when no authorization is required, the authorization must be submitted to a third-party utilization management vendor, or no additional information is needed for processing the request. In addition, health plans often return a message of “pended” and then request that the provider use another method of communication – phone, fax, portal – to complete the authorization. Not only does this practice divert the authorization workflow from electronic data interchange, but it discourages any use of the X12 278 transaction by providers.

Finally, providers face significant challenges in determining what services and procedures require authorization. As long as there remains a lack of transparency around the services requiring authorization and the documentation providers need to submit to health plans to receive a determination, adoption of the transaction will remain low, as providers will chose to call the insurer to obtain this information.

17-16. For Interoperability Need: Operating Rules to Support Eligibility and Claim Status Transactions (Phase II), feedback is requested on: a) the process for creating the operating rules; b) current adoption of the batch vs. real time rules for both providers and health plans; c) need for other operating rules that will improve adoption of the transactions.

The operating rules represent an important supplement to the named standard transactions.  As a result of their status as a supplement to the X12 transactions, it is best to include information concerning their applicability and the rights/responsibilities created therein with their corresponding HIPAA standard in the appropriate tab of the ISA.  As new transactions are mandated under regulation, corresponding operating rules will be extremely important to ensure that they meet the business needs of industry participants. 

There is real value to the real-time requirements for the eligibility and claim status transactions, as getting this information quickly is of critical importance to providers. Requiring responses to eligibility and claim status requests in real time, as required by the operating rule, is extremely beneficial to providers.

Up until recently, CAQH CORE has undertaken operating rule development strictly according to regulatory direction. It would be beneficial to the entire industry if CAQH CORE would periodically assess the need for additional operating rules and undertake rule development without a government requirement. This would allow a more agile response to emerging industry needs. To its credit, CAQH CORE recently has done just that by establishing a Prior Authorization Subgroup to develop additional operating rules for the authorization transaction.

17-17. For Interoperability Need: Operating Rules for Electronic Funds Transfer (EFT) and Electronic Remittance Advice (ERA) for Payments and Reconciliation (Phase III), feedback is requested on other operating rules that will increase adoption and/or use of the standards for EFT and ERA.

The recent guidance on EFT and virtual credit cards included in the CMS FAQs (https://questions.cms.gov/faq.php?id=5005&rtopic=1851) offers significant clarification and enumeration of provider rights related to electronic payment and should support increased adoption of EFT. At this stage, adequate provider education about their specific rights and the rules placed on insurers and vendors by this guidance will be important.  To establish additional provider protections for electronic payment, CAQH CORE could consider incorporating some of the concepts in the FAQs – e.g., providers’ right to refuse payment via virtual credit cards, providers’ right to request and receive standard EFT with no health plan or vendor fees – into future operating rules. It would also be beneficial to address security of providers’ EFT enrollment information in a future operating rule, as we have learned of cases where providers’ bank routing information is changed without their knowledge or consent. An operating rule addressing EFT enrollment data security could help deter this type of criminal activity. Additionally, the development of an audit or other improved enforcement mechanisms to ensure that health plans are adhering to standards and operating rules will be essential.  

It should also be noted that CAQH CORE has created Phase IV operating rules for the authorization, claim, employee premium payment, and health plan enrollment/disenrollment transactions. These rules are voluntary and not mandated for the industry, but they should be listed in the ISA. CAQH CORE does offer certification for entities that are voluntarily complying with the Phase IV operating rules.

 

Permalink

We are delighted to see the addition of Social, Psychological, and Behavioral Data content in the 2017 ISA and concur with all of the recommendations for use of LOINC for representing these observations.

Permalink

  • We live in a mobile and global world. Our health data need to reflect our mobile, instant, connected world. It is our right to access and own the results of our medical care instantaneously for our own longitudinal record, and shared with whomever we please.
  • We as patients should own our health information and digital results of our care free of charge. We already paid for them by paying for the medical service through our insurance premiums, copays, deductibles, and taxes.
  • We need our electronic health record to follow us so we are free to receive care wherever we choose. Through cooperation and non-discrimination, we can have one, single, mobile, longitudinal record, not multiple, separate portals from each provider, difficult to access.
  • Innovation needs to allow for compatibility of our health records with all technology vendors, and for the ability to analyze, aggregate, and readily share health data.
  • The standard needs to be that the electronic record is provided instantaneously, mobile, portable, compatible with all applications in the repository of our choice, and allowing for state-of-the-art and future technologies.
  • We need a transparent patient-centered record with full visibility into all our health records – labs, radiology, prescription fills, and care plans – to ensure the best, timely, informed, and efficient care.
  • Likewise, we need transparency into the quality, performance, and cost of care. With access to these metrics, we can shop for physicians and medical services at a competitive marketplace, not be restricted to certain providers, and hold both patients and providers accountable for performance.
  • With data driven choice, we can utilize sites similar to Yelp, Amazon, and OpenTable to shop, assess quality, and book our care globally. When aggregated health data is readily available for comparative quality, cost, research, and analysis, the cost of care lowers and the quality improves.
  • Providers and their software vendors need to allow for open technology development, leveraging existing state-of-the-art security and patient safety measures like thumbprint, voice, or facial recognition and device verification. The electronic medical record should be transactional, mobile, and secure like mobile banking is in the financial industry. A patient-centered longitudinal record gives the patients the choice of when, how, with whom, and to what extent their own medical records can be shared.
Permalink

Push Patient-Generated Health Data into Integrated EHR

We live in a mobile and global world. Our health data need to reflect our mobile, instant, connected world. It is our right as patients to access and own the results of our medical care instantaneously for our own longitudinal record, and shared with whomever we please. We as patients should own our health information and digital results of our care free of charge. We already paid for them by paying for the medical service through our insurance premiums, copays, deductibles, and taxes.

We should be allowing for the design of the future rather than addressing the dysfunction of today. In doing so, this will empower the consumer to control their own health information so they can make better choices about their health.

This EHR should be readily available by the patient and secured by the patient’s choice of password combined with third party verification, biometric or facial recognition, or the state-of-the-art technology as used in other sectors.

Providers and their software vendors need to allow for open technology development, leveraging existing state-of-the-art security and patient safety measures like thumbprint, voice, or facial recognition and device verification. The electronic medical record should be transactional, mobile, and secure like mobile banking is in the financial industry. A patient-centered longitudinal record gives the patients the choice of when, how, with whom, and to what extent their own medical records can be shared.

The patient receipt of their own health care record should be automatic. We need to eliminate the requirement for the patient to ask for copies of their information and copies of their films. A copy or photo of an image or film should be automatically provided to the patient. The patient should not have to go to a separate location in the hospital, fill out a separate form, and then wait up to 30 days to receive their information. Those 3 things collectively inhibit timely and quality care. We can achieve timely and the best of quality care if we provide the patient with immediate access to his or her own patient-owned integrated EHR.

We need our electronic health record to follow us so we are free to receive care wherever we choose. Through cooperation and non-discrimination, we can have one, single, mobile, longitudinal record.

Multiple, separate portals from each provider, difficult to access, each acting as an island unto itself, is a broken way for a physician to provide optimal health care. It is onerous, expensive, and redundant. It is broken. It does not work.

Patients need ownership rights to their own health information and data, and ability to have an aggregated, integrated, longitudinal, patient-owned electronic health record. That EHR should be readily available to them through their mobile devices. Hospitals/providers should have open API’s, and images, films, EKG’s, CT’s, MRI’s, radiology, open notes regarding discharge and care should be readily accessible in a shared, open architecture for other institutions on behalf of the patient. The EHR should also have available linkage to the patient’s pharmacy for populating a history of prescription fills.

We can greatly improve the quality of health care and provide timely, life saving measures to patients in emergent care with informed physicians and patients, family and caregivers alike. We can substantially reduce costs of health care by eliminating redundancies in providing care across institutions. This common sense approach can, in fact, be readily done with today’s technology, as evidenced in almost every industry other than health care.

Digital copies of new tests and electronic files should be available immediately in the patient’s own designated banked account. As lab results, physician notes, and tests become electronically available to the physician and provider/facility, a copy should instantaneously be populated into the patient’s own, integrated and aggregated, patient-owned, “banked” EHR.

The patient’s integrated EHR should be transactionally populated, much like the financial community, where each digital transaction is shown in the patient’s “banked account.” It should be integrated and aggregated through the patient’s applications of choice, much like Mint or Quicken aggregate financial transactions. Wherever the patient receives care, the patient receives that information into the patient’s “banked account.” Categories such as labs can be dated and aggregated, and trends and results can then easily be charted by the patient and the patient’s care providers.

For example, as a test result or x-ray is read and becomes digitally available to the institution, the patient should be able to have the results and findings reported electronically to their own application and site of choice. Eventually, in addition to lab reports and radiology reads, relevant photos and images should be included in the patient-owned and integrated EHR.

Near term, providers and patients alike (especially emergency departments) need readily available, shared access to existing images produced for patients. Imaging sharing should be open such that any institution could pull up an image no matter where it is, and that access should be provided across institutions for the patient.

We should eliminate the need for the patient to fill out a form to get access to their information. It should be instantaneously populated, versus up to 30 days. Thirty days is not an acceptable time frame. Those 30 days greatly diminish the quality of care.

Patients should be able to secure what they want to keep private, and readily share what they choose to share with other providers, physicians, family members, caregivers. Patients should be able to determine the level of privacy and to whom they want to share their own integrated EHR. Patients should be able to choose to “time out” that sharing, similar to a feature of the Find My Friends and Life360 apps.

Innovation needs to allow for compatibility of our health records with all technology vendors, and for the ability to analyze, aggregate, and readily share health data.

The standard needs to be that the electronic record is provided instantaneously, mobile, portable, compatible with all applications in the repository of our choice, and allowing for state-of-the-art and future technologies.

We need a transparent patient-centered record with full visibility into all our health records – labs, radiology, prescription fills, and care plans – to ensure the best, timely, informed, and efficient care.

Likewise, we need transparency into the quality, performance, and cost of care. With access to these metrics, we can shop for physicians and medical services at a competitive marketplace, not be restricted to certain providers, and hold both patients and providers accountable for performance.

The patient needs to know per drug administered the cost to the patient, itemized by the care facility. For instance the cost of Zantac administered from an ER versus the acceptable range of costs versus over the counter. The billing system of the hospital needs to be aligned with the patient’s instantaneous care as it’s populated, so that the patient has full transparency into the costs being charged for services rendered. Additionally, when a procedure like an MRI can be done electively, the cost of that MRI other than under emergent care where available, should be provided, and the price range of cost for the patient choice. Any out-of-network cost should be revealed to the patient upfront.

Cost data should be aligned with the EHR and be visible to the patient and physician. Physicians and patients alike are blind as to the ultimate cost of procedures. They are blind to what is “in network” and “out of network.” The “out of network charges are additional charges that occur unknowingly to patients and can be gamed by providers. To ultimately give the patient freedom of knowledge and choice, we need to strive for a near-term goal of attaching the cost to the insurer and the cost to the patient as it is aligned with the care provided for the patient, real time to the doctor and to the patient when available.

With data driven choice, we can utilize sites similar to Yelp, Amazon, and OpenTable to shop, assess quality, and book our care globally. When aggregated health data is readily available for comparative quality, cost, research, and analysis, the cost of care lowers and the quality improves.

The Hippocratic oath is to “do no harm.” Today’s EHR software companies and providers are causing harm to the patient by using protectionism and misusing HIPAA, blocking the patient from this readily available, integrated, longitudinal record of his/her health. Let’s get it done. The technology is all here. It is being used cost effectively in almost every other industry. It would drastically change the economics of health care for the better and greatly improve the quality of care to patients, as well as the quality of the jobs of our health professionals. Let’s do the right thing and make a systemic commitment to enable the complete, integrated EHR and empower the patient and give the patient freedom of choice.

Patient Exchanging Secure Messages with Care Providers

Patients and providers should be able to have two-way communication through email, Facetime or Skype, texting, photos, videos, and phone calls. New communication technology conduits should be readily adopted for such two-way communication, rather than requiring a regulation or legislation to allow people to communicate.

The patient should be able to choose to communicate through a text or email with his or her provider and FaceTime where appropriate. Like in the legal world, providers may have a disclaimer regarding confidentiality and security.

The patient’s own choice of privacy and security should supersede any institutional requirements. The patient should be able to opt in for deeper levels of security but should automatically be able to choose to share their fully integrated electronic file where they deem fit. The integrated file should be automatically available for emergency care.

The current software allows for physician notes to be viewable to the patients themselves. Patients should have readily available access to these physician notes. In addition, patients’ ability to edit and provide comments to the physician notes would be an important link to their longitudinal care. Better yet, patient edited and co-produced notes with their providers may be optimal. Most importantly, the collective needs to allow for patient participation and communication two-way with the patient’s integrated EHR.

View, Download, and Transmit Data from EHR

Much like the financial community, patients should be able to download their medical data. If any provider or the patient himself wants to view the integrated lab tests and look at a five or ten year horizon, he/she should be able to readily download the data and compare and contrast changes. They should stored in machine-readable form to allow for data analytics by care providers, caregivers, patients, and for research (where the patient has chosen to opt in).

HHS should seek to remove blockage and process burdens on patients under HIPAA that may limit patient access to their health information based upon patient choice of levels of privacy. See our comments above regarding instantaneous population to the digital record and eliminating signing a form for access and waiting 30 days.

Patients should be able to view their complete patient record, including pricing, tests, films, lab results, and health care provider notes. The EHR should provide affiliated charges and pricing. Price and cost transparency, outside of emergency situations, should be provided upfront to the patient prior to rendering services. As patients access the EHR, they should access the range of pricing from the institution compared to other comparable price ranges for a similar procedure elsewhere.

Health care providers should be able to view their patient’s aggregated/comprehensive patient electronic health record. Health care providers should have a two-way ability to communicate via email, phone, and text with each other regarding patient care.

We support the OpenNotes movement for physician notes to be provided attached to the patient EHR and two-way communication to be allowed for patient engagement.

Remote Patient Authorization and Submission of EHR Data for Research

Patients should own their health information and be able to easily create a longitudinal health record that they can use or share with health care providers, caregivers, researchers and others.

Patient information should not automatically be used for research or brokered even if it is “anonymized.” Patients should have the choice to opt in to any broad or specific medical research, and the institution should not be able to broker the patient’s data without the patient having full transparency and the choice to opt in to having their information brokered and shared. Patients should be remunerated for the per-patient access to such information if the researcher and the institution are being compensated for delivery of such information.

The patient should be fully informed of wherever the institution sends the patient data, even if they claim it is anonymized. The patient should also be informed of the transactional brokerage of their health data and the extent to which it is forwarded to pharmaceutical companies and their subsidiaries or contracted firms, anonymized or not.

If the institution is being paid for those data, the patient should have full transparency into payments the provider or researcher received for his or her medical record. Remunerations should be made to the patient for the use of such data.

Permalink

Push Patient-Generated Health Data into Integrated EHR

We live in a mobile and global world. Our health data need to reflect our mobile, instant, connected world. It is our right as patients to access and own the results of our medical care instantaneously for our own longitudinal record, and shared with whomever we please. We as patients should own our health information and digital results of our care free of charge. We already paid for them by paying for the medical service through our insurance premiums, copays, deductibles, and taxes.

We should be allowing for the design of the future rather than addressing the dysfunction of today. In doing so, this will empower the consumer to control their own health information so they can make better choices about their health.

This EHR should be readily available by the patient and secured by the patient’s choice of password combined with third party verification, biometric or facial recognition, or the state-of-the-art technology as used in other sectors.

Providers and their software vendors need to allow for open technology development, leveraging existing state-of-the-art security and patient safety measures like thumbprint, voice, or facial recognition and device verification. The electronic medical record should be transactional, mobile, and secure like mobile banking is in the financial industry. A patient-centered longitudinal record gives the patients the choice of when, how, with whom, and to what extent their own medical records can be shared.

The patient receipt of their own health care record should be automatic. We need to eliminate the requirement for the patient to ask for copies of their information and copies of their films. A copy or photo of an image or film should be automatically provided to the patient. The patient should not have to go to a separate location in the hospital, fill out a separate form, and then wait up to 30 days to receive their information. Those 3 things collectively inhibit timely and quality care. We can achieve timely and the best of quality care if we provide the patient with immediate access to his or her own patient-owned integrated EHR.

We need our electronic health record to follow us so we are free to receive care wherever we choose. Through cooperation and non-discrimination, we can have one, single, mobile, longitudinal record.

Multiple, separate portals from each provider, difficult to access, each acting as an island unto itself, is a broken way for a physician to provide optimal health care. It is onerous, expensive, and redundant. It is broken. It does not work.

Patients need ownership rights to their own health information and data, and ability to have an aggregated, integrated, longitudinal, patient-owned electronic health record. That EHR should be readily available to them through their mobile devices. Hospitals/providers should have open API’s, and images, films, EKG’s, CT’s, MRI’s, radiology, open notes regarding discharge and care should be readily accessible in a shared, open architecture for other institutions on behalf of the patient. The EHR should also have available linkage to the patient’s pharmacy for populating a history of prescription fills.

We can greatly improve the quality of health care and provide timely, life saving measures to patients in emergent care with informed physicians and patients, family and caregivers alike. We can substantially reduce costs of health care by eliminating redundancies in providing care across institutions. This common sense approach can, in fact, be readily done with today’s technology, as evidenced in almost every industry other than health care.

Digital copies of new tests and electronic files should be available immediately in the patient’s own designated banked account. As lab results, physician notes, and tests become electronically available to the physician and provider/facility, a copy should instantaneously be populated into the patient’s own, integrated and aggregated, patient-owned, “banked” EHR.

The patient’s integrated EHR should be transactionally populated, much like the financial community, where each digital transaction is shown in the patient’s “banked account.” It should be integrated and aggregated through the patient’s applications of choice, much like Mint or Quicken aggregate financial transactions. Wherever the patient receives care, the patient receives that information into the patient’s “banked account.” Categories such as labs can be dated and aggregated, and trends and results can then easily be charted by the patient and the patient’s care providers.

For example, as a test result or x-ray is read and becomes digitally available to the institution, the patient should be able to have the results and findings reported electronically to their own application and site of choice. Eventually, in addition to lab reports and radiology reads, relevant photos and images should be included in the patient-owned and integrated EHR.

Near term, providers and patients alike (especially emergency departments) need readily available, shared access to existing images produced for patients. Imaging sharing should be open such that any institution could pull up an image no matter where it is, and that access should be provided across institutions for the patient.

We should eliminate the need for the patient to fill out a form to get access to their information. It should be instantaneously populated, versus up to 30 days. Thirty days is not an acceptable time frame. Those 30 days greatly diminish the quality of care.

Patients should be able to secure what they want to keep private, and readily share what they choose to share with other providers, physicians, family members, caregivers. Patients should be able to determine the level of privacy and to whom they want to share their own integrated EHR. Patients should be able to choose to “time out” that sharing, similar to a feature of the Find My Friends and Life360 apps.

Innovation needs to allow for compatibility of our health records with all technology vendors, and for the ability to analyze, aggregate, and readily share health data.

The standard needs to be that the electronic record is provided instantaneously, mobile, portable, compatible with all applications in the repository of our choice, and allowing for state-of-the-art and future technologies.

We need a transparent patient-centered record with full visibility into all our health records – labs, radiology, prescription fills, and care plans – to ensure the best, timely, informed, and efficient care.

Likewise, we need transparency into the quality, performance, and cost of care. With access to these metrics, we can shop for physicians and medical services at a competitive marketplace, not be restricted to certain providers, and hold both patients and providers accountable for performance.

The patient needs to know per drug administered the cost to the patient, itemized by the care facility. For instance the cost of Zantac administered from an ER versus the acceptable range of costs versus over the counter. The billing system of the hospital needs to be aligned with the patient’s instantaneous care as it’s populated, so that the patient has full transparency into the costs being charged for services rendered. Additionally, when a procedure like an MRI can be done electively, the cost of that MRI other than under emergent care where available, should be provided, and the price range of cost for the patient choice. Any out-of-network cost should be revealed to the patient upfront.

Cost data should be aligned with the EHR and be visible to the patient and physician. Physicians and patients alike are blind as to the ultimate cost of procedures. They are blind to what is “in network” and “out of network.” The “out of network charges are additional charges that occur unknowingly to patients and can be gamed by providers. To ultimately give the patient freedom of knowledge and choice, we need to strive for a near-term goal of attaching the cost to the insurer and the cost to the patient as it is aligned with the care provided for the patient, real time to the doctor and to the patient when available.

With data driven choice, we can utilize sites similar to Yelp, Amazon, and OpenTable to shop, assess quality, and book our care globally. When aggregated health data is readily available for comparative quality, cost, research, and analysis, the cost of care lowers and the quality improves.

The Hippocratic oath is to “do no harm.” Today’s EHR software companies and providers are causing harm to the patient by using protectionism and misusing HIPAA, blocking the patient from this readily available, integrated, longitudinal record of his/her health. Let’s get it done. The technology is all here. It is being used cost effectively in almost every other industry. It would drastically change the economics of health care for the better and greatly improve the quality of care to patients, as well as the quality of the jobs of our health professionals. Let’s do the right thing and make a systemic commitment to enable the complete, integrated EHR and empower the patient and give the patient freedom of choice.

Patient Exchanging Secure Messages with Care Providers

Patients and providers should be able to have two-way communication through email, Facetime or Skype, texting, photos, videos, and phone calls. New communication technology conduits should be readily adopted for such two-way communication, rather than requiring a regulation or legislation to allow people to communicate.

The patient should be able to choose to communicate through a text or email with his or her provider and FaceTime where appropriate. Like in the legal world, providers may have a disclaimer regarding confidentiality and security.

The patient’s own choice of privacy and security should supersede any institutional requirements. The patient should be able to opt in for deeper levels of security but should automatically be able to choose to share their fully integrated electronic file where they deem fit. The integrated file should be automatically available for emergency care.

The current software allows for physician notes to be viewable to the patients themselves. Patients should have readily available access to these physician notes. In addition, patients’ ability to edit and provide comments to the physician notes would be an important link to their longitudinal care. Better yet, patient edited and co-produced notes with their providers may be optimal. Most importantly, the collective needs to allow for patient participation and communication two-way with the patient’s integrated EHR.

View, Download, and Transmit Data from EHR

Much like the financial community, patients should be able to download their medical data. If any provider or the patient himself wants to view the integrated lab tests and look at a five or ten year horizon, he/she should be able to readily download the data and compare and contrast changes. They should stored in machine-readable form to allow for data analytics by care providers, caregivers, patients, and for research (where the patient has chosen to opt in).

HHS should seek to remove blockage and process burdens on patients under HIPAA that may limit patient access to their health information based upon patient choice of levels of privacy. See our comments above regarding instantaneous population to the digital record and eliminating signing a form for access and waiting 30 days.

Patients should be able to view their complete patient record, including pricing, tests, films, lab results, and health care provider notes. The EHR should provide affiliated charges and pricing. Price and cost transparency, outside of emergency situations, should be provided upfront to the patient prior to rendering services. As patients access the EHR, they should access the range of pricing from the institution compared to other comparable price ranges for a similar procedure elsewhere.

Health care providers should be able to view their patient’s aggregated/comprehensive patient electronic health record. Health care providers should have a two-way ability to communicate via email, phone, and text with each other regarding patient care.

We support the OpenNotes movement for physician notes to be provided attached to the patient EHR and two-way communication to be allowed for patient engagement.

Remote Patient Authorization and Submission of EHR Data for Research

Patients should own their health information and be able to easily create a longitudinal health record that they can use or share with health care providers, caregivers, researchers and others.

Patient information should not automatically be used for research or brokered even if it is “anonymized.” Patients should have the choice to opt in to any broad or specific medical research, and the institution should not be able to broker the patient’s data without the patient having full transparency and the choice to opt in to having their information brokered and shared. Patients should be remunerated for the per-patient access to such information if the researcher and the institution are being compensated for delivery of such information.

The patient should be fully informed of wherever the institution sends the patient data, even if they claim it is anonymized. The patient should also be informed of the transactional brokerage of their health data and the extent to which it is forwarded to pharmaceutical companies and their subsidiaries or contracted firms, anonymized or not.

If the institution is being paid for those data, the patient should have full transparency into payments the provider or researcher received for his or her medical record. Remunerations should be considered for the use of such data.

We support the following submission to ONC:

  • We live in a mobile and global world. Our health data need to reflect our mobile, instant, connected world. It is our right to access and own the results of our medical care instantaneously for our own longitudinal record, and shared with whomever we please.
  • We as patients should own our health information and digital results of our care free of charge. We already paid for them by paying for the medical service through our insurance premiums, copays, deductibles, and taxes.
  • We need our electronic health record to follow us so we are free to receive care wherever we choose. Through cooperation and non-discrimination, we can have one, single, mobile, longitudinal record, not multiple, separate portals from each provider, difficult to access.
  • Innovation needs to allow for compatibility of our health records with all technology vendors, and for the ability to analyze, aggregate, and readily share health data.
  • The standard needs to be that the electronic record is provided instantaneously, mobile, portable, compatible with all applications in the repository of our choice, and allowing for state-of-the-art and future technologies.
  • We need a transparent patient-centered record with full visibility into all our health records – labs, radiology, prescription fills, and care plans – to ensure the best, timely, informed, and efficient care.
  • Likewise, we need transparency into the quality, performance, and cost of care. With access to these metrics, we can shop for physicians and medical services at a competitive marketplace, not be restricted to certain providers, and hold both patients and providers accountable for performance.
  • With data driven choice, we can utilize sites similar to Yelp, Amazon, and OpenTable to shop, assess quality, and book our care globally. When aggregated health data is readily available for comparative quality, cost, research, and analysis, the cost of care lowers and the quality improves.
  • Providers and their software vendors need to allow for open technology development, leveraging existing state-of-the-art security and patient safety measures like thumbprint, voice, or facial recognition and device verification. The electronic medical record should be transactional, mobile, and secure like mobile banking is in the financial industry. A patient-centered longitudinal record gives the patients the choice of when, how, with whom, and to what extent their own medical records can be shared.
Permalink

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

Permalink

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.