The Light Collective + OpenNotes Comments on ONC HTI-1 Proposed Rule

Subject: Public Comment Regarding the Proposed HTI-1 Rule on Health Data, Technology, and Interoperability

To: Office of the National Coordinator for Health IT (ONC)

Greetings,

On behalf of The Light Collective and OpenNotes, we want to thank you for providing the opportunity to comment on the Office of the National Coordinator’s proposed rule.  We appreciated the concise overview to facilitate comments from the public.

We are writing the enclosed comments from the perspective of patient communities and clinicians.

 

• • The Light Collective is a patient-led nonprofit with a mission to advance the rights, interests, and voices of patient communities in health technology.

 

• •  OpenNotes is an international movement advocating for greater transparency in healthcare.

 

There are certain aspects of the proposed rule that warrant consideration from the perspective of stakeholders who will be directly impacted by these proposed changes.  We hope these comments can help ONC to ensure a fairer and more effective Certification Program and maintain transparency in the use of algorithms in health IT.

Sincerely,

 

Andrea Downing Co-Founder & President The Light Collective	Catherine M. DesRoches, DrPH, Executive Director, OpenNotes Beth Israel Deaconess Medical Center, Associate Professor of Medicine, Harvard Medical School
Jill Holdren Co-Founder & Board President The Light Collective	Liz Salmi Communications & Patient Initiatives Director, OpenNotes, Beth Israel Deaconess Medical Center

 

 

---

 

Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing Proposed Rule

 

 

General Comments.

 

 

We have the following general comments.  To ensure fair Certification Program Updates and Algorithm Transparency, we encourage the Office of the National Coordinator for Health IT (ONC) to consider the following approaches:

 

1. 1. Explain a clear set of use cases:  The ONC HT-1 Rule specifically looks at Sepsis prediction as a use case. Here we would like to point to the recent investigative work on this type of predictive algorithm where, without independent oversight, Epic’s “black box” sepsis algorithm missed a majority of cases.  Any predictive model used in care must be subject to independent validation of results.  As we are now at the 10 year anniversary of the case that decided whether human genes could be patented, consider genetic/diagnostic testing for BRCA mutations, as an example use case.  The history of proprietary “black box” algorithms for BRCA can also be considered as a proxy use case for predictive algorithms in other patient populations.  Today variant calls for BRCA are subject to expert review from a body of clinical experts reviewing the evidence, after determining the need for reproducibility and independent validation.  For example the BRCA exchange is a global open information exchange that shares variant-level evidence while preserving patient privacy: https://brcaexchange.org/factsheet

 

 

2. 2. Apply The Risk analysis (8 risk types): validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy.  We encourage ONC to list use cases that are not eligible for certification, and to clearly define what risks or harms would disqualify an IT developer from certification.  ONC can make efforts to define clear “out of scope” use cases applying these risk types.  For example, if an IT Developer wanted to re-sell a predictive DSI to insurance companies in order to raise the premium rates for patients as a business model instead of to improve a patient’s care.  Or if an IT developer applied for certification using “social determinants of health” data obtained from users’ private social media posts to make predictions about their health.  Such examples that may result in harm or privacy violations.  How are certification criteria going to exclude developers engaging in risky or harmful practices?

 

 

3. 3. Oversight: TEFCA represents the largest-scale non-accountable PHI flow in history. ONC must create independent governance and accountability for the institutions supporting these exchanges. The role of an independent governance body would be to ensure certified IT developers are following the certification guidelines, especially for DSI’s.  IT Developers cannot be left to self-identify risks, but rather DSIs must be evaluated independently to ensure proof of claims of risk and conformance to requirements.

 

 

4. 4. Involving Patient & Clinician Stakeholders in the Co-Design of Algorithm Transparency Initiatives: The certification program and algorithm transparency initiatives should involve a broad range of stakeholders, including healthcare providers, health IT developers.  But perhaps most important to involve as stakeholders are patient & clinician advocacy groups who will need to build capacity to engage on these initiatives that directly affect their lives and futures. Specifically, there should be a focus on collaborating with stakeholders who represent patient & clinician communities that are directly affected by these algorithms if bias, discrimination, or harm were to occur as a result of a certified algorithm.  Involving patients in design cannot be mere tokenism.  We encourage the use of patient-created resources to evaluate fairness of engagement such as the Patient-Led Research Scorecard.

 

 

