Open Source Technologies in Safety-critical Medical Device PlatformsUsing Open Source to Design Connected Medical Devices ...
Who is Shahid?<br />20+ years of software engineering and multi-site healthcare system deployment experience<br />12+ year...
Healthcare landscape background<br />The government (through Meaningful Use & ACO incentives) is paying for the collection...
What if we had access to all this data?<br />Source: Jan Whittenber, Philips Medical Systems<br />
Where does patient data come from?<br />
Where does patient data come from?<br />
Patient data source analysis<br />Meaningful Use and CER advocates are promoting (structured) data collection for reductio...
Connectivity is a must, OSS is answer<br />Most obvious benefit<br />Least attention<br />Most promising<br />capability<b...
Key OSS questions<br />
Simple answer<br />Proof: we did it at American Red Cross in 1996<br />
It’s not as hard as we think…<br />Modern real-time operating systems (open source and commercial) are reliable for safety...
But it’s not easy either…we need<br />
OSS hazard and risk assessment<br />What is the intended use for the device or system?<br />How will the OSS product you’r...
Risk is related to severity and harm<br />R = Sh x Ph<br />R = risk<br />Sh = severity of harm<br />Ph = probability of ha...
Examples of Severity & Probability<br />Severity<br />multiple fatalities<br />fatalities<br />severe injury (non-reversib...
Formal risk assessment methods<br />
OSS Risk analysis steps - FMEA<br />Define the function of the OSS product being analyzed. <br />Identify potential failur...
Good summary of FMEA<br />http://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis<br />
Sampling of OSS / open standards<br />
OSS applicability to connectivity<br />
OSS applicability to manageability<br />
OSS enables extensible devices<br />
Appreciate tradeoffs<br />The more connection-friendly a device, the harder it is to validate it<br />Lesson: Demand Testa...
5<br />Device Components<br />3rd Party Plugins<br />Web Server, IM Client<br /><ul><li>Presence
 Messaging
 Registration
 JDBC, Query</li></ul>6<br />App <br />#1<br />App <br />#2<br />Sensors<br />Storage<br />Display<br />Plugins<br />7<br ...
OSS in Ultimate Architecture Core<br />Connectivity isbuilt-in, not added<br />Think about<br />Plugins from day 1<br />De...
OSS enables plugin architecture<br />Device Components<br />3rd Party Plugins<br />App <br />#1<br />App <br />#2<br />Plu...
OSS in connectivity components<br />Design all functions as plugins<br />Surveillance &“remote display”<br />Remote Access...
 Messaging
Upcoming SlideShare
Loading in...5
×

OSCon 2011 Talk: The implications of open source technologies in safety critical medical device platforms

4,457

Published on

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?

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,457
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

OSCon 2011 Talk: The implications of open source technologies in safety critical medical device platforms

  1. 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<br />Shahid N. Shah, CEO<br />
  2. 2. Who is Shahid?<br />20+ years of software engineering and multi-site healthcare system deployment experience<br />12+ years of healthcare IT and medical devices experience (blog at http://healthcareguy.com) <br />15+ years of technology management experience (government, non-profit, commercial)<br />10+ years as architect, engineer, and implementation manager on various EMR and EHR initiatives (commercial and non-profit)<br />Author of Chapter 13, “You’re the CIO of your Own Office”<br />
  3. 3. Healthcare landscape background<br />The government (through Meaningful Use & ACO incentives) is paying for the collection of clinical data.<br />Medical devices are the best sources of quantifiable, analyzable, and reportable clinical data.<br />Most medical devices today are not connected so you do not have access to the best data.<br />New devices are being design and deployed to support connectivity.<br />
  4. 4. What if we had access to all this data?<br />Source: Jan Whittenber, Philips Medical Systems<br />
  5. 5. Where does patient data come from?<br />
  6. 6. Where does patient data come from?<br />
  7. 7. Patient data source analysis<br />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.<br />All the existing MU incentives promote the wrong kinds of collection: unreliable, slow, and error prone.<br />Accurate, real-time, data is only available from connected medical devices<br />
  8. 8. Connectivity is a must, OSS is answer<br />Most obvious benefit<br />Least attention<br />Most promising<br />capability<br />This talk focuses on connected devices<br />
  9. 9. Key OSS questions<br />
  10. 10. Simple answer<br />Proof: we did it at American Red Cross in 1996<br />
  11. 11. It’s not as hard as we think…<br />Modern real-time operating systems (open source and commercial) are reliable for safety-critical medical-grade requirements.<br />Open standards such as TCP/IP, DDS, HTTP, and XMPP can pull vendors out of the 1980’s and into the 1990’s. <br />Open source and open standards that promote enterprise IT connectivity can pull vendors into the 2010’s and beyond.<br />
  12. 12. But it’s not easy either…we need<br />
  13. 13. OSS hazard and risk assessment<br />What is the intended use for the device or system?<br />How will the OSS product you’re planning to use going to be tied to your intended use?<br />What is the risk associated with the OSS product for that particular intended use?<br />R = Sh x Ph<br />
  14. 14. Risk is related to severity and harm<br />R = Sh x Ph<br />R = risk<br />Sh = severity of harm<br />Ph = probability of harm<br />Harm is damage done to a person<br />Severity is the degree of harm done<br />Probabilityis the frequency and duration of exposure<br />
  15. 15. Examples of Severity & Probability<br />Severity<br />multiple fatalities<br />fatalities<br />severe injury (non-reversible, requires hospitalization)<br />moderate injury (reversible, requires hospitalization)<br />minor (reversible, requires first aid)<br />very minor (no first aid)<br />Probability<br />Constant exposure<br />Hourly<br />Daily<br />Weekly<br />Monthly<br />Yearly<br />Never<br />
  16. 16. Formal risk assessment methods<br />
  17. 17. OSS Risk analysis steps - FMEA<br />Define the function of the OSS product being analyzed. <br />Identify potential failures of the OSS. <br />Determine the causes of each failure types. <br />Determine the effects of potential failures. <br />Assign a risk index to each of the failure types. <br />Determine the most appropriate corrective/preventive actions. <br />Monitor the implementation of the corrective/preventive to ensure that it is having the desired effect. <br />
  18. 18. Good summary of FMEA<br />http://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis<br />
  19. 19. Sampling of OSS / open standards<br />
  20. 20. OSS applicability to connectivity<br />
  21. 21. OSS applicability to manageability<br />
  22. 22. OSS enables extensible devices<br />
  23. 23. Appreciate tradeoffs<br />The more connection-friendly a device, the harder it is to validate it<br />Lesson: Demand Testability<br />
  24. 24. 5<br />Device Components<br />3rd Party Plugins<br />Web Server, IM Client<br /><ul><li>Presence
  25. 25. Messaging
  26. 26. Registration
  27. 27. JDBC, Query</li></ul>6<br />App <br />#1<br />App <br />#2<br />Sensors<br />Storage<br />Display<br />Plugins<br />7<br />Connectivity Layer (DDS, HTTP, XMPP)<br />4<br />Event Architecture<br />LocationAware<br />Plugin Container<br />3<br />2<br />Security and Management Layer<br />1<br />Device OS<br />(QNX, Linux, Windows)<br />SSL VPN<br />Healthcare Enterprise<br />Cloud<br />Services<br />Workflow<br />8<br />Device Gateway (DDS, ESB)<br />Notifications<br />Patient Context<br />Data Transformation (ESB, HL7)<br />Inventory<br />9<br />Management<br />Dashboards<br />Enterprise <br />Data<br />Shahid’s “Ultimate Connectivity Architecture”<br />
  28. 28. OSS in Ultimate Architecture Core<br />Connectivity isbuilt-in, not added<br />Think about<br />Plugins from day 1<br />Device Components<br />Connectivity Layer (DDS, HTTP, XMPP)<br />Plugin Container<br />Security and Management Layer<br />Device OS<br />(QNX, Linux, Windows)<br />Security isn’tadded later<br />Build onOpen Source<br />Don’t createyour own OS!<br />Create code asa last resort<br />
  29. 29. OSS enables plugin architecture<br />Device Components<br />3rd Party Plugins<br />App <br />#1<br />App <br />#2<br />Plugins<br />Connectivity Layer (DDS, HTTP, XMPP)<br />Event Architecture<br />LocationAware<br />Plugin Container<br />Security and Management Layer<br />Device OS<br />(QNX, Linux, Windows)<br />
  30. 30. OSS in connectivity components<br />Design all functions as plugins<br />Surveillance &“remote display”<br />Remote Access<br />Event Viewer<br />Alarms<br />Device Components<br />Web Server, IM Client<br /><ul><li>Presence
  31. 31. Messaging
  32. 32. Registration
  33. 33. JDBC, Query</li></ul>Connectivity Layer (DDS, HTTP, XMPP)<br />Plugin Container<br />Security and Management Layer<br />Device OS<br />(QNX, Linux, Windows)<br />
  34. 34. OSS in device components<br />Virtualize!<br />Device Components<br />3rd Party Plugins<br />Web Server, IM Client<br />Sensors<br />Storage<br />Display<br />Plugins<br />Connectivity Layer (HTTP, XMPP)<br />Event Architecture<br />Plugin Container<br />“On Device”Workflow<br />Security and Management Layer<br />Device OS<br />(QNX, Linux, Windows)<br />LocationAware<br />PatientContext, too<br />
  35. 35. OSS enables enterprise integration<br />DeviceTeaming<br />Cloud<br />Services<br />SSL VPN<br />Device<br />Data<br />Device Gateway(DDS, XMPP, ESB)<br />Cross Device <br />App Workflows<br />Patient Context<br />Monitoring<br />Data Transformation (ESB, HL7)<br />RemoteSurveillance<br />Management<br />Dashboards<br />Enterprise <br />Data<br />AlarmNotifications<br />HITIntegration<br />DeviceManagement<br />ReportGeneration<br />Inventory<br />
  36. 36. Device Components<br />3rd Party Plugins<br />Web Server, IM Client<br /><ul><li>Presence
  37. 37. Messaging
  38. 38. Registration
  39. 39. JDBC, Query</li></ul>App <br />#1<br />App <br />#2<br />Sensors<br />Storage<br />Display<br />Plugins<br />Connectivity Layer (DDS, HTTP, XMPP)<br />Security and Management Layer<br />Device OS<br />(QNX, Linux, Windows)<br />Healthcare Enterprise<br />Cloud<br />Services<br />Device Gateway (DDS, ESB)<br />Data Transformation (ESB, HL7)<br />Management<br />Dashboards<br />Enterprise <br />Data<br />Ultimate Connectivity Architecture<br />Event Architecture<br />LocationAware<br />Plugin Container<br />SSL VPN<br />Workflow<br />Notifications<br />Patient Context<br />Inventory<br />
  40. 40. Conclusion and Questions<br />

×