Medical Device Connectivity

Medical Device Connectivity


John Zaleski on Medical Device Integration: HIMSS Media Interview on Connected Medical Devices

4.29.2015 | 0 Comments

Share

HIMSS Media Announces New Book on Medical Device Integration: Connected Medical Devices

John Zaleski is interviewed by HIMSS Media on his new book on the topic of medical device integration. In this book, titled Connected Medical Devices, he describes best practices for medical device integration. This book is intended for the healthcare enterprise that is beginning the process of integrating medical device data into their electronic health record systems. A link to Connected Medical Devices interview is included here:

John R. Zaleski, Ph.D., CPHIMS–HIMSS15 Interview on Connected Medical Devices

Connected Medical Devices: Integrating Patient Care Data in Healthcare Systems

Within a healthcare enterprise, patient vital signs and other automated measurements are communicated from connected medical devices to end-point systems, such as electronic health records, data warehouses and standalone clinical information systems. Connected Medical Devices: Integrating Patient Care Data in Healthcare Systems explores how medical device integration (MDI) supports quality patient care and better clinical outcomes by reducing clinical documentation transcription errors, improving data accuracy and density within clinical records and ensuring the complete capture of medical device information on patients.  The book begins with a comprehensive overview of the types of medical devices in use today and the ways in which those devices interact, before examining factors such as interoperability standards, patient identification, clinical alerts and regulatory and security considerations. Offering lessons learned from his own experiences managing MDI rollouts in both operating room and intensive care unit settings, the author provides practical guidance for healthcare stakeholders charged with leading an MDI rollout. Topics include working with MDI solution providers, assembling an implementation team and transitioning to go-live. Special features in the book include a glossary of acronyms used throughout the book and sample medical device planning and testing tools.

About the Author

John Zaleski, PhD, CPHIMS, brings more than 25 years of experience in researching and ushering to market devices and products to improve healthcare. Dr. Zaleski received his PhD from the University of Pennsylvania, with a dissertation that describes a novel approach for modeling and prediction of post-operative respiratory behavior in post-surgical cardiac patients. He has a particular expertise in designing, developing, and implementing clinical and non-clinical point-of-care applications for hospital enterprises. Dr. Zaleski is the named inventor or co-inventor on seven issued patents related to medical device interoperability. He is the author of numerous peer-reviewed articles on clinical use of medical device data, information technology and medical devices and wrote two seminal books on medical device integration into electronic health records and the use of medical device data for clinical decision making.

Share

Clinically quantifiable benefits of biomedical device integration (BMDI)?

4.27.2015 | 0 Comments

Share

Historically, clinically quantifiable benefits of connected medical devices within the healthcare enterprise have been measured in terms of time-in-motion studies and workflow relating to time saving associated with accomplish a specific task or end goal. These are valid measures. Yet, the question remains as to whether there is something more tangible clinically that can be used as a measure of effectiveness related to interoperability. The attached white paper captures some of my thoughts on the subject.

Share

Author page setup at Amazon.com

4.10.2015 | 0 Comments

Share

My author’s page is setup at Amazon.com, for those looking for the first two books.

 

Share

Informs 2014 Joint Session on Analytics / Early Warning Notifications

11.16.2014 | 0 Comments

Share

This past week, I hosted a session at the 2014 INFORMS Annual Conference in San Francisco. The title of the session was Clinical Analytics, Informatics and Clinical Decision Making.

The I also gave a presentation titled Early Warning Notifications Using Medical Device Data.

The purpose of this paper was to introduce types of early warning notifications and analytics that can be employed using medical device data retrieved from the bedside medical devices for use in clinical decision making. A copy of the presentation is available via the hyperlink above.

Share

Nuvon Speeds Up The Process with Mobile-To-EMR Connections

11.02.2013 | 0 Comments

Share

Posted October 24th in Phildelphia.RegionsBusiness.com:

On the surface, Nuvon’s mission seems to address a problem most would imagine having been addressed years ago: Its technology platform connects wirelessly with all electronic medical record systems to automatically capture and communicate data.

Its technology connects data from mobile devices — tablets, especially — and seamlessly passes along data to EMRs, regardless of whether they’re inside or outside of a hospital. This saves nurses the pain of having to manually enter data, despite the system being electronic.

Share

Medical Device Interoperability Implementation

8.07.2013 | 0 Comments

Share

Published over at 24×7 Magazine is a piece I wrote on medical device interoperability implementation. This represents a summary of the key aspects of implementation required from an experiential perspective.

Share

Is medical device data safe from the prying eyes of the NSA?

6.13.2013 | 0 Comments

Share

An interesting point on the whole issue of connected health and patient privacy is before us. Medical Device & Diagnostic Industry (MDDI) Online published a piece just the other day entitled “Your Medical Device Data is Not Safe from NSA’s Prism.” The implication is that data collected by patients or their providers from medical devices as part of the process of patient care management may not be private — will most likely not be private — as revealed by the latest news of the NSA’s Top Secret Prism Program.

This blog is not political–never intended to be; never will be. Whether you consider Edward Snowden to be a hero, a traitor, or neither, the key point of this revelation is the exposure of information–and the implication for U.S. Citizens’ 4th Amendment Right to be secure in their persons shall not be violated:

The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.

From the medical device data perspective, the issue is to what end does the sharing of this data serve? Some have come out and said that they have no problem with the sharing of their personal information; that they have nothing to hide; and, if in the sharing this provides for greater societal safety, then all the better. I maintain that this has nothing to do with “having something to hide.” This has to do with trust. We are implicitly trusting people with information that is private and, if found to be in the hands of unethical individuals, can be used in nefarious ways. This concern has nothing to do with intentionally wishing to hide information.

I have and continue to be an advocate for the use of data for the good of improving patient care. My concerns are that in the process of exposing information to individuals not authorized to see it, or to whom we have no knowledge, we are throwing the door open to potential vulnerabilities that can ultimately harm the patient. The first credo of the physician is to do no harm. The potential for harm exists, given exposure of health information to unauthorized individuals.
Share

The physics of medical device connectivity

6.07.2013 | 0 Comments

Share

A note to my followers that I am now also a guest blogger at TheConnectingEdge. In this added role, I’ll be sharing experiences, information and knowledge associated with connecting medical devices in the various departments of the hospital, with emphasis on the hardware connectivity. Hope you will check it out. First entry to appear sometime within the next week.

Share

Personalized Blood Pressure Monitoring Meets the iPhone & iPad

4.24.2013 | 0 Comments

Share

Those individuals who have been following my blog for a while now know of my penchant for technology in healthcare, particularly as relates to the use of data for promoting patient safety, monitoring, and managing patient state. Recently, I purchased the iHealth dock, made by iHealthlabs, shown in the figure below, to evaluate as I do with many other healthcare related technologies. One of my interests is in the use of smartphones for monitoring and managing personal health and well being.

iHealth Docking Station

iHealth Docking Station

The iHealth unit provides a docking station-based automatic sphygmomanometer for either an iPad or iPhone to facilitate blood pressure monitoring and management. The unit (i.e., docking station)
prices out around $100, although I have seen some deals on Amazon.com as low as $35 or so.

Upon purchasing the unit you then download the app from the Apple App Store for free. This is all you need, in essence, to begin self-monitoring blood pressure and heart rate through the unit.

