Except for emergent situations, no medical device is used without an order. And if not an order written to accomplish a certain clinical task for a specific patient, then "standing" orders captured in written policies and procedures to handle frequent, routine situations. Consequently, orders are one of the first workflow steps in medical device connectivity. Orders are pervasive, used in all health care delivery environments from acute care hospitals to patient's homes.
Principal ways connectivity can add value to medical device are enhancing patient safety, improving clinical efficacy and productivity. That the inappropriate use or misuse of medical devices can result in patient injury or death is not news. Proper use or misuse can start with the order. Well designed and implemented order workflow automation in a connectivity solution can impact patient safety, the efficacy and utilization of the medical device, and staff/unit productivity. Besides their own unique considerations, order workflows share many of the risks and potential benefits of other types of connectivity workflows.
Diagnostic vs Patient Care Devices
The nature or characteristics of order workflows is highly variable. When analyzing order workflows, it can be useful to consider the similarities and differences between how orders are used with diagnostic and patient care devices. Diagnostic modalities, be they interventional radiology suites, endoscopy labs or EKG carts, tend to be procedure volume oriented operations. Typically, what's being ordered comes right off a straight forward pick list - there is little ambiguity. With diagnostic medical devices, value tends to center on throughput, diagnostic confidence and avoiding unnecessary costs, such as procedure delays, duplicate or unnecessary tests. Orders can be quite useful in driving preparation for complex diagnostic procedures like cath lab studies, where different equipment, equipment configurations, supplies, consumables and/or implants is highly variable. And of course, communicating the specifics of the order to the tech or clinician doing the diagnostic procedure can improve throughput and reduce the need to repeat studies (because the first one was done for the wrong order).
Orders associated with patient care devices (e.g., patient monitors, infusion pumps, ventilators and other devices used at the point of care) can be different. The orders themselves may not come from a neat and unambiguous pick list. There also tend to be more "standing" orders with patient care devices. The work environment where diagnostic modalities are used tends to be focused on the procedure at hand with relatively few distractions. Patient care devices tend to be used in patient care areas (or during transport) and the work environment is plagued with frequent interruptions with patient requests, family members, communications with staff, medical device alarms and other emergent situations, and competing tasks associated with a long worklist of tasks for caregivers. The risks and rewards for traversing the workflow from order to the successful fulfillment of that order also tends to differ with patient care devices.
Order workflows are often tightly integrated with patient data management and patient context. Orders are always applied to specific patents, resulting in the creation of an association between the patient and the medical device (patient association). And before you can associate the medical device with the patient, the patient's data must be part of the patient data management system. Due to this interdependency, the effort to add order workflows is often leverages at least some of the work done to implement patient data management and patient context. Likewise, there is a synergy among these workflows and the addition of order workflows may provide value that outweighs the effort to implement the order workflows.
Order Review and Analysis
The first domain or application of order workflows we'll consider is the review and analysis of orders. This review and analysis considers numerous factors concerning the patient and the order to ensure the order is safe and likely to advance the patient's diagnosis and/or treatment. Prior to configuring and engaging the medical device, the order is reviewed to ensure that resulting device configurations are consistent with patient physiology and that the order is consistent with, and not contraindicated by the patient's(preliminary) diagnosis. The benefits from this review can be improved patient safety (and reduced or avoided adverse events), improved device utilization and user productivity.
A common example of order analysis is found with infusion pumps. Due to the specialization of medication administration and long availability of pharmacy information systems and resulting rich feature set, infusion pump orders are typically reviewed in the pharmacy outside of pump workflow automation. However, there is a second review that is done via the Drug Error Reduction System at the point of pump configuration - this review is driven by the order for the pump.
Another interesting order workflow revolves around ventilators. Writing orders to put a patient on a mechanical ventilator is complex. Ventilator controls, variables and alarms vary across ventilator manufacturers, and sometimes across a single ventilator manufacturer's product lines. This variation is compounded by the fact that most hospitals use ventilators from more than one manufacturer. When a pulmonologist writes an order they are experts on the ventilators in their facility. Consequently, the order they write is very specific - even to the point of specifying a make and model of ventilator and initial settings for that ventilator's parameters. When an intensivist or internal medicine physician write a similar order, the orders tend to be more generalized and less specific and it becomes the responsibility of the tech to select the most appropriate ventilator and to apply the generalized order to the specific parameters and settings of that ventilator.
As noted earlier, orders are a great source of information indicating what supplies, disposables and consumables will be required for a specific order. This information is not included in the order, but can be inferred by associated these types of requirements for specific orders. Similarly, different physician preferences can come into play whereby the order and fulfilling physician, taken together, can drive the creation of a list of required items based.
A myriad of things are ordered in the diagnosis and care of patients. Depending on the order specified and based on a variety of factors, there can be a meaningful risk that the order will not be fulfilled. Hospital acquired conditions are a perfect example. Patients may be screened for risk of pressure ulcers, ventilator acquired pneumonia, urinary tract infections, infections associated with invasive pressure lines and falls. Should the patient be determined to be at risk, an order (often a standing order) is applied and the patient is designated to receive care intended to greatly reduce the risk of experiencing one of these hospital acquired conditions. The potential value here is that routine tasks have a way of sometimes not getting done and impacting patient safety, length of stay and reimbursement. There are analogs to these "misses" with orders for many different types of medical devices.
Auto Configuration
The configuration of a medical device can be derived from the order for many devices, directly from the order or after order review and analysis. This applies to device selection, configuration and settings for devices that provide therapy delivery, monitoring and diagnostics. The most prominent example in the market is auto configuration of infusion pumps based on orders from CPOE and pharmacy systems. (The best, most current write up of pump interoperability is this article (pdf) by Dan Pettus and Tim Vanderveen in BI&T.) If you read the aforementioned article, you'll see that configuring pumps based on orders is rather complex. Fortunately, not all medical devices have near the complexity of infusion therapies.
Constraints and Challenges
Like any connectivity workflow, orders workflows must provide appropriate process and automation support while at the same time, embody sufficient flexibility to accommodate natural workflow variations and exceptions. One potential workflow constraint regarding orders is that orders are often essential to subsequent workflows. Diagnostic point of care testing (POCT) systems are a perfect example. Proper workflow automation to support POCT requires integration with both the hospital ADT system, and the lab information system (LIS). When POCT systems first came out, less than 50% of test results found their way into the patient's chart. The POCT vendors created a result at the bedside (or nursing station) and via a docking station were able to push the result to the LIS. The problem was, the LIS would not accept a test result for which there was no order. It turns out the tests were verbally ordered by the clinician at the point of care - the intended scenario for "responsive" POCT systems. Caregivers rarely made it back to a computer terminal to enter the physician's order so they could then push the result to the LIS. In the past few years, new POCT systems have come to market and solved this unfortunate problem - often by starting the workflow with the creation of an order via the POCT device.
The conclusion to be drawn from the POCT example is that orders may be required simply to enable existing external information systems to support the desired medical device workflow automation. Dependencies with systems integration can entail numerous systems: inventory, departmental information systems, messaging systems, HIS/Order Entry, EMR/CPOE or ADT.
Having scratched the surface of order workflows, both the potential value and complexity should be apparent. As always, the discussion of this particular workflow is not all inclusive and does not constitute a complete recipe for designing and implementing order workflows. Properly capturing order workflow requirements requires detailed requirements gathering that goes beyond traditional Voice of the Customer type efforts. The best requirements come from direct observation and the connectivity experience to identify those workflow features with the greatest potential value.
Recent Comments