5. 5. Do not Certify Systems or Developers who used Banned Surveillance Tracking Technologies: We encourage ONC to specifically call out banned surveillance tracking technologies as a prohibited source of data in predictive algorithms.  Ensure systems are audited to check for use of Surveillance tracking technologies, following the HHS Guidance outlined in December 2022. Health IT Systems should not be certified if they are using banned tracking technologies. Algorithms that rely on surveillance tracking technologies must not be certified.

 

 

6. 6. Transparency in Algorithm Design and Use: Transparency is key in building trust with patients and providers. The ONC must require that health IT developers provide clear explanations of how their algorithms work, publicly state the sources of data they use, and how they impact patient care.  Provenance of data used in algorithms must be clear to patients at an 8th grade reading level.  This will ensure algorithms are used responsibly and effectively, and can reduce the risk of bias or error in algorithmic decision-making.  See our further comments in § 170.315(d)(14) – Patient Requested Restrictions Certification Criterion.

 

 

7. 7. Training and Education: The ONC should provide robust patient-facing resources for training and education to healthcare providers and patients on how to evaluate and understand algorithmic decision-making. There should be clear education about patient safety risks and limitations of using algorithms in care.  This will ensure these systems are used appropriately and effectively, and empower patients to better understand, use, and have more control over their health information.

 

 

8. 8. Patient-Centric Design: The ONC should encourage health IT developers to partner directly with patient advocacy organizations to ensure the usefulness and safety of design in their systems. This can improve the usability and accessibility of these systems for patients, and ensure health IT organizations are meeting the needs of end-users.

 

 

§ 170.315(d)(14) – Patient Requested Restrictions Certification Criterion 

 

We support prior comments made by SMART Health IT with additional input below.  We encourage ONC to adopt approaches that empower patients with rights and insights into the use of their data such as:

Controls at the source: Let patients ensure data accuracy at the source, to prevent sharing of inaccurate information. Introduce a functional requirement aligning with the HIPAA right to request corrections and amendments to erroneous information.

This would:

 

 

• • Ensure that patient portals and patient APIs provide patients an easy path to requesting corrections to their medical records, or to amending records in the case that providers decline to apply corrections.

 

 

• • Provide a clear market signal to drive participation in standardization efforts through independent patient-led governance bodies.  Here, governance structures should not just be unfunded volunteer HL7 workgroups.  This work must be funded and supported by the institutions sharing these data, and driving these exchanges.  We encourage the use of established patient-created resources to evaluate fairness of engagement with patient communities, such as the Patient-Led Research Scorecard.

 

 

• • Insights and controls for exchange: Let patients see who’s querying their data in TEFCA, and provide opt-out controls. Since most uses of TEFCA would fall under “treatment, payments, and operations,” TEFCA represents the largest-scale non-accountable PHI flow in history.

 

 

 

As patient & clinicians submitting this comment, recognize the specific need for our stakeholders to have a role to provide independent oversight, governance, and accountability.  Josh Mandel, JP Pollack, and Ken Mandl wrote “The Patient Role in a Federal National-Scale Health Information Exchange” at https://www.jmir.org/2022/11/e41750.

 

ONC should prevent TEFCA from driving such “dark” traffic by providing a mechanism for patients to review:

 

1. 1. Who made a query for my records?

 

1. 1. When?

 

1. 1. For what purpose of use?

 

1. 1. Who responded to the query?

 

1. 1. How is such a query aligned to benefit or harm me or patients like me?

 

 

Beyond just being able to review “dark” traffic, patients should have a way to collectively organize to enforce digital rights & health privacy when harm or adverse events occur.  Individual patients cannot be left to navigate how these new exchanges are working without support, and experts with a fiduciary duty to patient interests.  This governance, support structure, and formalized role for patient-led enforcement is lacking in TEFCA today.  Oversight cannot solely reside in the hands of institutions or industry who are applying for certification.  Please review The Light Collective’s white paper on the need for collective and independent governance.

 

§ 170.407 Insights Condition and Maintenance of Certification

 

Conditions for maintenance of certification should actively check for bias, and have provisions against using algorithms to discriminate in any way to deny care or increase the costs of care for patients.  Transparency here will be key.  ONC must consider creating a public register of Health IT developers’ certification status.

 

A company’s proprietary data should be made fully transparent and accessible to all interested parties, with no allowable withholdings for corporate trade secrets as a means of withholding data for independent validation.

 

Real World Testing – Inherited Certified Status 

 

IT developers should be required to follow human subject research protocols when conducting real-world testing. We cannot continue to assume that because data is “de-identified” that real-world testing does not need protections for human subjects.

 

Just as untested and faulty experimentation on human subjects has proven detrimental to the public in the past, this real world testing can fail to address social, emotional, health, and economic consequences that could result from the careless release of biased products and services.