FDA regulated medical devices are considered safety-critical systems due to their ability to affect patient lives. Given the nature of scrutiny and the requirement to play it safe, most medical device vendors end up choosing proprietary or custom solutions for operating systems, databases, messaging platforms, alarm notification systems, and event logging. This talk uncovered some of the common misconceptions around government regulations and how there are not inherent limitations around using FOSS in safety-critical systems so long as the requisite risk analysis and quality assurance work is conducted. Shahid presented his recent work on modern medical device architectures, the challenges and opportunities associated with using open source software in medical devices, and real-world findings from use of open source answering questions such as: Will the FDA accept open source in safety-critical systems? Are open source systems safe enough for medical devices? What kind of assessments are needed for open source software in medical devices?

1. Open Source Technologies in Safety-critical Medical Device PlatformsUsing Open Source to Design Connected Medical Devices to Help Fill EHRs with Clinically Useful Data Shahid N. Shah, CEO

2. Who is Shahid? 20+ years of software engineering and multi-site healthcare system deployment experience 12+ years of healthcare IT and medical devices experience (blog at http://healthcareguy.com) 15+ years of technology management experience (government, non-profit, commercial) 10+ years as architect, engineer, and implementation manager on various EMR and EHR initiatives (commercial and non-profit) Author of Chapter 13, “You’re the CIO of your Own Office”

3. Healthcare landscape background The government (through Meaningful Use & ACO incentives) is paying for the collection of clinical data. Medical devices are the best sources of quantifiable, analyzable, and reportable clinical data. Most medical devices today are not connected so you do not have access to the best data. New devices are being design and deployed to support connectivity.

4. What if we had access to all this data? Source: Jan Whittenber, Philips Medical Systems

5. Where does patient data come from?

6. Where does patient data come from?

7. Patient data source analysis Meaningful Use and CER advocates are promoting (structured) data collection for reduction of medical errors, analysis of treatments and procedures, and research for new methods. All the existing MU incentives promote the wrong kinds of collection: unreliable, slow, and error prone. Accurate, real-time, data is only available from connected medical devices

8. Connectivity is a must, OSS is answer Most obvious benefit Least attention Most promising capability This talk focuses on connected devices

9. Key OSS questions

10. Simple answer Proof: we did it at American Red Cross in 1996

11. It’s not as hard as we think… Modern real-time operating systems (open source and commercial) are reliable for safety-critical medical-grade requirements. Open standards such as TCP/IP, DDS, HTTP, and XMPP can pull vendors out of the 1980’s and into the 1990’s.  Open source and open standards that promote enterprise IT connectivity can pull vendors into the 2010’s and beyond.

12. But it’s not easy either…we need

13. OSS hazard and risk assessment What is the intended use for the device or system? How will the OSS product you’re planning to use going to be tied to your intended use? What is the risk associated with the OSS product for that particular intended use? R = Sh x Ph

14. Risk is related to severity and harm R = Sh x Ph R = risk Sh = severity of harm Ph = probability of harm Harm is damage done to a person Severity is the degree of harm done Probabilityis the frequency and duration of exposure

15. Examples of Severity & Probability Severity multiple fatalities fatalities severe injury (non-reversible, requires hospitalization) moderate injury (reversible, requires hospitalization) minor (reversible, requires first aid) very minor (no first aid) Probability Constant exposure Hourly Daily Weekly Monthly Yearly Never

16. Formal risk assessment methods

17. OSS Risk analysis steps - FMEA Define the function of the OSS product being analyzed. Identify potential failures of the OSS. Determine the causes of each failure types. Determine the effects of potential failures. Assign a risk index to each of the failure types. Determine the most appropriate corrective/preventive actions. Monitor the implementation of the corrective/preventive to ensure that it is having the desired effect.

18. Good summary of FMEA http://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis

19. Sampling of OSS / open standards

20. OSS applicability to connectivity

21. OSS applicability to manageability

22. OSS enables extensible devices

23. Appreciate tradeoffs The more connection-friendly a device, the harder it is to validate it Lesson: Demand Testability

25. Messaging

26. Registration

27. JDBC, Query6 App #1 App #2 Sensors Storage Display Plugins 7 Connectivity Layer (DDS, HTTP, XMPP) 4 Event Architecture LocationAware Plugin Container 3 2 Security and Management Layer 1 Device OS (QNX, Linux, Windows) SSL VPN Healthcare Enterprise Cloud Services Workflow 8 Device Gateway (DDS, ESB) Notifications Patient Context Data Transformation (ESB, HL7) Inventory 9 Management Dashboards Enterprise Data Shahid’s “Ultimate Connectivity Architecture”

28. OSS in Ultimate Architecture Core Connectivity isbuilt-in, not added Think about Plugins from day 1 Device Components Connectivity Layer (DDS, HTTP, XMPP) Plugin Container Security and Management Layer Device OS (QNX, Linux, Windows) Security isn’tadded later Build onOpen Source Don’t createyour own OS! Create code asa last resort

29. OSS enables plugin architecture Device Components 3rd Party Plugins App #1 App #2 Plugins Connectivity Layer (DDS, HTTP, XMPP) Event Architecture LocationAware Plugin Container Security and Management Layer Device OS (QNX, Linux, Windows)

31. Messaging

32. Registration

33. JDBC, QueryConnectivity Layer (DDS, HTTP, XMPP) Plugin Container Security and Management Layer Device OS (QNX, Linux, Windows)

34. OSS in device components Virtualize! Device Components 3rd Party Plugins Web Server, IM Client Sensors Storage Display Plugins Connectivity Layer (HTTP, XMPP) Event Architecture Plugin Container “On Device”Workflow Security and Management Layer Device OS (QNX, Linux, Windows) LocationAware PatientContext, too

35. OSS enables enterprise integration DeviceTeaming Cloud Services SSL VPN Device Data Device Gateway(DDS, XMPP, ESB) Cross Device App Workflows Patient Context Monitoring Data Transformation (ESB, HL7) RemoteSurveillance Management Dashboards Enterprise Data AlarmNotifications HITIntegration DeviceManagement ReportGeneration Inventory

37. Messaging

38. Registration

39. JDBC, QueryApp #1 App #2 Sensors Storage Display Plugins Connectivity Layer (DDS, HTTP, XMPP) Security and Management Layer Device OS (QNX, Linux, Windows) Healthcare Enterprise Cloud Services Device Gateway (DDS, ESB) Data Transformation (ESB, HL7) Management Dashboards Enterprise Data Ultimate Connectivity Architecture Event Architecture LocationAware Plugin Container SSL VPN Workflow Notifications Patient Context Inventory

40. Conclusion and Questions