WG5

1. WG5 • Steve van Albert, Rajeev Alur, Douglas Barton, Ralph DePalma, Matthew Dwyer, Steven Getz, LeRoy Jones, Peter Kuzmak, Peter Lee, Rami Melhem, Jens Palsberg, John Regehr, Victoria Rich, Michael Robkin, Gregg Rothermel, Vish Sankaran, Bow-Yaw Wang

2. High-confidence Medical Device Software Development and Assurance / Medical Practice-driven Models

3. General observations • Medical device software, while potentially safety-critical in nature, appears not to be developed using practices well-accepted by other safety-critical domains, most notably avionics. • The proprietary nature of medical device products is a barrier to participation by academic researchers. • Software quality may not be the critical issue; however IT is a key enabler and shows clear benefits in the cost and quality of patient care.

4. Problem summary, 1 • Software quality. Specific IT-based medical systems have clearly identified faults/defects, some of which have led to loss of medical records and adverse events. In some cases, technical solutions exist but other barriers (some non-technical) prevent their application. These include lack of standards, interoperability, and metrics.

5. Examples • Uniqueness of DICOM / HL7 identifiers is neither standardized in the industry nor is it properly implemented in deployed devices, leading directly to loss of medical records. • BCMA is unreliable. Barcoding is not standard across blood suppliers. Furthermore, barcode tags are physically unreliable and readers can be faulty. This has led directly to patient death. • Others: VisiCue software errors; WebVista errors induced by cookies; ...

6. Problem summary, 2 • Feature creep. There is a lack of visibility in medical device software and the processes used to create it. Feature creep leads to interactions in the software that are hard to specify and even harder to analyze. The result is that no one, not even the developers, understand how the systems behave, nor do they provide metrics on how well they work.

7. Examples • Feature interactions are a major problem. The value of testing and analysis techniques for validation has not been investigated. • Developers lack metrics for reliability, usability, etc. This makes it impossible to assess the costs and benefits of validation approaches.

8. Problem summary, 3 • Usability. The proliferation of information technologies has provided clear benefits for the quality and cost of patient care. But it may introduce significant and often unnecessary complications to hospital procedures. This can lead to situations that are confusing to caregivers (e.g., task overload) and unacceptably perilous to patients.

9. Examples • Practitioners are on a gadget treadmill. Besides the obvious training and operational challenges, version skew is inevitable and comes at times with severe, even disabling, consequences. • Unlike aircraft, medical devices often do not have “black boxes,” making audit and postmortem analysis of failures difficult or even impossible. • Interventional procedures have become extremely complicated, even unsafe, making it hard to know when all systems are operational and ready to perform.

10. Problem summary, 4 • Knowledge sharing. Knowledge saves lives. Data can be transformed into information. However, sharing of information is hampered by the lack of interoperability standards and technologies, and by confusion over privacy regulations (e.g., HIPAA).

11. Examples • The proprietary nature of the devices and privacy requirements means that researchers and industry lack access to platforms and data needed for innovation. • Lack of standardization in BCMA, DICOM IDs, etc.

12. Problem summary, 5 • Systems engineering. Integration of technology into the clinical environment (including the practitioners, workflows, and specific devices) often lacks a total system perspective. Specifically, device integration capabilities, interoperability, safety features are not considered during development, acquisition, or deployment. Some safety issues are systems issues. This results in adverse events and lost opportunities.

13. Examples • Maintaining configurations is difficult. Understanding the impact of version and feature upgrades in a large hospital context is difficult. • Analysis and modeling tools used in other industries (e.g., automotive) are not widely adopted by the medical device industry. • Patient modeling would help.

14. Summary of state of the art • algorithms for distributed unique identifiers • software processes for ensuring “five 9s” safety and availability in avionics • double-helix spiral development model (e.g., CPoF) • open research platform development and dissemination (a la motes/TinyOS) • modeling tools; analysis tools • lightweight formal methods; government-mandated formal methods (Europe)

15. R&D challenges • Realistic experimental platforms and data for research purposes • Analysis/validation/verification of feature interactions • Metrics for reliability, usability, etc. • Transparency, interoperability, and reliability in the face of market forces that promote features and low cost • Integration of disparate systems into a coherent whole

16. Research needs • Not just IT. This requires an interdisciplinary, whole systems approach involving computer scientists expert in areas such as software engineering and HCI, as well as caregivers, biomedical engineers, and device manufacturers.

17. Research needs • Rich, open experimental platforms and testbeds • Measurable assurance: metrics and standards for reliability, usability, interoperability, etc. • New methods for high-confidence software and systems, addressing independently and together interoperability, cost, feature interaction, privacy, visibility, and usability • Methods for evaluating the cost-benefit tradeoffs in various methods for high-confidence systems • Patient modeling and systems engineering of clinical processes

18. Roadmap, 1 • Develop open experimental platforms and testbeds to foster collaboration between academic, industry, and government • Regulatory mechanisms should be supportive of the platforms and encourage a systems approach, facilitate integration of components • Support and encourage the development and use objective measures

19. Roadmap, 2 • Develop and perform experimental evaluation of the effectiveness of integrated systems • Involves extraction of models from clinicians, analysis of change effects, measurement of system performance, etc. to support a systems engineering approach • NCO should coordinate the federal gov’t, state gov’ts, providers and industry to remove regulatory / legal roadblocks to encourage new IT-facilitated processes.

20. Roadmap, 3 • Academia, manufacturers, and government should work together to promote standardized barcode technologies in bloodbank applications and administration. • Similarly, promote universally unique identifiers for medical information objects.