On February 22, 2012 the Centers for Medicare and Medicaid Services (CMS) released (in a mere 455 pages in manuscript form) a proposed rule for Stage 2 criteria for qualification of an EHR for the Medicare incentive program. Among many topics, the proposed rule includes some elaboration on the mandatory use of CDS’s as well as issues related to their design and utilization.

This mandate might be viewed in the context of AHRQ’s statement (here) that “Despite thoughtful efforts over the last three decades to translate clinical guidelines into CDS rules, there has not been widespread and successful use of such rules to improve patient care.” Of course limited success to date does not mean that CDS cannot be beneficial in the future. In addition there is a wide range of sophistication in systems that might be called CDS, and which would in part satisfy the MU requirements.

In general the CDS Stage 2 objective is to “Use clinical decision support to improve performance on high-priority health conditions.”  The associated Stage 2 measure as proposed is to, “Implement 5 clinical decision support interventions related to 5 or more clinical quality measures at a relevant point in patient care”, including enabling and implementing drug-drug and drug-allergy interaction checks.  The drug related functionality is intended to provide  information to “advise the provider’s decisions” in prescribing drugs to a patient.

The “advise” component of CDS is a challenging issue since the quality of the advice is a critical element in any CDS system. It is here that the degree to which the provider can and should rely on that advice becomes an important  part of how CDS should be used, and equally how it will actually be used. In this regard it is common for advice systems to have a variety of disclaimers and associated assertions that the professional must in effect second guess the advice given and make their own judgement.

While logical, the value of a CDS that you can’t rely on is at least questionable, as is whether users will always mentally challenge the results. In this regard there are at least three ways in which CDS’s can go astray. One is when the underlying information upon which the advice is based is not strong. A second is that although the underlying data is strong the software is defective. Third, a patient’s individual condition may fall outside of the boundaries for which the information is reasonably correct even though the software is a reliable representation of that data. Moreover, the boundaries of the accuracy domain are often ill defined or not defined at all.

The Stage 2 proposed rule takes an interesting pass at these issues by requiring that each clinical decision support intervention must enable the provider to review all of the following attributes of the intervention:

• Developer of the intervention,
• Bibliographic citation,
• Funding source of the intervention, and
• Release/revision date of the intervention.

Thus instead of just a result (or ranked results perhaps) popping up, the user must be provided with the people and data behind the result, and how old that data is. The proposed rule states that “such information may be valuable so that providers can understand whether the clinical evidence that the intervention represents is current, and whether the development of that intervention was sponsored by an organization that may have conflicting business interests including, but not limited to, a pharmaceutical company, pharmacy benefits management company, or device manufacturer.”

This kind of disclosure is good, but it does not fully account for the degree of validation of the actual results that are generated. It is also proposed that the CDS suggested/advised/proposed interventions must be presented through Certified EHR Technology at a time relevant to direct patient care to a licensed healthcare professional. That professional is then expected to ”exercise clinical judgment.” Therefore it is clear that a CDS cannot be fully relied on, nor can it be a substitute for an appropriate healthcare professional.

The “presented through” requirement suggests that the CDS must be well integrated with the EHR, although this is short of requiring that the CDS actually be part of the EHR. This suggests that EHRs would have to have high flexibility to integrate with the required CDS’s, which conceivably come from different vendors, adding to the challenges of–dare I say it–connectivity itself.

Not all CDS systems will need to be particularly sophisticated. One example given in the proposed rule is a CDS that triggers a point-of-care alert from the EHR that prompts a licensed healthcare professional to ask about influenza immunizations when engaged with a patient 50 years old or older. This kind of little reminder is not fraught with the deeper issues of CDS reliability. More generally it is noted that family health history can be used to inform CDS and patient reminders and patient education. Another suggested CDS application is generic drug and insurance formulary information.

Those who believe that activity should not be confused with results will not find comfort in the observation that for Stage 2 CMS does “not propose to require the provider to demonstrate actual improvement in performance on clinical quality measures” through using a CDS, although improvement should be the provider’s goal.

This proposed rule has a 60 day comment period after which CMS will cogitate on the comments received and publish a final rule with any revisions deemed appropriate. Effected professionals and hospitals will have to watch for this final rule.

Unrelated to MU and CMS, but an interesting example of the intended use of CDS is the approval by the FDA of a software driven mammography pattern recognition system that analyzes the mammography images and marks suspicious areas consistent with breast cancer for review by a radiologist. Of particular interest to me is that the approved method of use is that the radiologist first reads each image in the conventional manner, and then re-examines each region marked by the software analysis before making a decision about the image.  The instructions for use, also posted by the FDA, include important warnings in this regard including that the marked images do not have the level of detail of the original mammogram and that their only purpose is to provide a reference for the location of the auto-generated marks. Further it is stated that the algorithm will not mark all regions that contain cancer and will mark regions that do not contain cancer. As a result the presence of a mark only indicates that a radiologist should review the marked region again to avoid a potential oversight, and the absence of a mark should not dissuade a radiologist from investigating their own suspicious findings.

 Thus the intended use clearly states that the automated read is not sufficiently reliable to be used as a primary analysis, or perhaps that the manufacturer doesn’t want to take on the responsibility of primary analysis, or that the FDA would not accept a claim of primary analysis. It is also possible that radiologists are able to protect their image reading turf by discouraging reliance on automated systems. In any case, the result is a CDS system that is not primary, and cannot be totally relied on.

The next questions then are how will it actually be used, and to the degree that it may be relied on, how good is it? An associated question of interest is whether radiologists would chose to not follow-up on a flagged region that they didn’t think was suspicious, or would they always pursue the next steps which may include biopsy. Since those next steps involve the potential for both physical and psychological adverse outcomes, pursuing that which doesn’t need to be pursued is not without consequence.

The experiences of radiologists using the system would also be of interest. Even doing what the instructions say, the radiologist may find that the system only finds what they have already found, and/or doesn’t find what they have already found, and/or finds things they didn’t find that are spurious, or really does find important things that they missed. Each possibility and their combination will inform how such systems actually come to be used, or not used.

William Hyman is Professor Emeritus of the Department of Biomedical Engineering at Texas A&M University. He recently retired and has moved to New York City where he continues his professional activities.

Health IT Risks

