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.

Months ago I wrote about the AAMI Summit on Clinical Alarms. This prompts some ideas for research to mitigate nuisance and general patient medical device alarm problems:

1. improving signal to noise (specifically, sensitivity / specificity): reducing data overload / information underload would limit “nuisance” alarms;
2. need for device intelligence: for example, the medical device alarm has context for which awareness and the ability to adapt to a specific situation would reduce the occurrence of artifact;
3. human-machine interfaces: improved usability through refined/redesigned human / machine sensory interface;
4. multisource data fusion: integration of data from multiple devices in a manner that provides for a fusion of knowledge and situational awareness that would not be available from these devices separately; and,
5. historic and prospective trending: deterioration trending of patients over time using historic data as well as models of prospective evolution.

Historic information provides some notion of what is risky for patient: events and information from multiple sources can establish an a prior assessment of whether a patient is experiencing distress. These conditions are not unique and have been seen previously by multiple clinicians over time. Hence, the historical information can be a great filter for establishing what is real and what is not real in terms of alarms and medical device alarm management. Just as automatic feedback control systems provide a feedback to the plant model as to deviations from expected performance, such is analogous with medical device alarms.

Part of the challenge is how to combine the information from multiple sources. This combination of information is not simply co-displaying them in a common format or user interface. It is presenting the data intelligently to the end user, possibly in a processed manner that determines, based on their combination, whether the result is a bona fide alarm condition. This rather cerebral aspect of the processing is the dilemma. Leaving out even the regulatory aspects of the situation, understanding what the processing is actually doing–the “plant” part of the automatic feedback control system–must be represented accurately.

A medical device alarm from a single device provides an indicator with respect to the sensors that are being measured for that one device. For instance, a physiologic monitor that is only measuring pulse and ECG cannot report an alarm on End Tidal CO2 or respiratory rate. On the other hand, a mechanical ventilator cannot report an alarm on heart rate or on ST segment elevation. The two devices report medical device alarms according to their particular sensors and objectives. However, the combination of the two devices can provide corroborating evidence. For instance, an ASYS alarm could be caused bya lead disconnecting from the physiologic monitor or from the patient. But, an ASYS alarm occurring at the same time as an APNEA alarm would provide corroborating evidence. This is rather a tragic example, but one that demonstrates the correlation of two events.

The fusion of multi-source devices can also provide a mechanism for reducing data overload while at the same time increasing useful information is one that I find to be very interesting. There are many research efforts surrounding modeling. Yet, integrated system modeling (multi system integrated assessments) has really yet to be shown (publicly) as viable in medicine–and generally accepted in operational use, not to mention for medical device alarms.

I would like to leave this here for now and follow-up in more detail on these areas. The medical device alarm field is fertile ground for integrated systems engineering application.

Yesterday I attended an NSF grant status review at the University of Pennsylvania. I had a chance to visit with some old friends of mine and to reacquaint with some new friends. It is striking to me the energy in the area of systems engineering in the medical field that has taken place since I was a student there some 16-20 years ago. When I was a student at PENN, the notion of applying systems engineering to medicine was not even a field: it was the study of one lone student in the department. I am happy to see such growth.

While I cannot get into the specifics of the discussions of the various projects, I will lend my overall impressions vis a vis the types of concepts that are being focused on, and that are a major focus in healthcare and medicine today.

Useful use (as opposed to Meaningful Use) of data within the enterprise is a huge objective in the treatment of patients:

1) using past information and history to assist in reducing the likelihood of readmissions;

2) better management of those patients, particularly in critical care who are likely to suffer from sepsis, ventilator acquired pneumonia, etc.;

3) reduction in the number of medical device alarms that bombard the clinicians;

4) better use of integrated information through application of interoperability standards.

All of these areas are of high value. As I noted in my “outbrief” at the end of the meeting, my views, while highly motivated by pure research, are more governed by the pragmatic from the perspective that I live with customers and their problems, and this motivates me to write on areas that are both pragmatic but motivated by research interests of my own.

