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.

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.

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.

My recent participation in an NSF Grant review at PENN on Tuesday and, in particular, Dr. C. William Hanson’s overview briefing during that event, brought to mind some things that he and I had worked on back in the early to mid 1990s. During the course of the presentations, which I found to be very fine and informative, it had occurred to me that basic research is still being conducted in areas that remain relatively untouched or unresolved today, some 16 years later. At the tail end of my dissertation it had been requested by my committee (Dr. Hanson in particular) to lay out key areas of future research that could stand upon what we had done and, in particular, focus on the problem of automation.

Extracts from that long-ago written conclusion read as follows:

“Develop… a larger database of spontaneous minute volume data to verify that it is possible to achieve a more accurate interpolation methodology…”

“Develop…a database of respiratory state data that can be easily recalled for real-time diagnosis and analysis by the critical care staff…by providing an easy way to download this information for…processing would permit the storage of each patient’s data, along with information on patient condition, to be used to classify each patient according to surgery.”

“[A]utomate the weaning process…motivated in part by the need to safely reduce costs and instill more uniformity in the respiratory weaning process across a larger patient population. Moreover, one desirable quality of such an automated methodology is that is would not require the input of such information as patient mass, gender, …anesthetic dosages…to operate effectively. The control system responsible for regulating patient respiratory support should use only that information available through the ventilator…Evidence and trends in patient care exist to suggest that automating post-operative weaning in patients who are not problematic is not only possible, but inevitable as hospitals strive to streamline and reduce the costs associated with critical care medicine.”

The conclusion then goes into the specific algorithm for reducing the support automatically. Undoubtedly, another research focus altogether. Nonetheless, this was written in 1996. Evidence-based medicine is a key objective in the application of treatment today. Furthermore, the databases that were referred to in the research do not (yet) exist today. There are clinical information systems, electronic health records (EHRs) and electronic medical records (EMRs), and varying levels of discrete data that comprise them. But, the level of data richness described in that conclusion still does not exist today.

The one key reason I focused so heavily in my career on medical device connectivity has been because of the inability to uniformly collect the information at the bedside so necessary to support these types of research (and, ultimately, to support the care models related to automated management). While there certainly exist safety concerns surrounding the automated aspect of any process in healthcare, the objective at that time was to provide more uniformity around the process of weaning. Furthermore, respiratory weaning was merely an exemplar to serve as an expression of the larger application of predictive methodologies based upon data normally collected at the bedside.

In order to improve situational awareness it is necessary to have access to the latest information. Part of that situational awareness relates to the observations collected from the patient. Observations in the high acuity spaces comprise the visual, audible and sensory based set that every clinician is familiar with. These are further augmented by historical information, patient demographic, and the training that each clinician receives. Integrate, fuse, or otherwise combine these data together and the situational awareness increases greatly. It is this situational awareness that was sought to be demonstrated through the research at that time and remains an important focus of future research.

Much has happened in the span of time since I graduated from PENN. The IHE, IEEE standards, and interoperability in general have advanced greatly. The research I had begun in the 90s that related to automation and data integration provides potential graduate and undergraduate students seeking to advance their knowledge through the pursuit of both Ph.D.s and Masters degrees with a great opportunity to advance the areas of automation, automated feedback control, and modeling far beyond its current state. While much has been done in the field since I was a student–almost 20 years ago–much remains and I believe the field is on the verge of really taking off, given the advances in interoperability that have occurred to date and the energy and focus on integration of data from various disparate sources within the healthcare domain.

Note: Links to external sites are not to be taken as an endorsement by the author.

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.

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.

 FDA holds Workshop on Mobile Apps

On September 12-13 of this year the FDA held a Workshop on Mobile Medical Applications–Draft Guidance. The link to this site is provided here. The FDA is seeking comment on how they should approach medical applications that are accessories to medical devices and, in addition, standalone software that supports or provides for functions related to clinical decision making–that is, Clinical Decision Support.

FDA Deadline on Comment Submission: October 19th, 2011