The potential for health IT to improve both the quality and efficiency of medical care has been much noted to include more complete and timely records, ready exchange of information between providers, clinical decision support, and in turn a reduction in errors associated with the quality and availability of patient information. Efficiencies may arise from electronic capture of data which would eliminate manual entry, and time savings in accessing and reviewing patient information, and perhaps in passing information to third party payers. Additional public health value might accrue from the enhanced searchability of electronic records with respects to trends, treatments and outcomes. These benefits assume well designed, user friendly, compatible systems not withstanding that the U.S. model is to allow for numerous independent products that may or may not be able to exchange information nor display it in a consistent manner. Not surprisingly the report notes that the IT imperative will likely not be fruitful without associated attention to the people and the clinical system they work in.

However there is also the potential for health IT to add to, rather then reduce complexity; misplace, lose or garble patient information, and to provide clinical decision support that is incorrect or unreliable. Thus health IT itself has risks that the IOM found have not yet been adequately addressed or monitored. The IOM also cites the lack of an effective health IT problem reporting system compounded by contractual language that may actually impede such reporting. In addition some vendors include disclaimers as to their responsibilities even for software defects and errors. The latter suggests the all purpose liability disclaimer language: “Notice-this product may be badly designed and therefore not suitable for its intended purpose.” Alternatively one could try: “Due to software defects the information in this EHR may or may not be complete and/or may not pertain to  the patient of interest. Do not use this information for medical treatment”. The value of such disclaimers will no doubt be tested.

Of course it is not only coding defects that can make heath IT less than effective. The well established issue of usability, or user friendliness, lives on, as does interoperability, training and workflow design. In this regard it might be noted that user friendly features such as pull down menus also facilitate quick but erroneous entries. Thus while an IT product might be theoretically capable of being used properly and effectively, whether it will achieve that goal in the real environment of use, when used by real people, is a separate matter. In this regard when faced with use issues and adverse events vendors will want to say that their product could have provided the correct functionality if only it had been used correctly–and don’t forget our disclaimer. The counter argument is that it was badly designed to the degree that “correct” use was predictably not likely to consistently occur. There are many anecdotes in this regard. A favorite of mine was an order entry system to which was added a physical sticky note on the monitor that read “Do not press Enter to Enter”.

Actual health IT hazards are at least in part separate from the questions of privacy, hacking and other mischief.

It must also be remembered that quantitative data (e.g. lab results and other medical device data), or reasonably well standardized data (e.g. images) are potentially much easier to capture, transmit and display than narrative information. The selection and arrangement of information on a display can also be a significant challenge with respect to density, utility and how many pages the clinician has to look at to get all the information needed–and you can’t spread those pages out. There is also a significant issue with the lack of standardization of “look and feel” factors. In this regard it must be remembered that clinicians of various types, working in multiple environments, might see multiple systems during even a single day. This is analogous to the reality of nurse use of infusion pumps. Ask the nurse if they know how to use an infusion pump and they will most likely say yes (and be insulted). But then ask them if they know how to use a particular infusion pump and they might say, no, I’ve never seen one of those before. In this regard a health IT application may be plug-and play, but that isn’t the same as plug-and-effectively-use.

IOM Report Recommendations

The report has several specific recommendations:

• A comprehensive effort to asses safety and risk
• Vendors should support the free exchange of information about health IT experiences and issues and not prohibit sharing of such information, including details (e.g., screenshots) related to patient safety
• HHS should make comparative user experiences publicly available
• A new Health IT Safety Council should be funded by HHS to evaluate criteria for assessing and monitoring the safe use of health IT and its ability to enhance safety
• The registration and listing of products from all vendors
• Specification of the quality and risk management process requirements that health IT vendors must adopt, with a particular focus on human factors, safety culture, and usability
• Establishment of a mechanism for both vendors and users to report health IT related deaths, serious injuries, or unsafe conditions
• Establishment of an independent federal entity for investigating patient safety deaths, serious injuries,or potentially unsafe conditions associated with health IT
• Regular monitoring and reporting of health IT safety by HHS, and the FDA should be charged with developing applicable regulations
• HHS should support usability research

Readers familiar with the FDA regulation of medical devices will recognize many of these items as standard fare. These include registration and listing, quality systems, and problem reporting. However since the FDA has not asserted that EHRs are medical devices, and the IOM elected not to make that specific recommendation.

Record-type health IT products remain in a regulatory vacuum–except with respect to acquisition funding subject to the meaningful use requirements. In this regard the report includes a dissenting statement from Richard Cook, MD (director of the Cognitive Technologies Laboratory at the University of Chicago) who asserts that health IT products should not only be declared to be medical devices, but that they should be Class III, the most stringently regulated device classification. In this regard he includes the following quote: “Medical and diagnostic devices have produced a therapeutic revolution, but in doing so they have also become more complex and less easily understood by those who use them. When well designed, well made, and properly used they support and lengthen life. If poorly designed, poorly made, and improperly used they can threaten and impair it.” While this quote could appear in nearly any one of the posts here, it actually dates to 1976 as part of President Gerald Ford’s signing statement for the Medical Device Amendments that ushered in the modern era of medical device regulation. While these amendments are often thought of as the beginning of  FDA medical device regulation, such regulation actually stems from the 1930′s. What did start in 1976 was before-marketing restraints as opposed to the FDA’s prior post market authority. (And no, 1976 is not ancient history. Some of us actually remember it.)

Health IT is caught in the corn maze of promise vs usability and hazards. With quality design and thoughtful implementation the exit may be found before nightfall. Without it someone is going to have to call 911.

William Hyman is Professor Emeritus of the Department of Biomedical Engineering at Texas A&M University. He recently retired and has moved to New York City where he continues his professional activities.

The Amazon postmortem explanation has to be  what will be a classic, if it is not already a classic. In fact I can picture a pull down menu of explanations where this would have to be one of the choices. The explanation in short: a configuration error was made during a network upgrade. A far more detailed explanation was posted by Amazon here. From a Web page perspective an interesting aspect of the posted explanation is that while it is clearly on the amazon.com Web site, it is not easily found, if it all, by starting at amazon.com, or at least I didn’t find it from there.