The term “Big Data” has often been used, and by itself is nothing more than marketing tripe. To my mind, systems engineering and the various concepts related to it, from situational awareness to systems of systems engineering, has been around a long, long time, primarily as related to the aerospace/defense industry (a former industry of my own). What is becoming more and more clear is that the effective use of data–not just mining it for whatever trend falls out of the net–is the real value. Combining specific information associated with diagnoses and then determining from that which patients are likely to be readmitted; which patients are likely to respond favorably from a certain course of treatment, etc. are outcomes assessments that carry with them great value but also great responsibility.

Pragmatically, most hospital systems that I have been involved with professionally are still at the stage of connecting the dots: getting information from point A to point B. As is typically the case, large academic research institutions are out in front looking at the why and wherefore of what to do with the information–the futuristic. Once something becomes generally accepted in clinical practice, that is when the futuristic becomes commonplace.

Yet, something else is happening now: I see even smaller community hospitals beginning to look at the futuristic from the perspective of how it can assist in the commonplace practice of medicine. It is not just the matter of connecting the dots of how data gets from one point to another; or how certain functions (e.g.: CPOE, eMAR) need to be rolled out into the institution, but what happens with the information after that. Interestingly, a motivation for this is the care and management of patients with chronic ailments and/or co-morbidities. Managing the patient once he or she leaves the hospital is of much more interest, regardless of the size of the institution.

Assisting in this management is the effective study of past history and increasing situational awareness surrounding patients in their home environments as well as in the hospital and how they compare with respect to peers. This is the focus and benefit of big data–where it is going. And we are at the beginning.

“Safety is a system” is how Farzad Mostashari, national health IT coordinator, emphasized his stance on electronic medical record (EMR) system software in the wake of the Institute of Medicine (IOM) report on the safety of health information technology and the need for a new agency to oversee regulation of health information technology. This is reported by HealthcareIT News in the wake of the IOM’s report on patient safety and healthcare IT systems. Systems engineering plays prominently in the safety equation between efficient workflow and effective patient care management. As of this writing, I have read through the first 50 pages of the report myself and am making rapid progress. However, of key note are the points in bold right up front that “lack of system interoperability is a barrier to improving clinical decisions and patient safety.”

While much of my focus on integration of medical devices has been the ubiquity with which medical device data can be integrated into clinical systems, the general point of interoperable system architectures (similar to systems of systems architecture) is a key point behind the patient safety and effectiveness argument.

Why?

Because, among other reasons, access to data is restricted when systems are not interoperable. Another reason is that differing semantics (commonality of definitions, lexicon, terms) makes for a healthcare “Tower of Babel,” wherein separate systems are not aligned in their ability to communicate. This is not just physical interoperability–it is semantic interoperability. These problems, among many, are key and require an overarching systems engineering integrator to facilitate architecture and alignment.

In our recent IEEE-AMA paper on liberating medical device data for research, we described the need for semantic interoperability. The problem of aligning separate EMR systems, laboratory systems, registration systems, and medical devices is a system of systems problem: systems engineering. The Department of Defense has recognized for decades the need for systems engineering. The need to meet MIL-SPECs and standards is a tacit requirement of any military system. Why is this not the case in healthcare? There is HL7, but as anyone who has worked with HL7 might indicate, there are many “flavors” of standardization and messaging requirements that can vary by vendor, by application, by enterprise. The idea of an interface control specification or document (ICD) that can be used to establish a common set of requirements among vendors is truly required. Again: systems engineering at work.

Innovation one of top 4 strategies for FDA CDRH

The FDA has posted a new publication, “Medical Device Pre-Market Programs: An Overview of FDA Actions” underscoring the work they began two years ago in terms of focusing on “smart regulation”:

 The FDA acknowledged that the top two problems they found with their pre-market program. These were lack of predictability which can cause cost impacts and inefficiencies on government and industry. Furthermore, lack of predictability impacted small companies (typically bringing innovative technologies forward) that could impede market introduction.

Sources for the innefficiencies were cited as being related to governmental bureacracy, turnover, and staff training (both in government and in industry). As a result, the FDA identified specific actions with the objectives identified as follows:

1. Create a culture change toward greater transparency, interaction, collaboration, and the appropriate balancing of benefits and risks;
2. Assure predictable and consistent recommendations, decision making, and application of the least burdensome principle; and
3. Implement efficient processes and use of resources.

The report can be read at the link provided above.

Tough Week for Blogging on Healthcare

This has been a very tough week, and although I have made a point of attempting to make at least 1 blog entry per day, it simply was not possible due to the business of my schedule and travel. This coming week is no better. However, I felt strongly motivated to take a moment while (finally) at home to make a blog entry while I get ready to pack for my next trip tomorrow… at least my cats still recognize me.

But, Steve Jobs’ death at the age of 56 is a blow in more ways than one. He was a creative genius. I liken him to Nikola Tesla in some ways for his uniqueness as well as his personal behavior–both the oddities and the passion. But, unlike Tesla, Jobs knew how to manage a business: he had both creative genius and business acumen, and this combination is even more rare than creative genius alone. There are many creative geniuses who have brilliant ideas that are manifested as tinkering in their garages, and who die penniless and / or insane. However, it is more rare for the creative genius to recognize and tap into that which can be commoditized and marketed in a way that the public will seek — nay — will run to as a “must have.”

This, to me, is sheer brilliance. I wish I had this talent!

Healthcare and Apple

HealthcareITNews had a piece recently on the legacy Steve Jobs is leaving in terms of the Apple products and their impact and use on healthcare. While healthcare per se was not Apple’s forte, the platforms and the ubiquity of the appliances and the application infrastructure are well designed, easy to use, and provide the perfect infrastructure for deployment of applications as well as usability. I have written on Apple, healthcare and technology in the past. The ability to support web-based applications in a palm-based platform (iPhone) that can support both external device connectivity (through USB) as well as providing camera, high resolution user interface, and the ability to support and share applications through the Apple Story mean that the sky is the limit.

I have spent a fair amount of time writing my own personal applications and learning the iOS SDK and there are enormous possibilities and untapped benefits that have yet to be realized. Many web-based applications from EMRs to software applications ranging from image-based viewing (picture archiving, or PACS) are readily available. The use of the iPhone or the iPad for interactive note taking, electronic medical record interaction, or applications are well represented through the Apple Store.

Healthcare and Medical Device Connectivity using iPad

Apple iPad2 (Source: iMedicalApps.com)

There are many iPhone and iPad knock-offs out there. All have their relative benefits. But, Apple will always be the first in terms of commercial appeal. Although there are some additional features I would like to see in the iPad (I’m sure Apple is hanging on every word I write), one of the key gaps I currently see is in the lack of multiple USB ports for connecting to external devices. Their single 30-pin interface (image shown below) provides for mapping to USB. However, it is the only hard-wired external interface available from the unit. This limits somewhat the capabilities for tertiary device connectivity given the iPad or iPhone is docked within a docking station or otherwise connected to charging power.

Apple 30-pin interface connector for use in healthcare connectivity (source: WikiMedia.org)

From a clinical environmental perspective, iPhone and iPad are not of medical grade (i.e., satisfy UL 60601-1-1 requirements, etc.). However, for physician use remotely or for personal use within the healthcare environment at the point of care, these are very capable for private, individual use. However, for general purpose use by staff in environments where the potential to drop the units or where they may receive rough use, these are probably not the best tools for the trade.

Healthcare into the future

Steve Jobs’ legacy may be the passion and creativity of his vision that has been passed on to individuals who can see the application potential of the technologies he created in many areas, not just healthcare. I know from my own perspective that he has inspired me.

Thanks for visiting Medicinfotech.

Medical Device Alarms Summit

