John R. Zaleski, PhD, CPHIMS

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.”

The IEEE published the following paper by Monatesti et al. on the evolving healthcare landscape, especially in terms of quality management, healthcare IT, and a realization that improving healthcare is a responsibility that we all share.

IBM’s Watson is a great computing resource and has been shown to be able to compete in many of the ways that higher learning demonstrates, from participation in the Jeopardy game show to the potential of dissecting the human genome. But, if none of the required data are available to solve the most complex of problems, then all the computing power in the world will not help.

In order to effect the use of data to solve a problem, data must be available and easily accessible. This may seem to be a trivial tautology. However, if no means exists to extract data from systems that are disparate, federated and under different ownership then the full majesty of the computing power will never be realized. The use of disparate sources is almost universally understood yet it remains a key challenge to effective use of data.

It is certainly possible to create or assemble data from disparate sources. Much of the work involved can be laborious: translations of terms, physical access to remote sources, normalizing and aligning methods may need to be developed, etc., etc., etc. The list goes on. Only when a collected source of information exists in a manner that can be readily interpreted by the applications to which these data are fed will the maximal benefit be realized in mining for information. That said, I am also not a blind proponent of data mining to glean intelligence from data.

Interoperability must precede processing power, in my opinion. In modern times (circa 2012) the ability to draw inferences from whatever data are collected is partially there. The fact is that the electronic medical record has evolved to more than just a warehouse of collected information, better than the state of affairs 10 or 20 years ago. Yet, because users must interact with data and information from multiple sources within the universe of the healthcare enterprise (hospital or hospitals in a multi-entity environment), to include notes and orders, it is necessary to carry the context of the information together with its temporal alignment (when things happen). Fragmentation of information, lapses in data, misalignment of events, all can lead to incomplete context. This pervades even the best of systems.

To this point, there is an interesting article on KevinMD this morning that identifies several ways for patients to minimize the fragmentation in care. This article describes how patients can assist their care providers by acting as the “ether” in providing information longitudinally across many care providers to help assemble a much more complete picture of their overall “story.”

The term “story” best represents the situation: each of us has a story (I’ve shared various of mine through this blog). While the challenge weighs upon the provider to extract pertinent facts from the overall temporal collection, judging what is of value and what is not should only occur after review of these facts, not before. To assemble a full story on a patient can involve communication of information from multiple sources, just as in the article described above: many sources made “interoperable” by action and labor of the patient in order to assemble a full (or more complete) picture on the patient. Without this picture, number crunching on the subset may be meaningless or, worse, result in erroneous conclusions.

• Small opportunities to use mobile technology in medicine // http://t.co/KTIbK6GC #
• Feds should integrate primary care and public health, IOM report says | Healthcare IT News http://t.co/noCj56ro #
• Hospital execs intrigued by mobile virtualization – FierceMobileHealthcare: http://t.co/PKY5mOjD via @AddThis #
• Drug Alerts in EHRs Contribute to Alarm Fatigue, Study Finds – http://t.co/F8AmVzza #
• More Clinicians Using Social Media Tools To Find Job Opportunities – http://t.co/5ctRf7hc #
• Data are the new soil? http://t.co/CVDI9b7N #
• VA, DoD to make imminent open 3M Health Data Dictionary part of iEHR | Government Health IT http://t.co/7skj3DMY #
• Comments for the meaningful use commenters: Specificity matters | Government Health IT http://t.co/EoM3FKLb #
• ONC to stand up NwHIN Exchange in October | Government Health IT http://t.co/wu3R8uUp #
• ONC to stand up NwHIN Exchange in October | Government Health IT http://t.co/6zeorP3G #
• Reducing training will diminish the status of physicians // http://t.co/3EU459g6 #
• Are Federal Training Programs Meeting the Growing Need for a New Health IT Workforce? – http://t.co/pvYLranW #
• How doctors should adopt new technology http://t.co/E1fKDk8s via @kevinmd #
• The obviousness of long waiting times in the emergency department http://t.co/L0GveACw via @kevinmd #
• Hackers hitting Macs with virus: industry experts – Yahoo! News Canada http://t.co/KYsEtTnd #
• An interesting collection articles on respiratory therapy, sepsis, and NwHIN business intelligence http://t.co/gmOTeA2K #
• 7 types of security features for your tablet | Healthcare IT News http://t.co/QV6GF7BH #
• The threat of technology to proper patient care // http://t.co/B9Ecx7vM #
• Telemedicine Dilemma: Savings Or Healing Hands More Important? — @InformationWeek http://t.co/9KUgNgJU #