One interesting aspect of the story is that different customers were affected in different ways in part because of the type of services they had under contract. For example Netflix said it had taken “full advantage” of the redundant cloud architecture which protects against local malfunctions, while other customers who were reliant on only the effected Virginia location were more adversely effected. Understanding what you are paying for can be a challenge here, especially for less sophisticated users, who in some cases would be exactly the ones turning to cloud providers.

As readers here probably know well, the computer cloud is a way for enterprises to outsource their computer operations in whole or in part including severs, software and data management, substituting Web access for the maintenance of their own servers and support. This concept has grown in popularity in recent years among both large and small organizations. Not surprisingly then, there was a good deal of sentiment expressed about this being a wake-up call that will cause a re-evaluation of reliance on the cloud, and that the reliability image would take a hit. What is perhaps most surprising about these sentiments is that seemingly knowledgeable people were willing to acknowledge that they were surprised that the Amazon system, or any large system, could go out. This is the it-will-always-work-and-always-be-there perspective that vendors love, and customers continue to buy into. (There is a wireless version of this that adds there-will-be-full-coverage-of-unlimited-capacity-and -we-will-not-interfere-with-anyone-and no one-will-interfere-with-us.) It might also be noted that some cloud data storage providers have already closed their doors, and there is no automatic guarantee that customer data will be accessible or easily transferred when cloud providers are gone.

While no medical systems were reported as being effected by the Amazon problem, this is none-the-less yet another example of what can go wrong with distributed information systems, and why preparedness generally, and risk management in particular, are necessary elements of today’s connectivity. ISO 80001, as discussed here by Tim Gee,  is a starting point for healthcare to think about these issues. The global question is what do I do when the network system I am depending on isn’t available? Related to that is which devices have stand alone capability, and which do not? And equally important, where is the data, how secure it is it, how fast can I move it, can I/they recover it, and will the vendor/my data be there tomorrow?

It is true the iPad is magical. Don’t deny that. On the other hand, there seems to be a lot of Apple fan-boy hyperbole surrounding the iPad in health care. Most stories on the iPad in health care focus on what a sexy product it is and how clinicians would love to use it in their practice. But there’s more to gaining market share in health care than a sexy product with usability and customer hopes, wishes and desires.

There are 4 key hurdles any tablet manufacturer must overcome to succeed in health care. First, software developers must redesign the user interface of their applications to run on the smaller screens of tablets (compared to desk top computers). This is no easy task, but at HIMSS last month, it seemed everyone had (or promised have soon) demo software running on the iPad. A great tablet that no one’s ever heard of, from Emano Tec, faded away at least partially due to a lack of applications designed for it’s form factor. And it is not clear that HIT vendors will jump at the chance to re-implement their software on multiple tablets, let alone the iPad.

The next hurdle is that deploying IT infrastructure in hospitals is not a consumer play. Due to HIPAA and other requirements, providers need a device with complete and robust enterprise features. Centralized provisioning and device management, authentication, strong encryption, and top notch wireless performance are required for broad cost effective deployment in health care. This is not currently an iPad strength.

Many caregivers work 12 hour shifts, and all tablet users will need both long battery life (ideally lasting a full shift). Once the battery is depleted, it needs to be recharged — in a commercial grade, ganged charger (i.e., one that charges multiple devices at once). Installing a bunch of power strips on a counter and plugging in wall warts that then attache to individual tablets consume too much space, are a hassle to use and manage, and represent an infection control risk. There may be tablets that meet the battery life requirement, but none offer ganged charging stations.

Finally, tablets used at the point of care require certain physical characteristics. While office based physicians may be able to get by without some of these requirements (like infection control and disinfecting devices used at the point of care), they are a necessity for hospitals. The first requirement is ruggedization and the ability to be dropped repeatedly onto linoleum covered concrete from 1 meter. Second is water resistance, to both patient fluids and when the tablet is wiped down with disinfectants. And tablets must be made out of materials that are not susceptible to the effects of the harsh disinfectants used in health care. A common problem with products used at the point of care and exposed to disinfectants over time is brittleness resulting in cracking and breaking of cases and parts exposed on the outside of devices.

After-market cases are available to overcome some or all the physical limitations of current tablets, especially ruggedization and water resistance. But these cases come at a cost – they increase the size and weight of the device, and may impact the the use of speakers and microphone, visibility of the display and touch screen performance.

Presently none of the tablets on the market meet all the requirements for health care. Most probably don’t meet any of them without a third party case.

So what are today’s tablets really capable of in health care? Sales demos and pilot deployments. [See update below.]

Over time, I expect tablets to evolve much like VoIP handsets. The initial versions of handsets sold into health care were designed for corporate suites. But over time, they became ruggedized, water resistant, and manufacturers changed to materials that could withstand the disinfectants used in health care. I suspect that manufacturers who primarily target commercial markets, rather than the consumer market, will be the first to adopt these industrial-type requirements. I also suspect that there are more tablets to come from other vendors in the enterprise telecom or Unified Communications markets.

If Apple wants the iPad to dominate in health care (and that seems to be an open question at this time), they’ll have to step up, and do it in a timely fashion. It would seem that a platform OS like Android, that runs on multiple manufacturers’ tablets would be a very attractive feature to most HIT vendors. I’m sure the HIT vendors are hoping to port their software to one tablet OS, rather than 2 or 3.

It’s a wide open market, with lots of customer demand – and at this point I wouldn’t count anyone out.

UPDATE: It strikes me that I should say more about the short term prospects of the iPad in health care. Sales demos are an application with significant potential; iPads are sexy and attractive and would likely enhance almost any application’s demo. Pilots are undertaken by early innovator customers. These are the folks who are willing to give up features that are essential to early and late majority buyers – like the shortcomings in the 4 categories above. I suspect that early innovators will enthusiastically embrace iPads. But early innovators does not a successful market make. Using Geoffry Moore’s market development model, the iPad  or any tablet needs a whole product solution (again the 4 categories above) before it can cross the chasm to the majority of the market. A market limited to just the early innovators is likely to be ten percent or less of the total market opportunity.

Here are photos of some of the tablets at HIMSS11 in Orlando.

UPDATE: I missed the Avaya Flare.

[thumbnail photo source: The Economist, via iPhoneIndiaBlog.com]

The following is my first take on the topic, and serves as a description of webinar. Any suggestions, points of view and links to relevant content on the Web (news stories, blog posts, regulations, etc.) is welcome.