The impending Medical Device Alarms Summit has caused me to do some research into the area of medical device alarms in general, and has also caused me to go back and review old papers and research of mine that are related. The conference coordinators provided links to some research material, and this research material also caused me to dig up some references to papers by one of my former advisors, CW Hanson, and colleague Bryan Marshall of PENN. Their paper, “Artificial intelligence applications in the intensive care unit,” (Crit Care Med 2001 Vol. 29, No. 2) is referenced within one of the recommended research articles co-authored by Michael Imhoff and Silvia Kuhls, titled “Alarm Algorithms in Critical Care Monitoring,” (International Anesthesia Research Society, 2006, 0003-2999/06).

Critical Care Medical Device Alarms

Imhoff describes the three classes of medical devices responsible for alarms can be classified into the categories of monitoring, therapeutic to “support or replace failing organs,” and therapeutic to “administer medications and/or fluids to the patient.” While medical devices have evolved in the area of providing closed-loop control in the form of feedback from the patient through sensors, Imhoff describes two key issues that remain in the area of medical device alarms. These are:

1) Identifying conditions for which an alarm needs “to be thrown”, and

2) the consistent and unambiguous annunciation of the alarm in a manner that makes it clear to the end-user that a critical event has occurred and can be differentiated from other such events.

 Classes of medical device alarms

In my work and my experiences, the types of medical device alarms have been legion. Imhoff describes several classes of alarms, and I will further characterize these as clinical versus technical. I view technical alarms as those that identify conditions within the device itself. For example, if a device disconnects from a patient (e.g.: a probe falls off, or a cable disconnects, or the device ceases to communicate with the middleware or interfacing system). These types of alarms, Imhoff explains, can have clinical impact. This, of course makes sense for somewhat obvious reasons.

The second class of alarms are those that are clinical: identifying conditions based on measurements made from the monitoring or therapeutic devices of danger or impending danger (e.g.: heart rate too low or too high, blood pressure too low or too high, O2 saturation too low, etc.). These types of conditions are those for which one expects alarm to be “thrown.” However, as Imhoff puts it, the failure of the technical architecture can result in the inability to detect the clinical conditions. Again, this is quite obvious. Ergo, it is necessary to notify of both technical as well as clinical failure since the failure of the technical will result in the inability to detect the clinical, especially when considering remote monitoring environments.

Medical Device Alarms and False Alarms: Detection & Modeling

Imhoff & Hanson both describe and discuss modeling and prediction techniques for identifying conditions, monitoring and modeling approaches for predicting future trajectory, that involve many different types of techniques. Key among these are artificial neural networks, fuzzy logic, Kalman filtering, Bayesian estimation, least squares filtering, and others.

In my dissertation, “Modeling post-operative respiratory state in coronary artery bypass grafting patients,”  and in the EMBS paper that followed it, found in the EMBS paper “Modeling Spontaneous Minute Volume in Coronary Artery Bypass Graft Patients,” I describe a template-based approach for predicting viability for spontaneous breathing trials. The key points being that, from a regulatory and a predictability perspective, most methods require large amounts of patient data in order to develop reliable and predictable outcomes. Deterministic behavior is required, especially for FDA approval of such methods. Hence, many methods have remained in the realm of research and clinical trials because of this. Nonetheless, the ability to reduce the overall effects of alarm fatigue and better predictability as well as improved forecasting of patient outcome remains a fertile area. I intend to report on the outcome of this workshop and am quite interested in the discussions that will ensue.

For further reading, I will (of course), point the reader to one or both of my books:

Integrating Medical Device Data into the Electronic Medical Record: A Developer’s Guide to Design and a Practitioner’s Guide to Application

John Zaleski -- Book I

and, Medical Device Data and Modeling for Clinical Decision Making:

John Zaleski -- Book II

Medical Device Alarms

I will be attending and reporting impressions on the Medical Device Alarms Summit (brochure here), scheduled for October 4th and 5th. This is an important gathering to discuss the topic of alarms used to intervene and guide patient care. Topics will range from false alarm reduction to fuzzy logic and management of alarm calls to minimize fatigue in the clinician.

Time synchronization of medical device data: a straightforward example