I am the consummate tinkerer. The app that operates the unit provides the user with the capability to transmit readings upon collection and to post to Facebook, Twitter, or email them to…whomever. As medical device integration (MDI) is one of my key focuses, it had immediately occurred to me that what this unit could use was a post-processor that relied on simple, everyday technology available to most people who can use Microsoft products (such as MS Word, Excel, and Powerpoint) so that they can track the information they are collecting.
As a result of this idea, I created a little “toy” of an application based on a Visual Basic Macro that deploys in an Excel spreadsheet. The docking station and app provide the means to email the data collected after each blood pressure measurement. This information I email to an account I set up for myself, and all measurements automatically are posted to a directory within that account. I can take as many measurements as I like–normally 5 measurements at a sitting in order to provide an artifact-free baseline.
The data, once received through email, are then polled by the Visual Basic application. The application reads the email, charts the data, and then provides the capability to display in an Excel spreadsheet for “post-collection” analysis. An example of an automated chart produced by this Visual Basic application is shown below.
Chart created automatically by Visual Basic application created within Excel spreadsheet. Written by John Zaleski. (c) 2013. All Rights Reserved.

Chart created automatically by Visual Basic application created within Excel spreadsheet. Written by John Zaleski. (c) 2013. All Rights Reserved.

The charts that are produced by the app are then output as image files for printing or incorporation into other documents…or for use in communicating with your healthcare provider during your checkups, etc.
Now, a few things to mention about this…notes can be added to the measurements because, lacking context, raw numbers can sometimes be meaningless or even misleading. For example, it is important for the end-user to know that blood pressure measurements must be taken in a quiescent period of little or no movement. As I was simply testing the technology out it is important to understand that many of the measurements I took are, in effect, aberrant (i.e., too high or too low due to artifact). Hence, any in-home use of equipment such as the iHealth dock must be accompanied by proper training in self-measuring of blood pressure, as is the case with any personal health management and monitoring tool.
Share

Latest Medical Device Interoperability Course (Abridged)

3.18.2013 | 0 Comments

Share

The following linkis my latest course charts on medical device connectivity / medical device interoperability given at the Baltimore Smart Tech Conference in November 2012. I decided to post an abridged version of this document based upon popular demand. The document contains some references and information from my earlier books on medical device connectivity and the EHR.

Share

IEEE Smart Tech – Coming to Baltimore November 2nd & 3rd 2012

8.26.2012 | 0 Comments

Share

IEEE Smart Tech is coming to Baltimore this November. Early Bird Registration ends 9 September 2012. IEEE Member cost is $129 and Non-Member cost is $159. Regular registration begins September 10th and the cost goes up 50$ for both Member and Non-Member registration. Reservations and a copy of the workshop agendas can be found at http://www.ieee.org/metroevents.

I am giving a workshop entitled “Biomedical Device Connectivity in Electronic Medical Record Integration” on Saturday, November 3rd. This will be an all-day affair. Topics include:

1. Electronic health records and how medical device data are integrated

2. What it means to integrate data into health information systems–from technical details to workflow implications.

3. Standards in healthcare surrounding medical device data integration.

4. Examples of integration.

5. Future of medical device data integration, including uses of these data to facilitate clinical decision making.

Hope to see you there.

Share

Syndrome Surveillance, Decision Support, and Modeling Critical Illness in Intensive Care

6.15.2012 | 0 Comments

Share
Share

Virtua links medical devices through Nuvon BMDI | biomedical device connectivity

5.17.2012 | 0 Comments

Share

Biomedical device connectivity challenges are being addressed at Virtua by Nuvon, Inc.:

“About three months ago, Virtua went live with a middleware solution (supplied by Nuvon, Inc…. that streamlines the collection of data and eliminates the need to record the data manually from the device…Its first implementation was in the hospital system’s Ors–one of the tougher environments because of the large amount of data being pulled from many devices.”

Share

A new link to an old blog post: Medical Device Open Source Frameworks | Medical device data system

3.26.2012 | 0 Comments

Share

I received a ping to a new comment on an old post I had written on Tim Gee’s site regarding medical device connectivity. The title of the post was Medical Device Open Source Frameworks and in this post I had written about creating ubiquitous connectivity to medical devices through standardized connectivity, similar to the way USB devices operate: plug into a port and they are recognized.

Share

Medical Device Connectivity is only an elementary step toward contextual interoperability

3.22.2012 | 0 Comments

Share

Attending Day 2 of the 22nd Annual AAMI/FDA Summit on Medical Devices.

The importance of medical device connectivity and the medical device data system, or MDDS, ruling taken together with electronic medical record (EMR) technology is, in my mind, driving toward the ultimate goal: how to integrate medical devices as part of the system architecture within the healthcare enterprise to support clinical use cases. The MDDS ruling has, in my mind, had the effect of codifying the methods and mechanisms that relate to communicating durable medical device data to the electronic medical record. Similarly, this has raised the awareness of integrating such information into the EMR charting system. Yet, this is really only the first step in the process.

The interaction of the many systems that clinicians use as part of the care and management of the patient involve interoperability among many verticals in the healthcare environment, to include medical device connectivity. The interaction of data from durable medical devices with the more information-based and clinically specific systems make up the larger medical device data system architecture.

The following figure, referenced from Wikipedia, is one source of the “Interoperability Taxonomy” adapted for presentation during the medical device interoperability presentations.

Levels of Conceptual Interoperability Model (LCIM). Source: Tolk, A. and Muguira, J.A. (2003). The Levels of Conceptual Interoperability Model (LCIM). Proceedings IEEE Fall Simulation Interoperability Workshop, IEEE CS Press

The hierarchy presented in the figure above maps well to medical device connectivity. The first three levels, that is level 0 – level 2, correspond, respectively, to medical devices that are not connected; medical devices that have some form of physical connectivity; and, medical devices that support the ability to syntactically communicate data with other medical devices as well as with information systems using methods such as HL7 messaging. Many hospital systems today that feature medical device connectivity are in the Level 0 to Level 2 range.

Higher levels of interoperability, such as semantic interoperability, are works in progress and organizations such as IHE are engaged in areas of syntactic, semantic and pragmatic interoperability.

The definitions offered per the LCIM model are as follows:

  • Level 0: Stand-alone systems have No Interoperability.
  • Level 1: On the level of Technical Interoperability, a communication protocol exists for exchanging data between participating systems. On this level, a communication infrastructure is established allowing systems to exchange bits and bytes, and the underlying networks and protocols are unambiguously defined.
  • Level 2: The Syntactic Interoperability level introduces a common structure to exchange information; i.e., a common data format is applied. On this level, a common protocol to structure the data is used; the format of the information exchange is unambiguously defined. This layer defines structure.
  • Level 3: If a common information exchange reference model is used, the level of Semantic Interoperability is reached. On this level, the meaning of the data is shared; the content of the information exchange requests are unambiguously defined. This layer defines (word) meaning. There is a related but slightly different interpretation of the phrase semantic interoperability, which is closer to what is here termed Conceptual Interoperability, i.e. information in a form whose meaning is independent of the application generating or using it.
  • Level 4: Pragmatic Interoperability is reached when the interoperating systems are aware of the methods and procedures that each system is employing. In other words, the use of the data – or the context of its application – is understood by the participating systems; the context in which the information is exchanged is unambiguously defined. This layer puts the (word) meaning into context.
  • Level 5: As a system operates on data over time, the state of that system will change, and this includes the assumptions and constraints that affect its data interchange. If systems have attained Dynamic Interoperability, they are able to comprehend the state changes that occur in the assumptions and constraints that each is making over time, and they are able to take advantage of those changes. When interested specifically in the effects of operations, this becomes increasingly important; the effect of the information exchange within the participating systems is unambiguously defined.
  • Level 6: Finally, if the conceptual model – i.e. the assumptions and constraints of the meaningful abstraction of reality – are aligned, the highest level of interoperability is reached: Conceptual Interoperability. This requires that conceptual models are documented based on engineering methods enabling their interpretation and evaluation by other engineers. In essence, this requires a “fully specified, but implementation independent model” as requested by Davis and Anderson; this is not simply text describing the conceptual idea.

 

 

Share

MDDS and AAMI SW87 — Quality System for MDDS?

3.21.2012 | 0 Comments

Share

Day 1 of the 22nd Annual AAMI/FDA International Conference on Medical Device Standards and Regulation in Herndon, VA is concluded and a lot of good material to report on. Key first item is the  AAMI SW87 document which aims to focus the FDA Quality System Regulations (QSR) on the  development of MDDS. A training webinar is scheduled for April 12th, 2012. For particulars, visit the AAMI web site.

The SW87 document was produced in 1 year and is focused on MDDS development. The SW87 defines MDDS as follows:

Per 21 CFR 880.6310, “a medical device data system (MDDS) is a device intended to providde one or more of the following uses, without controlling or altering the functions or parameters of any connected medical devices

(i) The electronic transfer of medical device data

(ii) The electronic storage of medical device data

(iii) The electronic conversion of medical device data from one format to another format in aaccordance with a preset specification; or

(iv) The electronic display of medical device data

An MDDS may include software, electronic or eletrical hardware such as a physical communnications medium (including wireless hardware), modems, interfaces, and a commmunications protocol. This identifiation does not include devicess intended to be used in connection with ‘active patient monitoring.'”

I intend to cover other aspects of the meeting, including a medical device interoperability taxonomy, in tomorrow’s blog entry.

 

Share

Durable Medical Device Data and Clinical Decisions

3.16.2012 | 0 Comments

Share
EMBS - Zaleski - 1998

Page from EMBS publication on modeling post-operative respiratory state

Back in 1998 I wrote my first scholarly article on the topic of modeling as it relates to human body systems. The focus of the article was to demonstrate how data collected from bedside medical devices could be used to model specific behaviors and trends that could then be used for predicting future state in critical care patients. This paper was published in IEEE’s EMBS magazine.

Throughout the years I have kept a close eye on the subject of data and clinical decisions based upon data. This is what led to the writing of my second book.

As electronic medical record (EMR) systems have advanced and evolved, the subject of data and clinical decisions has evolved as well, and for good reason. Many illnesses can be better managed or even detected through the collection and management of data, both form durable medical devices and laboratory instruments. A key illness among them is sepsis. Going back to 2008, Health Data Management described the use of bedside data that fed physiologic monitor based models for detecting sepsis in near real time.

Sepsis, or septicemia, is a leading cause of death in ICUs, especially among the elderly. The CDC reported in 2008 that the cost of sepsis management alone broached $14.6B (source: HealthLeaders Media). According to the same source, “[h]ospitalizations for … sepsis as a [primary] diagnosis grew from 326,000 in the [year] 2000 to 727,000 in 2008.” The number is not declining in 2012.

A key element in the management of sepsis is data. Data and clinical decisions surrounding changes in body temperature, heart rate, elevated white blood cell count OR lower-than-average temperature are also signs. Elevated pulse, highe respiratory rate in combination with these and other parameters such as end tidal CO2 changes are all measurable quantities. When combined these data are instructive as to cause. Many elements can be retrieved from the physiologic monitoring equipment, laboratory information systems and other devices (mechanical ventilators) that reside at the bedside of the patient.

It is important to realize that the completeness of the electronic medical record is not just in the notes that are recorded by the clinician at the bedside of the patient, but also in terms of the availability of all information recorded on the patient. Together, this information provides a powerfully instructive set that, when properly mined and properly analyzed, can lead to prospective assessments and early diagnoses of potentially life-threatening ailments…and the source of this rich information is data.

 

 

Share

Faster migration to market motivates medical device data system (MDDS) compliance?

2.25.2012 | 0 Comments

Share

The HIMSS 2012 Daily Insider on Tuesday, February 21st included an article entitled “Agility Through Regulation,” discussing the incentive the final FDA ruling on Medical Device Data Systems (MDDS) has had on enterprise-wide medical device connectivity. This article by Mary Carr discussed the motivation that the MDDS ruling, made by the FDA in February 2011, had on hospitals to begin their migration away from piecemeal, home-grown connectivity solutions and to align on enterprise-wide solutions. The objective in aligning on system-level integration is to foster homogeneous interoperability and connectivity, both at the durable medical device level and informationally through the various healthcare information systems throughout the hospital.

The MDDS ruling by the FDA reads in part:

“…This regulation classifies as class I MDDS only data systems with specific intended uses and functions. Those device data systems that include any uses beyond, or that are for intended uses different from, those identified for an MDDS will remain class III devices. FDA has determined that MDDSs can be regulated as class I devices because general controls provide a reasonable assurance of safety and effectiveness for this device type. In making this determination, FDA has considered that the risks associated with MDDSs are generally from inadequate software quality and incorrect functioning of the device itself. These failures can lead to inaccurate or incomplete data transfer, storage, conversion according to preset specifications, or display of medical device data, resulting in incorrect treatment or diagnosis of the patient. Based on FDA’s knowledge of, and experience with, MDDSs, FDA has determined that general controls will provide a reasonable assurance of safety and effectiveness of MDDSs, such that special controls and premarket approval are not necessary to provide such assurance.

“…Based on the preamble to the proposed rule, and the comments received in response to the proposed rule, FDA is now finalizing the reclassification of medical device data systems from class III to class I. This classification will be codified at 21 CFR 880.6310. To meet the definition of an MDDS under § 880.6310, a data system must be intended for the ‘‘transfer,’’ ‘‘storage,’’ ‘‘electronic conversion * * * in accordance with a preset specification,’’ or ‘‘electronic display’’ of medical device data, ‘‘without controlling or altering the functions or parameters of any connected devices.’’ This classification excludes any data systems with intended uses outside the scope of this rule …

“…an MDDS only communicates medical device data. For purposes of this rule, data that is manually entered into a medical device is not considered medical device data. However, if manually entered data is subsequently transmitted from a medical device as electronic data it will be considered medical device data. A device that then transmits that data or is intended to provide one of the other MDDS functions with regard to that data may be an MDDS. In response to requests for clarification, the use of ‘‘real time, active, or online patient monitoring’’ in the proposed rule has been replaced to indicate that an MDDS is not ‘‘intended to be used in connection with active patient monitoring.’’

Ms. Carr identified several key and salient points related to the FDA’s position on the integration of durable medical device data:

1) Piecemeal integration leads to silos and organic separation of information. My comment: piecemeal separation is anathema to large enterprises interoperability in which patients need to be transferred around the hospital. This makes for difficulty in sharing of patient information as needed as they roam or are moved from department to department.

