1 / 30

OHT Medical Device Platform Current thinking and activities

Sept 14, 2012 OHT BoD Meeting Baltimore, MD. OHT Medical Device Platform Current thinking and activities. Julian M. Goldman, MD, Dave Arney Mass Gen Hospital/CIMIT Program on Medical Device Interoperability. E-card www.mdpnp.org. We ha ve come a long way … in some areas ….

bill
Télécharger la présentation

OHT Medical Device Platform Current thinking and activities

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Sept 14, 2012 OHT BoD Meeting Baltimore, MD OHT Medical Device PlatformCurrent thinking and activities Julian M. Goldman, MD, Dave Arney Mass Gen Hospital/CIMIT Program on Medical Device Interoperability E-card www.mdpnp.org

  2. Wehave come a long way … in some areas …

  3. “Smart Phones” are “App Platforms”, designed to enable developers to use processors, sensors, data, and screen UI to deliver Apps. • Gyro/motion sensors • Mic and speakers • Radios (many!) • GPS • Operating System designed to effectively deliver App requirements

  4. What could healthcare “apps” do? That depends on the “app platform” This type of app is very useful. But it is not the subject of today’s discussion Imagine if apps could connect to the sensors/devices in the physical environment, they could finally solve some of these clinical problems

  5. Clinical care: Is not neat and tidy. Poor access to data, only manual coordination of devices.

  6. When standardized clinical databases are populated with standardized data,validated clinical rules or “Apps”will be shared globally Validated Clinical “Apps” Validated Clinical “Apps” Validated Clinical “Apps” Validated Clinical “Apps” Crowdsourcing of clinical apps could transform healthcare J. Goldman, MD 2005-2012

  7. Medical Device “Plug-and-Play”Interoperability Program (MD PnP) Founded in 2004, the MD PnP research program is a multi-institutional community based at CIMIT and MGH. Mission: lead the adoption of medical device interoperability to improve patient safety Funding: DoD/TATRC, NSF, NIST, NIH/NIBIB, CIMIT, to develop open platform and test-bed to enable apps to coordinate medical devices to improve the safety and efficiency of diagnosis and therapy

  8. MD PnP Program Status • The program is at an inflection point • Work to now has focused on developing demo systems, gathering clinical and technical requirements, and building developer and end-user communities • We are now at a point where we are starting to build ‘real’ components, and beginning to publish code online • Major goals for the coming year: • Build and release lots of code • Get our developer and end-user communities involved

  9. MD PnP Lab One of our developers took some snapshots earlier today. The lab is usually this messy- we clean it up for demos. Lots of devices coming through, lots of projects going on.

  10. MD PnP Lab New system from CPC installed Wednesday: Collects data from Ivy Patient monitor and anesthesia machine, adding pump connectivity soon Supports some limited control of monitor

  11. MD PnP Lab Patient Simulation is a challenge. Shown here are three patient simulators, a Philips patient monitor, and several other devices. Not shown is a capnography simulator and test lung. Synchronizing patient simulators to create a coherent, realistic clinical use case is difficult. We’re looking forward to tying this work into OHT patient data repositories and artificially generated patient data.

  12. Conference: June 2007

  13. 2011 MD PnP Open House

  14. MD PnP Programming Projects • We have started posting code to github.com/mdpnp • This year we plan to release code of interest to a broad community, starting with device interface code, adding more as it matures • We're developing a strategy & timeline for code release, would like to talk with other OHT members about this • MDCF has a large repository, there is agreement to link this in • Other related projects include: • Penn/FDA GIP work • MD PnP DoD-supported Data Logger work • NwHIN CONNECT and DIRECT • HITIDE • Pan-SHARP demos

  15. Hardware and Development Environment • Working with QNX and Intel on hardware • Exploring requirements and options for embedded OS / RTOS • Working with RTI for their DDS middleware implementation via a community use license • Evaluating DDS for ICE applications with an eye to commenting on the public DDS standard • Current development is using BeagleBoard and BeagleBone boards for device adapters and network controller • The MD PnP lab contains a large and growing collection of devices and networking equipment. This is a key resource available to collaborators.

  16. MD PnP Communities • We've just started publicly posting code, but have been developing a user and developer community for many years. • Figuring out how to get that community involved in the public code is an important goal for this year. • As is growing the community and getting more users and developers involved. • Community building is a funded aim of our new DoD/TATRC grant and important to the success of the NIH Quantum Interoperability project

  17. MD PnP Program Collaborators

  18. MD PnP Lab • Located in Cambridge, MA • Vender-neutral sandbox for experimenting with device interoperability • Contains devices from many of our partners and others, some donated or loaned, more purchased • Supports remote collaborators over network • For specific protocols (NwHIN CONNECT, DIRECT) • Or VPN into research network for direct connection to devices

  19. as of July 2009: American Medical Association World Federation of Societies of Anesthesiologists American Society of Anesthesiologists Massachusetts Medical Society Anesthesia Patient Safety Foundation Society for Technology in Anesthesia Society of American Gastrointestinal Endoscopic Surgeons RESOLVED, That our American Medical Association (AMA) believes that intercommunication and interoperability of electronic medical devices could lead to important advances in patient safety and patient care, and that the standards and protocols to allow such seamless intercommunication should be developed fully with these advances in mind. Our AMA also recognizes that, as in all technological advances, interoperability poses safety and medico-legal challenges as well … ”

  20. MD FIRE Medical Device “Free Interoperability Requirements for the Enterprise” • Position Statement & Sample of Interoperability RFP and Contract language • Developed by Mass General Hospital / Partners, Johns Hopkins, Kaiser Permanente via MD PnP research program • Conveys healthcare needs to industry, and simplify purchasing specifications • V2 published in August 2012added VA 5 Stakeholder groups from each organization: Purchasing/materials management, BME, IS, Clinical, Legal Download MD FIRE from www.mdpnp.org

  21. MD FIRE • “Healthcare Delivery Organizations (HDOs) must lead a call to action for interoperability of medical devices and systems. • One way that HDOs can effect this change is by including medical device interoperability as an essential element in the procurement process and in vendor selection criteria.” • Download: mdpnp.org/MD_FIRE.php

  22. Commissioner's Grid plan for Manhattan (adopted 1811) The Commissioners' Plan of 1811 was the original design plan for the streets of Manhattan, which put in place the grid plan that has defined Manhattan to this day. It originated as a proposal by the New York State Legislature, adopted in 1811 for the orderly development and sale of the land of Manhattan between 14th Street and Washington Heights. The plan is arguably the most famous use of the grid plan and is considered by most historians to have been far-reaching and visionary. http://en.wikipedia.org/wiki/Commissioners'_Plan_of_1811 http://www.library.cornell.edu/Reps/DOCS/nyc1811.htm

  23. The NIST Medical device interoperability Health IT project • Requirements Analysis – Scenario-based functional decomposition of ICE requirements • Gap Analysis – Using FIPS 182 IDEF0requirements modeling. Don’t start with a design! Find the requirements, then design the system. • Candidate scalable data transport middleware • Medical Device Cooperation Framework (MDCF) • The NIST Data Flow System V2 • OMG Data Distribution Services (DDS) • 11073 Domain Information Model (DIM) • NDFS mapping

  24. ASTM F2761-09 CConOps 1Patient Controlled Analgesia Fatality • Section B.2 Clinical Examples • B.2.1.1 Clinical scenario, safety Interlock • Current State: “A 49-year-old woman underwent an uneventful total abdominal hysterectomy and bilateral salpingo-oophorectomy. Postoperatively, the patient complained of severe pain and received intravenous morphine sulfate in small increments. She began receiving a continuous infusion of morphine via a patient-controlled analgesia (PCA) pump. A few hours after leaving the PACU [post anesthesia care unit] and arriving on the floor, she was found pale with shallow breathing, a faint pulse, and pinpoint pupils. The nursing staff called a “code,” and the patient was resuscitated and transferred to the intensive care unit on a respirator [ventilator]. Based on family wishes, life support was withdrawn and the patient died. Review of the case by providers implicated a PCA overdose.” [7] Delayed detection of respiratory compromise in patients undergoing PCA therapy is not uncommon because monitoring of respiratory status has been confounded by excessive nuisance alarms (poor alarm specificity).”

  25. Models of the ASTM 2761-09 Standard - Requirements Activity Diagrams • IDEF0 Activity Diagram: A hierarchy of diagrams illuminating activities contextualized by inputs and outputs • Critical to get the highest levels right! NIST

  26. System Data Flow Requirements Model NIST

  27. System Data Flow Requirements Model NIST

More Related