Register for this webinar here, to be held on October 27, 2010 from noon to 1pm EST.

The Case for Regulating EMRs

From a quarter century point of view, it seems inevitable that the HIT industry will be regulated by the FDA. Look past all the hand waving and hyperventilating caused by this suggestion, and one sees that the HIT industry is already regulated by the FDA. For examples, look no further than blood bank software and PACS. The Center for Biologics Evaluation and Research (CBER) started regulating blood bank software via the premarket submission process in 1996. From their inception, the FDA considered PACS as accessories to diagnostic imaging modalities, and thus regulated. (Many PACS components have since been reclassified in recognition of their independence from imaging modalities.)

These examples aside, the HIT industry has pretty much avoided FDA scrutiny by claiming they’re just automating administrative tasks and paperwork (i.e., workflow around the paper chart).With the advent of decision support systems tied to CPOE and other applications, “administrative” HIT systems have come to be increasingly recognized as a source of patient safety risk. See Margalit Gur-Arie’s post at the KevinMD blog.Perhaps the story that’s created the most buzz about the danger of EMRs is this Huffington Post piece from April, 2010.

On February 25, 2010, at a HHS panel meeting, Jeff Shuren reported:

The Food & Drug Administration has received 260 reports of health IT-related malfunctions with the potential for patient harm in the past two years, including 44 reported injuries and six reported deaths, said Dr. Jeffrey Shuren, director of FDA’s Center of Devices and Radiological Health.

Vendors, patients, clinicians and facilities voluntarily reported the problems but, because of that, “they may represent only the tip of the iceberg in terms of the HIT-related problems that exist,” he said at a Feb. 25 hearing of the Health IT Policy Committee’s adoption and certification work group, a Health and Human Services Department advisory panel.

Because there is no legal requirement for providers or manufacturers to report patient deaths or injury (or “near misses”) due to EMR and related software, many believe these numbers represent the tip of the iceberg.

All of this has generated a growing call for the FDA regulation of EMRs. As HIT system architect Shahid Shah observed:

Yikes. We see all this focus on “meaningful use” but almost no discussion on safety critical systems and how the government will ensure that software being built is being built right and with high quality. Without stricter regulations like we have on medical devices, I’m afraid we won’t get the safety attention we need to bring to bear.

Regulators at the FDA and manufacturers have been grappling with how best to regulate software since the mid 1990s and before. With the advent of the iPhone, the topic of the potential regulation of smart phones is heard with increasingly frequency.Many of the issues here are related or similar to those revolving around EMR regulation.

The FDA’s been spending some quality time thinking about all this. As evidence, there’s this interesting analysis of HIT adverse events into 4 categories. Of course, the optimal solution to these patient safety issues continues to be debated by HHS and FDA — who both want to claim the mantle of “EMR regulator.”

Impact on Manufacturers

Three words: Quality, System, Regulation. In some cases, software buyers don’t want to know how the sausage gets made. It is common practice for HIT vendors to:

1. Write software without documented and complete requirements
2. Have little or no traceability between requirements and testing
3. Provide little or no post market surveillance of installed products

That’s not to say that all HIT vendors, or all EMRs represent egregious examples of these product quality shortcomings — they don’t. But vendors will likely have to implement some sort of basic quality system to improve software quality. Meaningful post market surveillance is a no-brainer. And should regulators be more aggressive, there could be requirements for human factors engineering to optimize usability.

All of these changes will impact how products are delivered and costs. There will be no more quick and inexpensive product customization to win a sale. And the time between product releases will increase in an effort to wring as many latent software defects out of the code as possible. A mechanism for product recalls is also likely. And all of these potential changes will somehow roll downhill on to providers.

Impact on Providers

The safety and effectiveness of an EMR extends beyond writing code or even the initial implementation and configuration, as implied by this quote from the Huff Post piece:

Justin Starren, a physician who oversees technology at the Marshfield Clinic in Wisconsin, lays out the dilemma starkly: “Computers are strong medicine. Done well, they are wonderful; done poorly they can kill people,” he said.

How an EMR is used, managed and supported by the customer has a significant impact on patient safety. This will impact both costs and operations (which again, impacts costs). Here’s my summary list of provider impacts:

1. Higher purchase price from HIT vendors (but probably not a lot, due to competition).
2. Much higher operating costs, though providers should be able to leverage some IEC 80001 investments.
3. Providers will be challenged when it comes to modifying purchased EMRs if they are a regulated medical device.
4. Risk management will need to be beefed up considerably – better governance, better documentation, deeper more substantial risk management focus.
5. Change control will also need to be brought up a few notches in many organizations, and expect to be driven by product recalls and other post market surveillance results.
6. Interoperability and connectivity between 1) similar systems in other provider organizations, 2) between information systems in the enterprise, and 3) between EMRs and medical device systems all add complexity and risk to broader HIT systems.
7. Test, test, test! The system of systems (#6 above) installed in any one location is unique and has never been tested by any one manufacturer – just manufacturers testing their own bits and pieces.
8. The slow trickle of IT people currently leaving hospitals for banks, big box retailers and other IT-intensive and low-risk employers will grow considerably.

All this begs the question of what providers (and HIT vendors) should do in anticipation of the inevitable? These are substantive changes impacting strategic plans, purchase plans and daily operations. I’ll be recommending best practices for providers in the webinar.

Let me leave you with another question: When EMRs are regulated medical devices, does that mean that IT will report to Biomed?

There will be much more in the webinar on October 27, 2010. Hope to see you then!

UPDATE: Here’s the link to the webinar on Santa Rosa Consulting’s site. This topic has proven of such interest that I’ve written a more in-depth story for Patient Safety & Quality Healthcare magazine. I’ll post a link when it goes up some time in February.

UPDATE: Here’s the link to the story I wrote for PSQH magazine on FDA regulation of EMRs, titled The Case For Regulating EMRs.

In the context of these projects CDS means the provision of clinical knowledge and patient-specific information to help make decisions that enhance patient care. While this type of general statement remains somewhat vague as to what constitutes such help, the report comments further that in a CDS “the patient’s information is matched to a clinical knowledge base, and patient-specific assessments or recommendations are then communicated effectively at appropriate times during patient care”.  Therefore, as used here, CDS is more than just the effective presentation of integrated patient information, as might be done by a Medical Device Data System (as discussed here) for example. Instead it is knowledge based and the relevant knowledge is used to compare a patient to a predefined pattern in order to “suggest” or “advise” (or “tell”) the clinician what course of treatment is to be followed.

In this regard a CDS is, in older and somewhat forgotten terminology, an expert system. Introduced in the late 1990′s,the idea of an expert system was that the knowledge and expertise of one or more human experts could be captured and implemented as a computer code. Once this code was written (and perhaps verified), it would be possible to enter a new situation within the domain of the expert system, and the expert system would then provide the same result as the original expert or experts. It was further believed that some expert systems could be written that could “learn” such that it actually became more expert than the original experts whose knowledge was tapped (by a knowledge engineer) in its original creation. Of course such learning could only occur if the expert system was given controlled feedback along with having a coding scheme that was self adjusting. Neural nets was one of the popular approaches to such learning.

Many challenges were realized in the early development of expert systems, and these challenges are now being rediscovered in the attempts to develop CDSs. The first challenges are whose expertise is it that we want to capture, how expert are they, and how wide and deep is the agreement among several such experts. In this regard a student of mine once suggested that we title a paper “Expert System or One Guy’s Opinion.”  Even given an expert or group of experts it was then discovered that in many cases they couldn’t tell you exactly how they made decisions because the basis of their expertise was actually at least in part vague and uncertain. It was then further discovered that being perhaps somewhat embarrassed by their lack of certainty, the expert would fabricate a methodology that wasn’t what they actually did.

In the current CDS projects the challenges of the starting expertise is generally being approached by using practice guidelines that are already established (e.g. the American Diabetes Association’s Diabetes Management Standards of Care), i.e. there already exists a set of knowledge (mostly in words) that can be used as the basis for the software. However, and perhaps not surprisingly, even existing practice guidelines have their challenges. One is how robust are they, especially with respect to unusual patients, and how is the unusual patient identified such that the CDS is not used for their case? This is the domain problem; who is in the domain in which the CDS works, and who is not in that domain, or perhaps not fully within the domain. For such patients, will they be clearly distinguishable as not being appropriate candidates for the conclusions reached by the CDS?  And will this stop the CDS from providing its recommendations? Where there is understanding of this clinicians might be properly reluctant to follow the CDS recommendations. A related question is who is responsible if the CDS makes a recommendation that turns out to be wrong. It is of interest here that the CDS would be a product subject to both negligence and product liability, whereas a human decision is subject only to negligence law.

Thus one barrier to CDS implementation identified in the AHRQ report is that clinicians other than the developers might be reluctant to follow the system’s advice. And perhaps appropriately so. Interestingly, even clinicians participating in the development did not necessarily want to use the system that resulted.

A fruther problem identified is that “written guidelines do not allow for their direct translation to computable code”. This occurs because code generally seeks certainty while written language may not, perhaps because certainty does not exist. The answer here is not to force people to create certainty. The imperative to code should not be used to make people agree on things that aren’t necessarily correct, and with which they actually don’t agree. A closely related issue is that “the technical translation of guidelines into executable code requires a high level of clinical…knowledge and experience”. This is again in part because the original guideline language is not exact, probably because the underlying medical knowledge is not exact. In this regard it can be noted that the term evidenced-based medicine does not mean proof-based medicine. The AHRQ report reaches a disturbing conclusion in this regard; that “guidelines should be specific, unambiguous and clear.” At least this needs the addition of “when possible.”

Beyond these fundamental expertise questions, a number of others were raised by the two projects including understanding the scope and requirements of the task, data capture, clear and effective management, plans for obtaining clinician buy-in, and work-flow implications. The AHRQ report also concludes that these interventions take considerable time and effort, and that a lack of alignment with an organization’s overall goals and incentives can adversely affect these projects. These observations are hardly surprising and are applicable to almost everything we do, and the bigger the potential impact of the project is, the more this is the case.

William Hyman is Professor Emeritus of the Department of Biomedical Engineering at Texas A&M University. He recently retired and has moved to New York City where he continues his professional activities.

These rules defines 25 functions that together constitute meaningful use. Each of these also has a level of performance that is required for ultimate certification (as listed in the January 13th FR). For example, the first use (see below) of “Use Computer Provider Order Entry (CPOE)” has the criteria that it is used for at least 80% of all orders; but only 10% for hospitals. How an EHR is actually used by the provider is an interesting and important distinction from what the system is capable of, i.e. if the system provides for CPOE but if the users don’t use that capability to an adequate degree, then by these definitions meaningful use is not achieved. Thus what the EHR can do is a necessary but sufficient condition to establish its certifiablity.

The 25 elements and an abbreviated statement of the associated measures are:

1. Use Computer Provider Order Entry (CPOE) (80%/10% hospitals)

2. Implement drug/allergy checks (Enabled)

3. Maintain an up-to-date problem list of current and active diagnoses (80%)

4. E-prescribing (Eligible Professional (EP) only) (75%)

5. Maintain active medication/allergy list (80%)

6. Record demographics (80%)

7. Record and chart changes in vital signs (80%)

8. Record smoking status for patients 13 years old or older(80%)

9. Incorporate clinical lab-test results (50%)

10. Generate lists of patients by specific conditions(demonstrate)

11. Report ambulatory quality measures to CMS or the States (EP only) (attestation)

12. Send reminders to patients (50% of patients 50 and older)

13. Implement five clinical decision support rules relevant to specialty or high clinical priority (implement)

14. Check insurance eligibility electronically (80%)

15. Submit claims electronically to public and private payers (80%)

16. Provide patients with an electronic copy of their health information upon request (80%)

17. Provide patients with an electronic copy of their discharge instructions and procedures at time of discharge, upon request (Hospital only) (80%)

18. Provide patients with electronic access (10%)

19. Provide clinical summaries to patients for each office visit. (EP only)

20. Exchange key clinical information (80%)

21. Perform medication reconciliation (80%)

22. Submit electronic data to immunization registries (one test submission)

23. Provide electronic submission of reportable lab results to public health agencies (one test submission)

24. Provide electronic syndromic surveillance data to public health agencies (one tets submission)

25. Protect electronic health information (risk analysis)

Of the above there are at least a few that have the sense of decision by committee. For example in 8, why is smoking of unique interest? Why not obesity or other conditions? Why not 12 instead of 13? Some of the measures are also interesting. Why is 80% the most common? (Perhaps because in school it is a B and everyone wants to get at least a B.) However from a safety perspective, why is it acceptable for 20% of patients to not have an electronic copy of their discharge instructions, and who are these 20%? Even more curious, why is electronic access set at 10%, which hardly seems significant. If it is because of a low expectation of computer availability, then what are the 80% with electronic discharge instructions doing with them?

Number 13′s implementing decision support rules is perhaps one of the issues that is closer to the core interests of readers here. This is intended to occur at the point of care, and is included to “facilitate disease and medication management; and reporting clinical quality measures and public health information”. Further, decision support is described as “health information technology functionality that builds upon the foundation of an EHR to provide persons involved in care processes with general and person-specific information, intelligently filtered and organized, at appropriate times, to enhance health and health care”. Filtering we can all understand. What makes it intelligent filtering is open to debate and validation.

In addition it is stated that research has shown that decision support must be targeted and actionable to be effective, and that “alert fatigue” must be avoided”. This suggests some important design issues.  These decision support rules are in addition to drug interactions and allergies and may include the use of demographic data, specific diagnoses, test results and/or medication lists. It is further suggested that this implementation might include automatic electronic messaging including pop-ups and sounds, other alerts, and (perhaps most interesting) “care suggestions” based on the rules and the evidence. Such advisory functions have significant issues with respect to the reliability and portability of advice on an individual patient basis, and the degree to which caregivers are expected to rely on that device (regardless of the manufacturer’s disclaimers). On a different note, the potential for pop-ups and sounds littering the EHR suggests that destructive sabotage might soon follow.

The 25 elements are also captured (but not in order) in the 5 categories of: Improving quality, safety, efficiency and reducing health disparities; Engage patients and families in their healthcare; Improve care coordination; Improve population and public health; and Ensure adequate privacy and security protections for personal health information.

The effort to standardize and define EHR capability is clearly a daunting one, and perhaps ever more so when there is Recovery Act money on the table. Certainly some specific expectations are required because we want our tax dollars to be be spent wisely. However there is the associated risk that what you require is all you are going to get.

William Hyman is Professor Emeritus of the Department of Biomedical Engineering at Texas A&M University. He recently retired and has moved to New York City where he continues his professional activities.

While I’ve done projects for some great health care providers (Providence, RWJUH, Spectrum and Partners), most of my business has been on the vendor side. This past fall Marilyn Hailperin of Santa Rosa Consulting contacted me about working for their firm. We have entered into an agreement where all of my consulting for health care providers is done through Santa Rosa, while I continue to pursue consulting business with manufacturers as Medical Connectivity Consulting.

Santa Rosa Consulting was founded this year by Richard Helppie, the founder, Chair and CEO for Superior Consultant. One of the hospital consulting market segments Santa Rosa is targeting is point of care workflow automation and medical device integration. Here’s more from the press release:

As part of the Santa Rosa team, Mr. Gee will provide consulting services related to point-of-care technology strategy development, clinical workflow optimization, technology vendor selection, risk management of converged medical device/enterprise networks, and support for Santa Rosa’s PCDI [Patient Care Device Integration] implementation team.

Santa Rosa Associate Partner and National Practice Director for PCDI, Marilyn Hailperin, says, “We are pleased to have someone of Tim’s caliber on our team. He has long been an advocate and recognized authority on medical device connectivity. Tim brings essential real-world knowledge and expertise to our clients to maximize their investment in point-of-care technology, achieve the benefits of patient care device integration with information systems, and attain “meaningful use” certification with respect to medical device interoperability.”

While Santa Rosa gets to use me in their provider practice, my provider clients also benefit in a number of ways:

• With hundreds of consultants, Santa Rosa can provide resources to increase the size and scope of projects I’m able to take on
• Santa Rosa also provides the traditional health care IT consulting firm infrastructure (handling invoicing, expences and project management) that solo consultants are hard pressed to provide
• Now Santa Rosa’s provider clients will benefit from my manufacturer consulting experience, in addition to my subject matter expertise

As a principal consultant for Santa Rosa, I’ve completed my first engagement for Marilyn, defining an operating framework for the deployment and ongoing support of patient care device integration at Virtua Health. The main deliverables for this engagement were 22 standard operating procedures and 2 additional controlled documents (more on this later). You can read about the overall project, including the operating framework in this testimonial.

Besides completing consulting engagements, I’ll be helping Santa Rosa promote their PCDI practice. To that end, I gave a keynote at the NJ HIMSS Chapter Fall 2009 conference. You can download the presentation here (warning, it’s big). There’s also some upcoming webinars in the works for some other regional HIMSS chapters. Finally, I will also be writing blog posts on the Santa Rosa Team Blog (here’s the first post). You can also see the Santa Rosa Consulting banner in the right hand column, click on that to straigh to the Santa Rosa site.

I’m very excited to be working with such a successful and experienced team as the people at Santa Rosa Consulting.

The small photo accompanying this post is of a portion of the PCDI integration lab at Virtua Health, managed by Linda Chan.

Evidence of all of this can be found by looking back at the past 10 or more years and examining typical implementations of biomedical device connectivity to information systems.

•    Most implementations up to now have been in very specific care areas such as the ICU and OR.

•    Most implementations are relatively small in scope, often in the area of about 20 to 50 beds. Incidentally, for most US hospitals this happens to be about the same number of ICU beds per facility.

•    In the ICU, the key devices that are interfaced are typically multi-parameter patient monitors and sometimes ventilators – but vents to a much lesser degree than monitors.

•    In the OR, the key devices are typically patient monitors and anesthesia/gas machines.

•    Outside of high-acuity care areas, in the general ward there are some limited niche interface solutions for mobile vital signs data capture. Many of these are only semi-automated in terms of truly automating both the data capture and the clinical workflow.

•    For virtually all of these implementations, the data collected from the devices is identified though a mapping of the medical device’s location – that is a bed or room location identifier is used to associate the data and alarms.

•    The device workflow – that is the steps clinicians are required to perform at the bedside to interact with devices to establish connectivity – has been limited. This is because most of the devices are actually fixed to the location – i.e. the monitors in ICU are mounted to the wall and data is interface via a networked gateway with outbound HL7.  Therefore few if any steps are required by clinicians because the devices are permanently tethered to a local PC or terminal server that facilitates the data collection.

But as discussed in some of my previous market trends postings – requirements for connectivity have been changing and in some not so subtle ways. Many hospitals are now starting to look beyond departmental connectivity solutions (i.e. the tactical approach) and are now evaluating their enterprise needs. Looking at an entire healthcare enterprise requires a more comprehensive evaluation of the healthcare organizations’ goals and requirements – and this requires more strategic thinking and planning in a number of areas. Hospitals that attempt to extend their departmental connectivity strategies and technology platforms in ad-hoc fashion, will hit the wall at some point. And in the end, I believe those hospitals will likely spend a lot more time and resources (not to mention money) unwinding what they have in place in order to achieve the level of results that most hospitals are looking for.

In the past, patients on general medical-surgical floors did not have biomedical devices. But over the past five to ten years, the acuity level of general ward patients in many hospitals has increased significantly. Now these patients often have one or more IV pumps and patients are always at least periodically monitored via spot check monitoring every 2-4 hours. And there is a shift towards continuous monitoring in the general ward, mainly to provide caregivers an early warning of rapid decline in state. Rapid response teams are being formed in many hospitals as a means for dealing with early intervention to prevent patient crashes. In all of these cases, the connectivity requirements are distinctly different as compare to a high-acuity (i.e. ICU) environment.

I am beginning to see more and more hospitals recognize this situation, and as a result they are starting to assess connectivity requirements across their entire healthcare enterprise. In addition to increasing acuity levels across all care areas, hospitals are also thinking about some of the challenges around their EMR. Many institutions have one main EMR vendor but many of them have to also deal with the fact that they have several “point EMR solutions” in specialty areas. For example, many times a hospital will have a different vendor in the OR for the anesthesia charting application, and another in the ED for emergency department management. This adds both complexity and confusion for the hospital trying to evaluate their medical device connectivity options, mainly because their departmental applications often come with their own niche solution for solving device connectivity in the specialty care environment.

There are three main use models or categories of medical devices and this has an impact on the connectivity solution and workflow.

•    Category #1 includes the fixed devices – such as anesthesia machines in the OR, or a patient monitor mounted to the wall in a patient’s ICU room. These devices are not going anywhere so managing connectivity tends to be a little easier (sometimes via networks gateways).

•    Category #2 includes devices that can move from patient to patient periodically, but once moved, they remain with the new patient until the patient is transferred or discharged. These would be devices like patient-worn telemetry, IV pumps, and ventilators.

•    Category #3 is transient devices that come and go and move from patient to patient on a frequent basis. Unlike category 1 and 2, these devices could contain data for more than one patient. Examples of these include POC blood testing devices and vital signs spot check monitors used on general medical-surgical floors.

Hospitals are also starting to recognize that there are workflow and patient safety implications — i.e. data from a medical device going to the wrong patient’s record, or alarms from a device not getting to the appropriate caregiver.  Perhaps the largest area for potential gains in both workflow and patient safety can be realized by implementing common methods (the workflow steps) for managing the clinician interaction with medical devices, regardless of device type, make/model, category (as described above), or care environment. The process of managing patient ID and association to medical devices is one key area where standardization needs to be thought about and planned for.

For all of these reasons, hospitals have started to realize that implementing connectivity from separate vendors in different care areas (depending on which vendor application is installed in that particular care area), is a recipe for lots of problems. And this practice will only make it harder and ultimately much more expensive to create any standardization when the hospital is ready.

Here is an analogy that may resonate with some of you. Think of how many remote controls you have on your coffee table at home and how problematic it is to train someone unfamiliar with your equipment and setup – just to watch a basic cable-TV program. Perhaps you have addressed this problem and made life easier by investing in a good universal remote? If you did, then you would have realized that the end result is easier training, less steps (think workflow), and less mistakes. And I am only talking about something as simple (or should be anyway) as your home audio-video equipment. Now think about how non-standard all of the bedside equipment is and how the clinical staff can function without making mistakes.

I would be interested in knowing what hospitals are doing to look at connectivity more strategically and how they are going about assessing their situation and requirements. Let me know what you think?

I’m curious if anyone has been successful using their own vendors to pull cables for monitoring installations.  With the monitoring OEM we work with, they simply get a local subcontractor to do the cable pulls.

So this would involve breaking future monitoring packages up into two quotes:  one for the actual technology itself (and associated installation and implementation), and then one for just the cable pull work.  The latter would get bid out, and the OEM could compete against other vendors.

Of course, the OEM can just take the profit they would have made on the cable pull and add that to the cost of the equipment bid.  One would need to find a way to watch that carefully.

Which lead to a critical observation from Craig Muehling:

We have started pulling our own cable for monitoring installations. I have one happening now and I’m not exactly pleased how it’s working out. I won’t mention and names, [vendor name removed] but they make their equipment charges per drop whether you have any drops or not.

I would still like our [networking] vendor to do the networking, ie: install and configure switches and physically plug patch cables into the switches. Seems easy, but the way they [the patient monitoring vendor] charge it’s really not much less than if they did the whole job. I think from now on, we will have to take on the entire networking job.

I have learned a lesson from this last installation and will scrutinize the quotes closer from now on, but with their charging structure
(supposedly) there’s not a lot of options. Either we do the entire job, or they make lots and lots of money for relatively little work.

Here’s how they do it at the Mayo Clinic, from Steve May:

We have our own low voltage and high voltage contractors for all in-house cable pulling, to include data pulls and all project related work, so cable pulling and wiring costs are never part of an installation package, but an infrastructure cost which we earmark as Capital expenditures and plan/budget annually. Bids & labor costs are renewed by Purchasing every 2 years and our preferred contractors are all able to bid on both project services & time & material services.

It works well because the contractors get familiar with our electrical & system standards, building layouts, construction management staff and our bigger customers (at our project reviews, meetings etc.) whom have special requirements like radiology, surgery etc. All our monitoring projects are hardware only, we are even trying to separate the installation engineering, documentation (which is usually terrible) like red lines drawings and wire lists. We’re also trying to separate the go-live training, to manage train-the-trainer, in-service and certifications by the manufacturer after installation.

And according to Chris:

We do not use third parties to pull cable for monitoring systems.  We pull all of our own cable.   I have about 8 personnel who are Fluke certified to pull and terminate copper and fiber.  Of course any of the technologist on my team can pull the cable.  We have a Fluke DTX1800 as our primary cable certification tool.  We have other tools to validate cable pulls and termination, but the DTX1800 certifies each cable.  Our Information Services department likes our capabilities to certify our own cable.  The IS department “farms out” their cable pulls and terminations to a third-party vendor.

I like that we pull our own cables, this way my team knows exactly where all the runs are located, for each area, and they are confident that the job is done right.  We have had to work side-by-side on many projects with the outsourced vendor for the IS cable pulls.  Their technicians ave laughed a few times because we have pulled many cables at one time during an install and tested each one and they all passed the certification process.  They laughed because they said when they pull that many cables at once, they usually have around a 10% failure rate (bad termination or poor fiber signal).  I also think pulling our own cable makes us better at understanding networking.  It certainly aids in troubleshooting.

All of our UPS’s are networked [i.e., monitored] and that way we get paged and e-mails if a UPS is starting to fail or the room temperature where the UPS is located gets too high.  We have remote sensors that attach to the UPS for monitoring environmental conditions. Our Philips Monitoring Network uses Cisco routers and we have downloaded a very nice application that monitors all of the routers and switches in the network, again paging us if there are problems. 

I believe that pulling our own cable is just an extension of managing our networks for which we have responsibility (CCTV, Card Access, miniPACS, etc…). Last year we saved over $340,000  by pulling our own cable versus outsourcing including overtime labor for some of the larger projects.

And J. Scot Mackeil suggests the following best practice:

Have ALL the data cables that carry life critical monitoring data around the facility be a unique color per hospital policy.  When my hospital started installing spacelabs IP networked monitors and replacing the DEC net stuff, I insisted we adopt such a policy and stick to it. Every medical monitoring network run and patch panel from the servers to the local closets to the wall plates to the monitors is done in HOT PINK Cat 5 cables.

There is no way the IT or facilities guys can mistakenly disturb a life critical monitoring application as our cable color screams out loud and clear, “don’t mess with me!”  Our connections to the cloud are by VLAN and in the racks, we have 24 port ethernet hubs, installed so we could isolate from the network in the event of a major IT failure.

This approach works great for private networks like those required by patient monitoring systems. The industry trend, however, is to converge private medical device networks with the enterprise network. Medical device systems running on enterprise networks have a whole different set of best practices.

Jerry Messina noted that, “Some vendors will not certify the network if they or their contractor does not do the cable pulls.” And Ray Brown expanded on Jerry’s observation with the following:

I got a question or two about cable pulls. I was in a Biomed / IT meeting earlier today, and I wanted to see if the following was specific to just Missouri, or if it was USA-wide. Also, let’s pick two different types of data runs, and I’ll be specific – GE PACS, and
Philips Intellivue networks.

Is there a rule on the books that, “if you run wiring to any Biomed equipment that affects a patient or patient care, the FDA requires those lines have to have certification, and you must keep a copy of the certification for 25 years.”

I know Philips especially wants their lines certified before use, but keeping the certificate on hand for 25 years? This information came to my Director via the Missouri State Engineering Association, and I just wanted to see what else was on the books.

The FDA is a convenient lever for many situations, but one not always applied correctly. My response follows:

In general, FDA regs look at two things, 1) the processes a manufacturer follows to design and manufacture medical devices, and 2) the safety and efficacy of medical devices via the FDA’s classification related regulatory clearance/approval processes (Class I, II and III). As a health care provider, the FDA has no regulatory oversight over you unless you do things that meet the legal definition of a manufacturer.