The following slides were generated by this author and presented at the FDA Workshop on Interoperable Medical Devices in January 2010. Perhaps an esoteric but important challenge in patient care management and clinical research is the time alignment of data streams automatically collected from patient care devices (PCDs). Data collected from individual patient care devices may contain (1) local time stamps from the devices themselves that are not synchronized with common clocks; and, (2) queries of these patient care devices for their data may not be synchronized with independent queries for similar data from other patient care devices, resulting in data that are not synchronized with one another.

This case is illustrated in Figure 1 below in which a sampling of multi-parameter data collected from a patient who has undergone coronary artery bypass grafting surgery is being monitored in time. As can be seen the plots of individual parameters (again, only a small subset shown) describe the evolution over time.

Figure 1: Continuously monitored data from multiple patient care devices collected on coronary artery bypass grafting patient

Discrete data points show lack of time synchronization

In Figure 2, the individual data points from the separate patient care devices are overlaid on the continuous data, illustrating that these discrete points are not time synchronized in terms of their query or resulting output.

Figure 2: Time synchronization of individual data points from patient care devices not enforced

Data reporting at any particular instant illustrates time synchronization need for patient care device data

the plot of Figure 3 illustrates the need for time synchronization of patient care device data. Should a data request from all devices be made at a particular instant, certain data may be “stale.” That is, lack of time synchronization can result in data that are old or not current. If the query frequency of data associated with a patient care device not be aligned in time, then should a request for data be issued, the data that are available may be that which is valid at a previous time stamp.

Figure 3: Example data reporting time showing the lack of alignment of data availability for multi-parameter devices that may occur due to lack of time synchronization

Lack of time synchronization may impact clinical decision making

Figure 4 illustrates further the possible implication of lack of time synchronization: data staleness associated with misaligned or non existent data.

Figure 4: lack of time synchronization of patient care device data may impact clinical decision making

Alignment with absolute time also impacts time synchronization as each patient care device may not be using standard time clocks

Figure 5 illustrates a further complication to time synchronization: the lack of a common time clock. Should patient care devices not use or synchronize to common time standards (such as network time services within the enterprise), then the very real and common problem of time offsets will exist. The net effect of this is to cause a bias or shift offset of time in terms of data collection, making the process of time synchronization impossible to solve.

Figure 5: bias shift or offset in terms of non-standard clock usage by patient care devices

Hazards and risks associated with patient care devices whose data are not time synchronized

Figure 6 summarizes the potential hazards of receiving and using data from patient care devices whose data are not synchronized in time.

Figure 6: time synchronization -- hazards

Clinical Decision Support impacts on non-time-synchronized patient care device data

Figure 7 summarizes the impacts of time synchronization on real-time clinical decision making.

Figure 7: time synchronization impacts on clinical decision support

The end state: time synchronization of patient care device data

Figure 8 illustrates the objective: when data from patient care devices are not available at a particular reporting time, provide the capability to “fill in the gaps” by querying for these data.

Figure 8: time synchronization end state showing gap-filling of patient care device data

 Time synchronization summary

As a result of this workshop and other efforts, IHE (Integrating the Healthcare Environment) created a workgroup to begin to address what became known as Asynchronous Data Query (ADQ). The work of this group is to establish a common transaction for retrieving time-synchronized device data from patient care devices.

Other resources on this topic include my research at other locations on this site. Thanks for visiting http://www.medicinfotech.com.

AMIA Recommends Human Oversight of Clinical Decision Support Systems

HealthcareITNews is reporting a recommendation by AMIA–The American Medical Informatics Association–is recommending to the FDA that special attention be paid to clinical decision support systems that provide automatic or autonomous recommendations to users without proper licensed professional vetting. Furthermore, special attention should be paid to mobile devices–particularly those operating with patient care data.

Clinical Decision Support Recommendation by AMIA CEO:

Dr. Ted Shortliffe, CEO of AMIA, stated: “AMIA’s comments are premised upon practical evidence that the health sector is exploding with an array of clinical information systems for potential use in a broad range of settings.”

Dr. Shortliffe continued:

“A growing volume of research demonstrates that health information technology in many forms and on many kinds of devices can improve the quality and safety of patient care, and promote efficiencies in overall care delivery. In this modern era of ubiquitous electronic data and access, it is important to have regulations that keep pace with clinicians – many of whom are becoming quite expert at using technology to access pertinent information, and thereby streamlining healthcare delivery and improving overall health,”

Clinical Decision Support Definitions

OpenClinical Definition: “Clinical Decision Support Systems are “active knowledge systems which use two or more items of patient data to generate case-specific advice”  [Wyatt J, Spiegelhalter D, 1991].

Clinical DSSs are typically designed to integrate a medical knowledge base, patient data and an inference engine to generate case specific advice.”

Other links to clinical decision support resources:

Clinical Decision Support Book

Clinical Informatics Post

Polycom SpectraLink here.

SpectraLink as Nursing Workflow Tool:

From eWeek.com: “Polycom is taking enterprise-grade VOWiFi to a higher level of functionality and performance with the introduction of the 8400 series handsets,” Craig Mathias, principal of wireless-communications consulting company Farpoint Group, said in a statement. Mathias said the SpectraLink products’ “thin-client approach” should appeal to enterprises.

Doctors and nurses can also communicate with colleagues over the Microsoft OfficeCommunications Server IM (instant messaging) client and via push-to-talk functionality. In addition, the SpectraLink’s “snap in, snap out” battery packs will work well in 24-hour operations such as hospitals, Guderian said.”

Medical Device Connectivity for Mechanical Ventilators

Included here is a trackback to Tim Gee’s MedicalConnectivity Consulting web log on mechanical ventilator connectivity. This refers to the Remote Mechanical Ventilation Manager that was developed several years back. That link is actually provided here that I first presented at the Northeast Biomedical Device Conference some years back, and the essence of which is described in Book I:

A 5 lb physiological / vital signs monitor

Found this small physiological vital signs monitors, the VitalPoint(r) Pro, located on this site here. This caught my attention not only because of its size, but also because it has extra-enterprise uses (home health use). I like small devices because they are light, agile, and can be used in alternative locations other than intensive care, emergency departments, and operating rooms. I’m going to continue my research on these devices because smaller makes them able to be integrated with electronic medical record systems. This makes them scalable and usable by the folks.

mHealth link to an interesting article involving iPhone Application development

Link to iPhoneMedicalApps.com has a nice piece on the use of iPhone technology in the mHealth application environment. The development of iPhone applications in general has expanded enormously over the course of the last 2 years and the healthcare application area involving the mobile health platforms and infrastructure — mHealth 2.0 — has been tremendously enabled via the ubiquity and access of the iPhone and other appliances (for example, Android).

The key is that there is not slowing in this market, and the limitations are only those associated with the creativity of the developers. So, mHealth will be an enormous growth field into the future as far as the eye can see.

Is FDA 510(k) clearance a get-out-of-jail-free card?

CMIO.net has an interesting follow-up to the IOM assessment of the FDA 510(k) process. Anyone who has brought medical devices forward to market understands the onerous nature of the 510(k) application, the quality system regulations (QSR)and the general adherence requirements. Nonetheless, I am an advocate of the discipline and rigor required by the QSR and good manufacturing practices in general. The creation of a quality product mandates discipline, proper design documentation, reference to source material, and rigorous testing. This last piece cannot be overstated: rigorous, destructive testing is ABSOLUTELY necessary for any product.

FDA 510(k) Relies on Substantial Equivalence

When submitting an application as part of the 510(k) process, the key for any manufacturer seeking the least burdensome route is through identifying substantial equivalence to existing products on the market. Substantial equivalence essentially identifies that the product you are attempting to bring forward is overwhelmingly similar in function, behavior, and interaction as an existing product on the market. Therefore, pre-market approval is not necessary as this does not represent a breakthrough in the basic science and the ability to engage in costly and time consuming clinical trials is obviated.