2) Silos are often unable to deliver real-time patient data reliably to centralized information systems. My comment: data synchronization to ensure the latest time-aligned data may be absent.

3) Vendor-dependent solutions lead to internal battlegrounds. My comment: this will be a challenge for some time to come. In my opinion, and based on the industry at-large, the right answer is to target enterprise-wide solutions that meet the scalable and flexible needs of the institution and allow for expansion and growth. Eventually, durable medical devices will speak in accordance with common physical and semantic standards, and this problem will go away (see the IHE PCD Wiki).

In both of my books I have written about the need for ubiquitous medical device data integration. It has taken a long time (decades) to reach the point of some commonality in terms of semantics and messaging since I started out in the field. It will take a while longer to achieve will interoperability of medical devices in the physical connection department. The focus will need to shift on the use of the data for clinical decision making. Some medical devices are beginning to make the shift to network connectivity as their primary physical mode of communication and transmitting HL7 transactions from the machine itself. Many medical devices will need to make this shift. Furthermore, the ability of medical devices to accept commands from external systems is an aspect that needs to happen to support higher-order command and control (C3I) type functions that make use of extended situational awareness around the device and the patient. Again, I believe this is beginning to happen and will continue to happen. It is a matter of time and continued proselytization. The era of data collection from durable medical equipment where I began my healthcare career some 20 years ago has changed some in this department and will change further. I believe we as an industry are on the verge of a breakthrough and great acceleration in this department.