Manufacturers submit entire medical device systems to the FDA. These systems are described by (among other things) marketing claims/intended use statements, product and system specifications, and resulting verification and validation testing. It is this totality of the product/system, as it is intended to be used, that is cleared or approved by the FDA.

Complex systems that include networks and interfaces to other devices and/or systems end up blurring the lines between what is and what is not a part of the regulated medical device. For example, if a medical device system runs on a network (physically separate or as a VLAN on your hospital enterprise network) the network is part of the medical device.

The buyer of these systems should maintain their systems within the specifications used by the manufacturer in the design and installation of the system. Not conforming to these specifications result in a medical device system that is different from what was designed and tested by the manufacturer, and different from what was cleared or approved by the FDA. It is those vendor defined specifications that received FDA clearance, that must be maintained over the useful life of the system.

Thus the principal reason to conform to manufacturer’s specifications is to ensure safe and effective operation of the system.

There is no FDA regulation that says customers can’t install systems themselves or change something in a system, but to do so in a way that fails to meet the manufacturers specifications would likely render the system an “off label” use. There is no legal “certification” process that hospitals must meet, nor are there any requirements to maintain “certification documentation” for 25 years.

When manufacturers install complex systems in a hospital they do (sometimes a considerable amount of) verification testing after the installation, to ensure that the system — and the broader network and IT environment in which it is installed — meets the specifications for that system defined in the design documents of that product. This process is sometimes referred to by the vendor as “certification”, but is not recognized as some kind of official or endorsed certification by the FDA or anyone else.

System specifications for any product change over time, usually because parts used in the system become unavailable and the manufacturer has to find replacements that change specifications. It is also possible for hospitals to go outside of specifications with relative safety, if they follow a risk management process similar to the one used by manufacturers. Such an effort is not a trivial task, and is rarely undertaken by hospitals. (Specifications are often unknowingly changed frequently by hospitals, but that’s another issue.)

Regarding your specific cabling example, the manufacturer writes a specification for that cable, perhaps something like, “shielded twisted pair Cat 6 cable”. There may also be specifications about physically routing the cable (distance from EMI sources) and/or specifications for testing the cable run after it is pulled for attenuation, noise, etc.

Provided the manufacturer gives you all those specifications, you can certainly pull cable and do other installation tasks yourself. By following the manufacturer’s specifications (including testing), you can remain fully in compliance with what was approved by the FDA. If the manufacturer choses not to share those specifications with customers, that is their choice and not something mandated by the FDA.

UPDATE: The title for this post was revised to better indicate the subject, which is the installation of patient monitoring system networks.