As an individual who has developed products that have been through the 510(k) process I believe that while it is essentially minimizing the pain on the part of the manufacturer, it does not necessarily support the best interest of the patient. So, I sit on both sides of this issue. The key to substantial equivalence is not just that the product you are attempting to bring forward for sale is similar to an already-existing and marketed product, but that it does not introduce new errors or hazards beyond those of the competitor’s that would mandate significant testing to demonstrate their amelioration or negation. Furthermore, the 510(k) process asks for the submitting manufacturer to provide a summary of its risk analysis demonstrating it has thought of the various vulnerabilities and has adequately mitigated their effects either through design, education, documentation or avoidance through limiting use in the clinical environment.

Just because a Device is Shown to be Substantially Equivalent to Another does not Make it Safe

The report on CMIO.net explains:

However, allowing a product to enter the market based on the equivalency of a previouslycleared device is problematic, according to the authors, because it doesn’t ensure safety and effectiveness.

“Today, we have a system in which a new moderate-risk device can enter the market because it is substantially equivalent to another device that may have been cleared for marketing two years ago because its manufacturer showed that it was substantially equivalent to yet another device cleared in 2003, and so on, all the way back to a device that was being marketed when the law was enacted in 1976,” wrote Challoner and Vodra. “But that original device might never have been assessed for safety and effectiveness, nor perhaps would any subsequent ones in the family tree.”

This is the essence of the point: FDA 510(k) clearance does not guarantee safety or performance.

Medical Device Vulnerability Can Lead to Patient Hazards

In regard to the SC Magazine post, this is a key concern in the safety and assessment of medical devices at the point of care. Vulnerabilities that can lead to patient safety hazards, even down the road, well beyond the original horizon of the device, requires creative thinking and the ability to accommodate the effects of new technologies into thinking during the design process and beyond.

Are older devices more prone to medical device vulnerability because they predate modern IT technology?

It is understood that this device is older and when it was originally designed the vulnerabilities were perhaps not understood and, therefore, were not designed around. Yet, given this knowledge today, a new severity-likelihood assessment needs to be performed and mitigation for the revealed vulnerability identified and a corrective action plan created to mitigate the effects of the new vulnerability.

How to mitigate medical device vulnerability in general

Medical device design and development involves adherence to the quality system requirements put forward by the FDA. As part of the design of any medical device it is necessary to assess risk severity and likelihood of occurrence to evaluate whether a particular risk poses an unacceptable hazard to a patient or a clinician or any other user, technician or anyone who comes in contact with the medical device. The term acceptable depends on the situation and specifics of the device and context surrounding the patient. The objective of the assessment is to identify ways to mitigate the risks in terms of their severity, their likelihood, or both.

Medical Device Vulnerability implies the need for proper severity likelihood analysis to evaluate and identify ways to mitigate risk.

The Institute of Medicine (IOM) is recommending the revamping of the FDA’s 510(k) process (here).

As an individual who has brought products through FDA 510(k) approval, I can truthfully say that the process can be onerous. However, it is also focused on good engineering and manufacturing processes. While I agree that the process is not optimum by any stretch and is also not foolproof, I am concerned about what might replace it. The old adage “I
am from the ‘gun-mint’ and I’m here to help” comes to mind.

We need to be careful what we wish for, else we might get it. The onerousness of the 510(k) process could be mitigated by continuing with a focus and assistance on making it less burdensome, educating agents and regulators in understanding of new technologies, and bringing the process into the 21st century in terms of enabling the mindless forms and wrote templates to better conform to aspects of medical devices that are really antiquated (information technology and software focus of devices versus hardware).

In my experience as both a patient and a creator of medical devices, I am a big proponent of patient safety and good engineering and manufacturing practices. Anything that cuts corners in these areas I am opposed to. Anything that can facilitate the job of the manufacturer in achieving a more streamlined filing and assisting in the general process of filing I am for. Anything that can assist the manufacturer in achieving a better, safer product, I am for.

Number 6 Zaleski US Patent: US 7,945,457

While trolling the USPTO site this evening I found out that I was just awarded my 6th US Patent. This patent is titled: “Distributed system for monitoring patient video, audio and medical parameter data.”

Zaleski US Patent Abstract:

Zaleski US Patent accessed via USPTO Web Page for US 7,945,457:

The main web site provides the capability to download the images of the actual patent. However, the quick search tool may be used to locate, for those interested. Here is a screen image of the patent:

Significance of this US patent award:

In this US Patent, I discuss the use of video imagery combined with medical device parameter data to provide a more holistic picture of patient care. The significance of this offering and its key differentiator from competition already on market is in the use of an enterprise network for web-based display of imagery through the Internet.

Please view my web site on PhD Dissertation to see benefits of medical device data for patient care and clinical decision making.

A component for remote viewing and monitoring of mechanical ventilator data

Original Mechanical Ventilator Paper here.

Conference Poster on Mechanical Ventilator Controller:

Abstract

Many medical device manufacturers provide methods for collecting and analyzing data from their devices. While some of these methods are sophisticated, others can be as simple as requiring standard serial interface connectivity. However, in addition to physical device connectivity, there oftentimes exists a proprietary syntax or language that, in this age of standards, minimizes the likelihood of deploying the communication methods from one manufacturer to devices of another manufacturer. Unlike the Health Level-7 standards, these basic machine interfaces are presently unique to each manufacturer, requiring that communication methods be tailored in relation to the type of devices deployed, and requiring further development, testing, training, and troubleshooting. This paper describes a remedy for this issue in relation to mechanical ventilators. A method is described which employs a user-defined command table that enables a user to deploy the same application infrastructure to other proprietary devices. This infrastructure is built for mechanical ventilators, but can be expanded to accommodate other medical devices. It is referred to as the Remote Mechanical Ventilation Manager, or RMVM.

Introduction

The Remote Mechanical Ventilation Manager (RMVM) enables remote monitoring of mechanical ventilators, bringing patient data from the ventilator directly to the clinician. The prototype system has been operated with Siemens Servoⁱ ventilators, but can support the syntax of the Puritan-Bennett 7200 AE mechanical ventilator. For syntax specific to both of these ventilator types, the interested reader is referred to [1] and [2]. The RMVM comprises a user interface (UI) and connectivity between Ethernet-based local area networks (LANs) and serial ports of these point-of-care mechanical ventilators so that (1) data can be extracted from the mechanical ventilator; (2) extracted data can be filtered and processed so that telemetry from the mechanical ventilator can be distributed to a hospital or enterprise-based clinical information system; and (3) authenticated clinicians and other users can remotely view telemetry results using a Web-based user interface (UI).

Clinical Informatics in intensive care.

Clinical informatics relies on use of real-time data presented in various ways and using various analytics to assist the clinician in assessing status and trajectory of the patient.

A great deal of time on patient care in intensive care units is devoted to management of pulmonary and cardiovascular systems. This is illustrated along with key parameters or measurands in the following slide image:

Pulmonary & Cardiovascular Systems

Medical Device Data Assist in Patient Care Management.

A key objective in managing patients post operatively is maintaining their oxygenation, as shown in the following slide image:

SaO2 versus O2 Partial Pressure Showing Optimal Range.

Laboratory data are necessary to ensure proper blood chemistry, and also provide verification of patient viability to wean. An example of the results of three blood draws is illustrated in the following slide image:

Results of laboratory analysis of three blood draws on a post operative coronary bypass patient.

Pulmonary measurements, such as tidal volume, are among many that can be taken from the mechanical ventilator through serial connectivity and provide a means of monitoring in real-time the respiratory performance of the patient over time. This is illustrated in the following slide image:

Tidal volume and other respiratory function measures assist in identifying patient state and function over time.

Data from Medical Devices Achieved through Connectivity Enable Collection of Clinically Relevant Data.

By collecting and overlaying all such data, measured and acquired in real time from the equipment at the bedside, it is possible to establish a contextual picture for patient state. This is a key aspect of live, bedside clinical decision making. An example of such data are illustrated in the following slide image:

Various measures such as inspired O2 fraction, respiratory rate, tidal volume, and minute ventilation form the basis for establishing pulmonary state. When taken in context with other parameters, these help the clinician with bedside decision making in terms of care management and trajectory.