The FDA has provided a link to submit electronic comment on the draft guidance at this location. Alternately, written comments may be submitted to:

Division of Dockets Management (HFA-305),

Food and Drug Administration

5630 Fishers Lane, Rm. 1061

Rockville, MD 20852

Identify comments with the docket number: FDA-2011-D-0530

FDA Public Workshop: Day 2, Session 3

Presentations during this session focused on the following:

1) Definition of standalone CDS software

2) What are the different types of CDS software?

3) What levels of support do these CDS software provide?

The speakers included Dr. Kristen Meier of the FDA; Dr. Jonathan White, of AHRQ; Dr. Stan Pestotnik, TheraDoc Clinical IT; Dr. Richard Katz, GWU; Dr. Meghan Dierks, Beth Israel Deaconess Medical Center; and Meryl Bloomrosen, AMIA. Hyperlinks are included with the presenter names to their respective presentations.

Dr. Kristen Meier’s presented on “Standalone Clinical Decision Support.”

FDA Panel 5 – Categorizing standalone clinical decision support software

This panel focused on the factors used to determine risk classification of difference types of software that manage or provide for clinical decision support, and what ways to approach assessing safety and effectiveness determination of same.

FDA Panel: Some Takeaways

Dr. Meghan Dierks included some interesting and provocative points on a definition of “What is Clinical Decision Support?” The author stated that CDS…

“…has the potential to influence any or all of the typical decisions that I make when caring for a patient…”

and,

“Any tool that can influence my ability to: (a) detect current state; (b) detect change; (c) predict future states; (d) identify and present goals and objectives; (e) identify and present options available.”

Furthermore, the following I found to be key to my personal understanding and belief of CDS influences:

“Any tool that can influence my ability to: (a) identify, present optimal choice among several criteria; (b) assess information adequacy/quality; (c) search for additional information; (d) check for bias; (e) structure the approach–intervention.”

Basically, this is interventional guidance.

CDS Risks…

Dr. Dierks continues: What are the key risks if the CDS fails? Well, is the failure visible to the clinician–can the clinician detect the failure and in sufficient time to override or intervene on behalf of the patient before it is too late? Are there cues or insights or strategies available to the clinician in the absence of the CDS system or methodology? From here, the question as to severity of harm and likelihood of harm–all aspects typically assessed as part of hazard and risk analysis per the FDA Quality System–apply.

Zaleski’s Perspective…

I am encouraged by this level of discussion–it engages the clinicians as part of the process that I believe for far too long has been absent in the area of healthcare IT. It is time for the electronic medical record (EMR) “community” to evolve more into the role of evaluating tools that will truly bring forward Meaningful Care (not necessarily the same as Meaningful Use). This means enabling, facilitating, and removing impeding barriers from the clinician in the process of assessing and caring for the patient. The IT infrastructure that has garnered much of the focus on healthcare IT in terms of charting over the past several years now needs to evolve forward into effective use of the information IN A WAY that helps the clinician. This statement has many implications, from optimal display of data; reduction in “screen flips” to truly enabling that which is most important to the physician end-user. This is achieved not simply by providing better “mouse traps” in the form of sophistication. It means providing data in a straightforward manner; presenting options and analyses close at hand and in a way easy to access so that options may be assessed. The technology should NEVER get in the way of the physician. I believe we (the community as a whole) has a long way to go in this regard.

Some time ago I had referred to the fact that I was going to be writing much more on the topic of clinical informatics and clinical decision support. I have posts here, here and here that refer to this dialog. I plan to write much more.

Other related links on this site:

Dissertation on weaning from post-operative mechanical ventilation

FDA regulatory framework for 510(k) clearance

Informatics and connectivity

Thanks for visiting http://www.Medicinfotech.com

FDA Regulatory Flowcharts, FDA 510(k) clearance

When I was at Siemens, I worked with The Emergo Group to bring my first medical device through the FDA 510(k) clearance. They have a great site where they have regulatory process flowcharts based on country. This is really a great resource!

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.