Powered by Twitter Tools

I work at staying on top of the healthcare IT market and also what is going on in healthcare and medical research. Every so often I come upon some medical and healthcare articles that catch my eye and these I thought I would share.

1. “Management of critically ill patients receiving noninvasive and invasive mechanical ventilation in the emergency department.”  Written by Louise Rose on the nursing faculty of the University of Toronto, this is a primer for those clinicians in the emergency department (ED) who are not normally familiar with aspects of mechanical ventilation normally familiar with those of their colleagues in intensive care units (ICUs). I highly recommend as it is not only an informative read, it also condenses many of the management methods of mechanical ventilation so familiar to respiratory therapists (RTs) in ICUs.

2. “Prediction of severe sepsis using SVM model.” This article by Wang, Wu and Wang discusses a predictive model for sepsis using a Support Vector Machine (SVM) approach. I have discussed sepsis elsewhere on the blog. This model makes use of data collected both through bedside physiologic monitors and laboratory tests to establish the likelihood of onset. There are many models of sepsis out there. This one caught my eye due to the use of the algorithm.

3. “Surviving sepsis campaign guidelines for management of severe sepsis and septic shock.” This article by Dellinger et al., details the “Surviving Sepsis Campaign” guidelines on sepsis management and is a very complete source for diagnosis, therapy and general guidelines for dealing with the ailment.

4. “ONC to stand up NwHIN Exchange in October.” This piece by Tom Sullivan over at Government HealthIT is also one I wrote briefly about recently. This describes an overview of the ONC’s plans for the Nationwide Health Information Network and is a good source for information on that for those who are interested.

Government Health IT is reporting that the ONC plans to stand up the NwHIN Exchange in October. For those not familiar with the acronym, this is the Nationwide Health Information Network. The plan calls for interoperability among a minimum o 4 Federal agencies, to include CMS, DoD, SSA and the VA and will include 21 non-Federal entities. These entities will be able to share patient records for episodes of care. Mariann Yeager, interim executive director of the MwHIN-Exchange, reports that as of “…6 months ago, 500 hospitals were already connected, 30,000 clinical users, 3,000 providers, and patient population covering 65 million people and 1 million shared records.”

This blog entry will be relatively brief and will focus on some interesting web sites that I have found. The first of these is a TED video of David McCandless on data visualization. McCandless coined the title phrase of this blog, in which the inference is that interesting information can be mined from data, and the effective display of data can yield not only important associations and correlations, but can provide immense value when displayed appropriately to the human eye.

The second link I found relates to data visualization approaches and is presented by SmashingMagazine.com. Here, some very provocative renderings of user views and user interfaces are provided that can inspire the developer or “data designer”.

Both of these sites also inspire me based upon the use of large quantities of data to manage patients, both from the perspective of large quantities of data and from the perspective of how to deal with data as if drinking from a fire hose, as is the case with medical device alarms and high-frequency data taken from durable medical devices.

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.

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.

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.

In Donald Norman’s book, “The Invisible Computer”, written back in the late ’90s, he describes the features and functions of “information appliances” — technologies that are tailored towards solving specific problems in everyday lives. A key benefit of information appliances is that they are singular in purpose. For example, a garage door opener could be considered to be an information appliance.

One might argue that the fact that such devices exist is obvious and unremarkable in everyday use. However, the argument made around having such devices singular-of-purpose is just that: they are easy to use, require very little “training,” have few failure modes and are self-intuitive.