Share

Automated data collection is a key enabler for comparative effectiveness research

2.14.2012 | 0 Comments

Share

When I began conducting my own research ~20 years ago, I envisioned interaction among large numbers of databases from which I could automatically draw needed information to assemble the models I required to verify performance of one patient in comparison with a population of patients having the same specific characteristics. The comparison of a test patient with a population was not only the basis for my predictive methodology but a basic tenet of Bayes’ Theorem and conditional probability. I envisioned back then a day would come when all the data I was attempting to cobble together by hand and by computer would be readily available… perhaps 10 years down the road.

Fast forward to today.

In the AHRQ’s opening FAQ about what comparative effectiveness research (CER) is, they state that, they state that “Comparative effectiveness research is designed to inform healthcare decisions by providing evidence on the effectiveness, benefits, and harms of different treatment options.”

Physicians rely on evidence, in the form of corroborating (and some contradictory) studies to validate and verify hypotheses related to treatment. Accepted treatments and approaches for care are those most usually associated with corroborating evidence–a great deal of corroborating evidence. Not all data arrive in the form of simple measurements. Data take on the form of studies, published research papers, laboratory results, films, guidelines, textbooks, and from bedside medical devices.

To a degree, the electronic health record (EHR) was seen as a key element in achieving the type of data richness that was necessary to support comparative effectiveness research. The EHR and its adoption are necessary but (yet) insufficient in terms of the CER enterprise. In “Optimizing Health Information Technology’s Role in Enabling Comparative Effectiveness Research“, Navathe and Conway note that “…[f]or CER to be conducted, …EHRs must be connected to data networks enabling access to at least portions of their captured data. It will be challenging to implement EHRs on a large scale and to develop electronic networks substantial enough to produce observational data that alter clinician, patient, and other decisions.”

