Advances in Wireless Technologies for Healthcare The Do s and Don ts of Medical Device integration Shahid N. Shah, CEO
Visit Dräger and Shahid at HIMSS 2012 Dräger Booth on the main floor: Booth #5734 See Dräger s integrated Monitoring Systems & IT solutions like the Wi-Fi certified Infinity M300 continuous mobile patient monitor or the Anesthesia Information Management System Innovian Anesthesia. Celebrate the worldwide deployment of Innovian Anesthesia at all Department of Defense hospitals by getting your photo taken at our booth. For every photo we will donate $5 to the Fisher House Foundation, an international not-forprofit organization helping to improve quality of life for members of the military, retirees, veterans, and their families. Dräger Kiosk at the HIMSS Knowledge Center for Medical Device Integration: Booth #14647 See Shahid s and Cisco s Presentation at the Knowledge Center on Wednesday, February 22 at 3:45pm Dräger Integrated Anesthesia Workstation at the Intelligent Hospital Pavilion: Booth #12442 Dräger Patient Monitoring Solutions managed by Cisco s Biomedical Network Admission Control (BNAC) Software: Cisco Booth #4223
Who is Shahid? I build things. 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 (regulated systems, government, non-profit, commercial) 10+ years as architect, engineer, and implementation manager on various EMR and EHR initiatives (commercial and nonprofit) Author of Chapter 13, You re the CIO of your Own Office
What s this presentation about? Data Landscape Data has potential to solve some hard healthcare problems and change how medical science is done. The government is paying for the collection of clinical data (Meaningful Use or MU ). All the existing MU incentives promote the wrong kinds of data collection: unreliable, slow, and error prone. Key Takeaways Medical devices are the best sources of quantifiable, analyzable, and reportable clinical data. Devices you purchase must support connectivity inherently. Integrating safety critical devices is challenging yet essential and achievable. The many Do s and Dont s of medical device integration.
The goals for medical device integration Feed EHRs and evidence-based medicine with timely, useful data
What if we had access to all this data? Source: Jan Whittenber, HITSP/TN905
What problems can data help solve?
Data changes the questions we ask Simple visual facts Complex visual facts Complex computable facts
Data can change medical science The old way The new way
Evidence-based medicine is our goal
Unstructured patient data sources Source Patient Self reported by patient Health Professional Observation s by HCP Labs & Diagnostics Computed from specimens Errors High Medium Low Time Slow Slow Medium Reliability Low Medium High Data size Megabytes Megabytes Megabytes Data type PDFs, images PDFs, images PDFs, images Medical Devices Computed real-time from patient Biomarkers / Genetics Computed from specimens Availability Common Common Common Uncommon Uncommon
Structured patient data sources Source Patient Self reported by patient Health Professional Observations by HCP Labs & Diagnostics Specimens Medical Devices Real-time from patient Biomarkers / Genetics Specimens Errors High Medium Low Low Low Time Slow Slow Medium Fast Slow Reliability Low Medium High High High Discrete size Kilobytes Kilobytes Kilobytes Megabytes Gigabytes Streaming size Availability Uncommon Common Somewhat Common Gigabytes Uncommon Gigabytes Uncommon
The need for connected devices 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
What should you be shooting for? The desired integration end state
Don t buy legacy connectivity styles Don t promote this kind of connectivity by buying devices that can only work this way Converters and concentrators are legacy 11073 assumes desire for multi-vendor connectivity
Buy Next-gen physical connectivity Option 1 (hospital IT integration required or no cellular access) Wired Wireless Could be a Home Network, too Option 2 (cellular access and no hospital IT integration required) Wireless, Cellular
Desired Connected End State Device Teaming External Cloud Patient Context Monitoring Device Gateway (DDS, XMPP, ESB) Device Data Data Transformation (ESB, HL7) Cross Device App Workflows Remote Service Remote Surveillance Management Dashboards Enterprise Data Alarm Notifications HIT / EHR Integration Analytics & Reporting Device Management Inventory Shahid s Ultimate Medical Device Architecture
Don t just buy what is built, influence vendors to build what you need Your purchasing requirements must influence vendors roadmaps
Evolve hardware purchase decisions Consumerization of Devices Add language in RFIs, RFPs, etc. that you prefer to purchase devices further evolved to the right rather than the left. Sensors on mobile phones, platforms
Purchase more software-centric devices Consumerization of Apps Add language in RFIs, RFPs, etc. that you prefer to purchase devices with more software customization capabilities.
Require connectivity when purchasing Consumerization of IT Don t buy any more of these
Require advanced integration Changes in Practice Models Don t buy any more of these Multi-purpose with analytical connectivity
How to prepare for better purchasing
Require manageable devices Proper gateway designs allow good multi-device manageability Device provisioning should be centralized Device utilization, security logs, audit logs, and intrusion detection logs should be remotely accessible Vendor should remotely conduct fault management, diagnostics, and emergency support Device settings and parameters configuration shouldn t require medtechs to visit each device New firmware updates and software upgrades shouldn t require human intervention Hospital IT connectivity to EHRs, financial systems, etc. should be built in
Required quality properties Risk management approach that meets or exceeds FDA requirements must be used Safety critical attributes need to be supported based on which devices may connect Scalability and performance based on expected vendor devices that need to be connected Security threats and threat matrix based on both closed (your own company) and open access (across vendors) Reliability that meets or exceeds medical device standards Fault Tolerance that meets or exceeds medical device standards Reusability of design (not necessarily code) across business units Supportability across sectors and business units Maintainability across sectors and business units Testability across sectors and business units
PHI, PII and HIPAA properties Mechanisms of ensuring compliance with Healthcare, HIPAA PHI, and PII security requirements Security policy and procedure creation for crossdevice data collection and dissemination Awareness, training, and education materials for both safety and privacy concerns De-Identifying information must be allowed for research and data sharing Workstation and server IT related security controls that meet or exceed hospital IT environments need to be incorporated
Require evidence of serviceability New device purchase New device purchase with pre-existing service Remote service management Tracking training on device Tracking certifications on device Help desk problem determination Back up and restoration High volume configuration Automatic status reporting Software download and updates Change of service (e.g. adding a new service) Service discovery and provisioning
Structured Data Format Suggestions Item In general Patient Summary Record Standard Follow requirements stipulated by NIST in MU guidance HL7 CDA Release 2 CCD or ASTM CCR Electronic Prescribing NCPDP SCRIPT Version 8.1 or 10.6 Electronic Submission of Lab Results to Public Agencies Electronic submission to immunization registries Quality Reporting HL7 2.3.1 or HL7 2.5.1 HL7 2.3.1 or HL7 2.5.1 The CMS Physician Quality Reporting Initiative (PQRI) 2009 Registry XML Specification
Coded Vocabulary Suggestions Item In general Standard Follow requirements stipulated by NIST in MU guidance Problem List ICD9-CM / ICD10 or SNOMED CT 2009 Procedures CPT-4 / CPT-5 Laboratory test results LOINC 2.27+ Medications Immunizations Any source vocabulary that is included in RxNorm HL7 Standard Code Set CVX - Vaccines Administered, July 30, 2009 version Race and Ethnicity OMB Statistical Policy Directive No. 15
Privacy and Security Standards Item In general Encryption and decryption of electronic health information Record actions related to electronic health information Verification that electronic health information has not been altered in transit Record treatment, payment, and health care operations disclosures Standard Follow NIST 800-53 and related standards SSL/TLS Certificates, NIST FIPS 140-2 The date, time, patient identification, and user identification must be recorded when electronic health information is created, modified, accessed, or deleted; and an indication of which action(s) occurred and by whom must also be recorded SHA-1 or higher (NIST FIPS PUB 180-3) The date, time, patient identification, user identification, and a description of the disclosure must be recorded for disclosures for treatment, payment, and health care operations, as these terms are defined at 45 CFR 164.501
Advances in Wireless Technologies for Healthcare The recording of this webinar will be available on www.draeger.com Also see our past webinars: - The Do s and Don ts of Safety Critical Wireless in Healthcare - Managing the All Digital Hospital - The Changing Role Of Engineering in Healthcare IT - Advances in Wireless Technologies for Healthcare
shahid.shah@netspective.com www.healthcareguy.com Thank you for your time Conclusion and Questions