We turn now to healthcare and the concept of an information appliance in this field. When Norman wrote his book back in the late ’90s there were no iPhones, no Androids, no iPods (at least those we are familiar with today), and certainly no iPads. Yet, a theme that is often used in describing the ultimately usable device(s) for physicians and nurses, we hear that usability is chief among them. In last week’s Healthcare IT Newsweek piece “12 Integration Capabilities EHRs will need to have” we learn of features and functions that need to be deployed to support single sign on, integration of patient context and awareness, publishing functions to consuming widgets. But, these are all quoted with respect to the assumed rendering device: the personal computer. The personal computer is a generalist’s appliance, not a specialist’s. It is designed to be used for multiple purposes. Hence, when applied toward the specialization of any one problem, it does so only with clunkiness. We are all undoubtedly familiar with problems in upgrading computers; in applying patches; in the intricacies of software installation and configuration. These “generalist appliances” can oftentimes get in the way of the specialist’s purpose because we (all of us) oftentimes spend our time simply figuring out how to use the appliance rather than using the appliance to solve a particular problem for us.

As I was reading Donald Norman’s book, I was thinking about what could be considered to be today’s “information appliances” and how they could be applied to healthcare. My iPhone or iPad immediately came to mind. Albeit, generalist-devices, they have downloadable applications that can make them specialist devices for particular purposes. Then I thought about whether they were really applicable to the healthcare environment: from a clinical perspective, if used by a physician in his or her office or at home that might be the case. But, if use were to be considered at the bedside, there are other issues to deal with: cleaning, dropping, ability to use with a gloved hand, etc. Could the iPhone truly be considered a clinical information appliance at the bedside? I’m not sure it could.

In the 14 or so years since the publication of Norman’s book, much has evolved in terms of technology. Furthermore, the acceptance of technology for clinical practice has certainly evolved enormously. Yet, what has seemingly evolved in a limited way is the usability of technology for clinical practice. Physicians and nurses are all-too-often required to learn to work with, through, or around the quirks of information technology and their requisite appliances rather than having technology that will work with, for and conform to the requirements of the clinical user. This has caused me to think about where is the true clinical information appliance? I do not think it (yet) truly exists.

I am an Informatician. There are several definitions of this that are, generally, supportive of one another. Albeit, the definition of biomedical informatics is rather unique, as can be seen below.

For example, Wikipedia defines Informatics (not biomedical informatics) as follows:

…the science of information, the practice of information processing, and the engineering of information systems. Informatics studies the structure, algorithms, behavior, and interactions of natural and artificial systems that store, process, access and communicate information. It also develops its own conceptual and theoretical foundations and utilizes foundations developed in other fields.

The general study of algorithms, structure, behavior and interactions of natural and artificial systems that store, process, access and communication information are all aspects of biomedical informatics, too.

The Free Dictionary provides the following definitions:

…computerized automated delivery and manipulation of information to and by users of computer systems.

…the management of information and knowledge by computers.

…information management; the technology of information storage, retrieval and transmission. Includes on-line access to and editing of data bases, facsimile transmission, optical reading and word processing.

The American Medical Informatics Association has developed a formal definition of Biomedical Informatics:

…Biomedical informatics (BMI) is the interdisciplinary field that studies and pursues the effective uses of biomedical data, information, and knowledge for scientific inquiry, problem solving and decision making, motivated by efforts to improve human health.

The list goes on, but I think the point is made: the use of biomedical data for knowledge and scientific inquiry, problem solving and decision making. These are definitely aspects and attributes of the definition that apply to me and my background.

I am a member of AMIA, a member of HIMSS (Health Information Management Systems Society), and other organizations that aim to use health information to foster improved care at the bedside. However, when I started my involvement in this whole arena or field of study I knew of neither and some of the societies that are now in full swing were not even born (IHE, for instance).