As Navathe and Conway state, healthcare data is not just personal, it is a strategic asset upon which basic research depends. Despite visions of a unified, singular database “Borg” where all data would go to be mined endlessly by large mainframes, the facts most probably near term and into the future are that data will be federated. They will reside in many different pockets “owned” by many separate and disparate institutions large and small. The key, then, to my mind, is not figuring out how to assemble them into some common structure, but enabling their inter operative interaction, much the way the Internet operates today. When we type in a Google query, we are not interacting with some great big “WOPR” computer (references to the 1983 movie WarGames), we are interacting with millions of computers around the world.

What I did not realize 20 years ago that I have finally come to realize is that I thought then the “hard” problem was solving the predictive model for the patients I was monitoring, when the really hard problem was assembling all of the data together from the many disparate sources. Through all of the standards committees and claims of interoperability, we are really a long way off in terms of enabling the one thing that would allow us to do what I had started out almost 20 years ago doing: automating the data collection, from any source, that would allow us to focus on the real business of health care research, and would enable the vision of comparative effectiveness research.

Share

Medical Device Alarms and the MIMIC-II Database for Multiparameter Data Modeling

2.06.2012 | 0 Comments

Share

Some months ago I meant to put this on the blog and it has been sitting in draft form wallowing.

In reference to the medical device alarms topic, there is a very good source for high frequency and fidelity monitoring data. The MIMIC-II database is an excellent source for waveform level modeling data taken from critical care patients and deidentified for use in research. A key reference for the scope of the data found in the database (which is generally available for access at no cost) can be found in the following paper:
Saeed et al:, Multi-parameter Intelligent Monitoring in Intensive Care II (MIMIC-II): A public-access intensive care unit database

Share

Wordpress SEO Plugin by SEOPressor

Switch to our mobile site