FDASIA WG Regulations Sub-Group Report Out

1. May 30 2013 FDASIA WGRegulations Sub-Group Report Out HIT Policy Committee FDASIA WG www.jgoldman.info

2. Breakout Topics • Clarification of “regulation” • FDA vs non FDA • Written vs. applied • Notion of scope of “safety” • Review of published literature for regulatory duplication and ambiguity • Deliverables will be: • prioritized list of ambiguities and duplication requiring resolution • Potential new issues that need to be avoided • Proposed solutions – Will assess recommendations / work products from other groups to guide our recommendations

3. Examples to help clarify regulatory recommendations • EHR-medical device data representation/gaps • Hazards cross FDA regulated and other spaces • Data time stamping • Technology complexity is not necessarily aligned with severity of risk – PCA example • Interoperability • Need for surveillance of HIT systems • Data logging / black box recording as a basis for improving system safety

4. Experiment What is the real O2saturation?Which value will be recorded in EHR? Averaging time should be included in EHR data Pulse Ox is set to: 16 sec averaging time Experiment: Simulator is set to create transient desaturation 99%->70%->99% 8 sec averaging time 2 sec averaging time Photos of pulse ox screens when they display the lowest saturation Julian M. Goldman, MD / MGH

5. Monitor Example: Low pulse oximetry value created an alarm. Low sat data is not recorded by EHR Alarm event is not captured in EHR WHY? Configuration? Intended performance? What if caused by performance issue with IT h/w (“Cisco router”) No evidence of low SpO2 in EHR GE Monitor Recorded Low SpO2 Alarm Event “84%” Julian M. Goldman, MD / MGH

6. Sources of variation in EHR documentation d/t Data Sampling 60 Seconds Example of possible EHR sample points for 1-minute recording Based on this example, EHR May record SpO2 as: 98% 92% 80% 75% Etc. Pulse Oximeter Displayed SpO2 at 8-second averaging time SPO2= 75 Patient’s “actual” SpO2 minimum = 70%

7. Device Clock Time Errors:Undermine system integrity and can create emergent hazardsClock time may originate in medical device, be consumed by other systems.

8. Medical Devices

9. EMR EMR time stamp error Blood gas analyzer in OR

10. Draft – unpublished data Consolidated 4 Hospital Summary (Draft)

11. Draft – unpublished data Incorrect dates

12. Device Clock Time Errors:Undermine system integrity and can create emergent hazardsTreatment errors, barriers to analysis of adverse eventsIs this an example of an “interop problem” that should be solved in the proposed framework?

13. PCA Pump (With patient button) Nurse call Patient Patient-Controlled Analgesia (PCA)system safety concerns ? • Patients can call to request more analgesia, but, cannot call for help when over-medicated. • Over-medication can cause respiratory and cardiac arrest • Comprehensive monitoring is not typically used due to high false/nuisance alarm rate • How can we improve safety of this system? • Solution: Smarter alarms with sensor fusion + capability to stop medication infusion prior to injury

14. PCA Safety Issues continue http://ppahs.wordpress.com/2012/02/01/guest-post-yes-real-time-monitoring-would-have-saved-leah-2/ This is the story of an 11 year old who died from narcotic-induced respiratory depression. "Ten years after my daughter's death, nothing has changed in the codes of monitoring post-op patients continuously, until they leave the hospital. Alive." http://www.apsf.org/newsletters/html/2010/spring/12_coalition.htm This is a statement from a multi-hospital coalition frustrated by ongoing adverse patient events: "A closed-loop system, which stops or pauses opioid dosing if respiratory depression is detected, is desirable. Systems are most ideally centrally monitored. In any case, alarms should be audible or otherwise available to the primary caregiver, and a mechanism for prompt response should be in place." http://ppahs.wordpress.com/about/ "Carly Ann Pritchard ... suffered an ankle injury and then underwent surgery to reduce lingering pain from her ankle injury. Unfortunately, although she survived surgery, she suffered brain damage because of an accidental overdose from a morphine-filled pain pump - after surgery. A California appeals court recently upheld a jury's award of about $9.9 million in damages."

15. Newsletter • “A particularly attractive feature may be the ability to automatically terminate or reduce PCA (or PCEA) infusionswhen monitoring technology suggests the presence of opioid-induced respiratory depression. To facilitate such capabilities, we strongly endorse the efforts to develop international standards for device interoperability and device-device communication. • It is critical that any monitoring system be linked to a reliable process to summon a competent health care professional to the patient's bedside in a timely manner.” Risk to patient of adding these capabilities is very low, although technology is sophisticated

16. Reporting … PCA as example • Injury due to pump failure -> FDA report • Injury due to HIT-related contribution (body weight error, allergy data lost, etc.) no report? • Injury due to INABILITY integrate devices and HIT systems to prevent error – not reported

17. Interoperability • Key enabler of HIT-based healthcare transformation • Un-disciplined system integration has been introducing new hazards.

18. “Reporting”Leverage HIT for Surveillance • IT’s strength is surveillance • Can we reduce pre-market regulatory burden by improving surveillance of system • medical device + HIT components • Single point of reporting adverse events and means to resolve issues – especially that cross regulated and “non regulated” spaces

19. Planes, Trains, Automobiles … Data Logger or Clinical Black Box Recorder • Data Log supports Analysis and Playback for two complementary purposes: • Analysis of device / system interactions (debugging) • Analysis of adverse events involving patients (clinical) • The log may include: • Commands • Button presses • Information about the status of devices • Device connections and disconnections

20. Proposed Next Steps wrt safety and regulatory framework • Develop use cases to tease out Regulatory Framework requirements • Include high and low acuity • Usage venues: mHealth etc. • Identify common needs across use cases (these or others)