My involvement in healthcare informatics began in 1990, and the decision to migrate into this field formally occurred after rather a personal tragedy: my mother’s diagnosis with, and ultimate death from, breast cancer. We all have our stories and reasons why we do things in life. This was one that changed my complete direction. I had been working in the aerospace industry for a major defense contractor (later acquired by yet another defense contractor) and had no intention of changing my field. However, mom’s rather sudden diagnosis with a very virulent form of breast cancer combined with the utter helplessness I felt during her illness and the lack of answers I could obtain from her oncologist, caused me to begin to ask the questions about how such seeming inability to assess and forecast was not a major news story. Furthermore, the inability to locate and access data was, to me, unbelievable. After all, weren’t we dealing with people’s lives here? I compared the relative “order” in my field of aerospace engineering–the existence of standards; the ability to link and integrate disparate systems; the ability to collect data and access multiple sources of information, even sources developed by competing contractors, and could not understand why medicine or healthcare in general was “allowed” to continue this way!

Of course, I was naive. I  understood that there were major challenges in medicine that remained and still remain unsolved (cancer being one of them). Yet, I was coming at this “problem” from the perspective of an engineer’s brain: diagnose the problem, seek the data, formulate a solution approach, execute the solution.

What I saw in this case (so close to me as it was) was the ability to diagnose the problem, collect some of the causal data, but the processes of formulating an effective solution and executing on that solution were completely beyond the capabilities of everyone involved. At the time, at least, there was “guessing”; there were pockets or sources of incomplete data; not all information could be collected and made available to any given clinical end user, etc. Now, to be fair, had my mother been diagnosed in this day & age I believe she may still be around–some very fundamental advances have been made in the field that would have given her more of a fighting chance. However, back then the key approach was “poisoning” the system (note: I had read Dr. Susan Love’s book on breast cancer at that time). Furthermore, the tools at hand for her oncological team were stored in “silos.” There was not much sharing of information outside of the major medical journals. In addition, the oncological team’s ability to seek independent studies or new research to be able to evaluate or even model or statistically assess the effectiveness of experimental treatments was almost impossible to do.

However, the experience placed a focus like a laser beam in my consciousness in terms of providing the tools and access to data to improve the care and prospects of the patient that has not diminished in me since that time. In the aerospace field, collecting information from multiple sources in order to seek better overall knowledge of the “target” was and is done regularly. Often called “multi sensor data fusion”, I carry this term forward from my former field to comparable use in medicine and healthcare as a metaphor for describing the process of collecting data that may paint a picture of “different sides of the elephant” in order to assemble a more complete view of what is actually happening–in other words, to improve situational awareness around the patient. This aspect of informatics is one that, for me, also motivated the need for better and more complete data (medical device connectivity being one source for this type of information).

During my days in research at PENN, collecting data from multiple sources was key to establishing the situational awareness and conditions around the predictive models I had developed for assessing likelihood to wean from post-operative mechanical ventilation. To accomplish this, rich and complete source data from laboratory to medical device information as well as patient demographics and history were necessary. The conditions that establish the usability of the data, its importance and applicability to the environment are, in a microcosm, what was missing from my mother’s experience and that of her oncological team. The ability to source data–even experimental data–from multiple sources and to have the ability to combine and integrate it effectively for the use in “what-if” analysis was completely missing. However, again, going back to the aerospace engineering analogy, this is frequently done as a method for validating design or determining the best approach or possible effects for dealing with unknown situations.

In summary, medicine is much more complex than “rocket science,” but only because of the unknowns. The field of informatics seeks to place the best possible information in the hands of those who are operating on the front lines of battle–the physicians, principally–who are charged with guiding the treatment. If, in this process, I can assist or make a difference to win the battle for the patient, my life will have been well lived.

Stage 2 MU announcement was made at HIMSS 2012 last week in Las Vegas. Healthcare IT News has a write-up:

The rule proposes to delay implementation of higher standards in Stage 2 of the $27 billion meaningful use program by one year for eligible hospitals and physicians who adopted EHRs in 2011. These new standards incrementally increase requirements and add new functions health providers must meet to qualify for taxpayer incentives in Medicare and Medicaid.

“Unfortunately, under the HHS rule, we will lose a year of interoperability,” White said. “Stage 1 required a test of clinical information exchange. HHS has proposed eliminating the test in 2012 and 2013. So there isn’t even a test for that previously required function.”

“In 2014, HHS suggests adopting minimal standards for information exchange related to a patient who transfers from a hospital to a nursing home, or who is referred by an internist to a cardiologist,” White added. “We have to wait two years for that? This is simply not acceptable.”

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.

Kent Bottles’ piece “break out of the prison of the American health care delivery system” nails it: just as the 19th century focused on the new idea of identifying pathology of disease, the 21st century needs to be the one that evolves beyond screening for ailments that are already there, to the point  of (in Dr. Susan Love’s words) finding of root cause.

According to Lucy Mckeon in her article “The coming medical revolution“, that’s how much medical data are produced yearly. In this article she interviewed Dr. Eric Topol, Chief Academic Officer for Scripps Health.

In this interview, Dr. Topol lists three areas in which data–big data–and the human genome are contributing to the shift toward personalized medicine. I briefly summarize these below and leave to the interested reader the link to the page above:

1) Pharmacogenomics and the ability to assess whether certain patients will respond to certain drugs based upon genotype. The statistics stand at $350B for the amount the US spends annually on prescription drugs. Many drugs do not work on certain individuals (e.g.: Plavix – 1/3 of those taking have no response; Metformin – 1/4 of diabetics unresponsive). The effects of underlying genetics could be better understood with a genotype of individuals, thereby resulting in better targeting of drugs based on individual. Genotyping is a major big data producer.

2) Cancer therapy and tumor genomics in comparison to the germline DNA of the individual. Comparative analysis can lead to better, more directed therapies. Certain cancer treatments, when directed based on the underlying genotype, can lead to better outcomes. Cancer therapy is a major big data consumer.

3) Reduction in what Topol terms the idiopathic relative to “guessing” at therapies that would / could / should be revealed by the underlying genome that would establish biological basis for disease.

Is social media the new way of life? Are we to avoid it as a fad or simply agree to “become one with the Borg?” Is social media a means for improving the communication between we as the patient and we as the physician? There are many reasons to use social media, and many reasons to avoid it…especially if you are a professional. Once something appears on the Web it is effectively there forever (I know…)

I have been maintaining this blog for about 4 years now and have over 120 posts on various topics related to clinical decision making, medical devices, and data as well as links to my books, etc. I maintain this primarily for myself… as a professional diary and as a social tool for professional interaction. By and large this goal has been and is being achieved. Yet, I read something interesting on the use of Google+, with special emphasis on a use case for physicians, primarily, that provides a vehicle for interaction among themselves, possibly with their patients, and as a safe haven that is not quite as revealing as Facebook and not as “minimalist” but yet as open as Twitter.

In the world of medicine, especially in the relationship between physician and patient, it is extremely important to maintain privacy and control of the conversation. One of the key challenges in the health information technology age is ensuring that patient information and the communication between physician and patient remain private with control in the hands of the participants. I emphasize that security and control are key. The next generation of social media may involve more of the security and less of the social. This aspect of communication, once trustworthiness is assured, may represent or reflect the maturing of the technologies that heretofore have been seen as the wild west.

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.

So, I was reading Information Week Healthcare and there is a great piece titled “Healthcare IT Needs More Crazy CIOs“. In this article Paul Cerrato talks about MD Anderson Cancer Center’s CIO Lynn Vogel. It turns out that they developed their own EMR, and for many of the reasons I have been discussing with my physician colleagues. One reason stood out bang on the dot:

Most commercial vendors are focused on either routine hospital or physician care, Vogel says, and don’t incorporate the latest clinical research data into patients’ records.

CIO Vogel continues:

In cancer care, that routine just doesn’t work, Vogel says. “It used to be a university would do the research. Five, six, seven or eight years later, it would show up in some clinical practice,” he says. “We want to shorten that. When people have cancer, they don’t want to wait four or five years.” They want to learn about new research right away, so they can enroll in clinical trials. “That’s what drove us,” Vogel says about the center’s work to incorporate research into clinical processes faster.

MD Anderson plans on sequencing all of its patients within the coming years and the vast amount of data requires innovative ways to extract and manipulate it. While this is not outside the realm of existing technology, it may be beyond the capabilities of most EMR systems to provide along with the required flexibility for research.

Glad to see the innovative spark alive and well at a major healthcare provider, and in the person of their CIO!

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.