Scheduling is not a workflow one normally associates with medical device connectivity. In some applications, scheduling is handled by software separate from the connectivity solution. Sometimes, scheduling is not done at all. In other applications, as we shall see, scheduling is so much a part of the broader workflow, that it’s hard to recognize as a scheduling task. Two illustrative aspects of scheduling will be discussed, scheduling for diagnostic modalities and scheduling for routine patient care tasks. Because it’s less understood (and frankly more interesting) we will look at scheduling for routine patient care tasks first.
Patient care tasks encompass routine activities carried out by caregivers and/or aids. Examples of these routine tasks include vital signs collection, medication administration, bed turns (to avoid hospital acquired pressure ulcers, or HAPU), and respiratory circuit flushing (to avoid ventilator acquired pneumonia, VAP). These tasks must be completed at a predetermined frequency on a reliable basis or adverse events – including patient death – can result.
While the scheduling workflow diagnostic tests is very medical device centric (getting the patient to the device), patient care task scheduling is more patient centric (as in ensuring that certain patient care tasks are completed). The order for these routine tasks come from the ordering physician in numerous ways. Often the actual patient care task is implied by the physician order and must be interpreted by the caregiver. Some tasks are initiated based on operating policy that requires that patient’s be screened for things like HAPU, VAP or fall risk. Patients that meet the at-risk criteria then receive the routine care prescribed by the policy.
Identifying all the routine tasks associated with a given patient is not the hard part. The challenge is ensuring that these routine tasks actually get done, and completed within the specified time frame. The reason this is a challenge is because of the interrupt driven environment at the point of care. This adverse work environment is at the root of many patient safety challenges found at the point of care: medication administration errors, hospital acquired pressure ulcers, ventilator acquired pneumonia, fall prevention, failure to rescue, and more. Besides failure to rescue, everything on the preceding list succeeds or fails based on completing routine tasks.
The need to balance nursing vigilance, medical device alarm response, patient and family member requests, and reliably completing routine tasks is a tall order. Past efforts to improve this situation have focused mainly on trying to develop and apply information technology to transform the point of care into a more manageable and predictable environment. Sadly, there is no information technology in existence that can direct when a patient needs to use the toilet, when their pain becomes intolerable, or when a patient’s condition deteriorates generating a medical device alarm. Not surprisingly, attempts to reduce the interrupt driven nature of the point of care have failed.
While it is possible to somewhat improve improve workflow and nursing unit design to minimize interruptions, solutions that bring meaningful improvement to reliably completing routine tasks on schedule remain scarce.
Reliably completing routine tasks can be thought of as a connectivity solution. Let’s consider bed turns as a means to prevent HAPU. First the patient must be screened and identified as at-risk, and an appropriate prevention regime selected – this portion of the workflow is well understood and widely adopted. What’s missing for many point of care tasks is a solution that improves on the implementation of the previously selected patient care plan. In our HAPU example, the next requirement is a means to reliably know whether or not a patient has been turned within the prescribed time frame. Next, you need a means to prompt the caregiver to complete the required turn that doesn’t itself become another nuisance interruption that detracts from patient care. Finally, the data from this process – when the the actual turns occurred compared to when they were scheduled – is recorded and available for retrospective analysis.
The first example of a solution supporting a specific type of routine care has recently come to market. A similar framework and resulting product could be used to address a variety of activities at the point of care. Some of these routine tasks are more challenging to support with automation than others. A perfect example of a challenging application is medication administration, where initial solutions were shown to be inadequate.
A classic example of scheduling is found in diagnostic imaging, where complex algorithms are needed to match requests for specific diagnostic procedures with available diagnostic equipment/rooms and human resources. This scheduling must be done in a way that evenly disburses workload across on-duty techs and radiologists and also maximizes the utilization of fixed assets such as x-ray rooms, CTs, MRs and interventional radiology suites. These kinds of complex scheduling tasks are often automated using software separate from the connectivity solution – in this example, scheduling is typically found in the Radiology Information System rather than the PACS.
These classic scheduling requirements are common to many diagnostic departments and associated with diagnostic connectivity workflows. Smaller, lower volume diagnostic modalities such as endoscopy and the cath lab may have scheduling included in the same solution as medical device connectivity – either from the medical device manufacturer or a third party.
If there was a connectivity solution for dialysis, this would be an example of a therapeutic modality where patient flow and resource utilization is as important as with many diagnostic modalities. An application like this is simplified in that the dialysis therapy does not vary like different diagnostic imaging procedures, and the dialysis machines on a unit tend to be identical or at least very similar. This greater degree of uniformity means the scheduling process is much less complex.
In certain situations scheduling can morph into more of a workload optimization and fulfillment exercise, somewhat different from the typical prospective scheduling scenario. For example, orders for clinical lab tests are generated by providers on nursing units or in their offices. These orders are received by the lab information system (LIS) which then dispatches phlebotomists to collect specimens which will then be tested.
A key part of the scheduling process is the initial capture of patient information. These patient demographics are captured along with the specific exam being ordered, the ordering physician and any special instructions regarding the patient or required time frame for the study. Some of this data, such as orders, may be available from other systems and can be pulled in without requiring the user to reenter that data. In some workflows, the order may follow the request to schedule the study. When this happens, there must be a validation step where the scheduled study and the ordered study are compared to ensure they are identical – and the ability to resolve any inconsistencies found.
Besides the obvious value of scheduling the study or some other patient encounter, scheduling data can indirectly support operations. For example, the schedule can drive when to push work lists or copies of orders to medical devices and/or techs to improve workflow. Scheduling data can also be used to determine optimal staffing levels for the scheduled workload. The scheduling of tasks can be part of a connectivity workflow, or a point of systems integration that feeds data into the connectivity workflow.
The foregoing scheduling workflows are mostly well understood. The software for supporting these kinds of scheduling tasks is mature and most of these markets have reached penetration and become replacement markets.
Routine tasks in patient care can be approached as scheduling challenges. Unlike with scheduling diagnostic tests, patient care task scheduling is more about the implementation of the tasks than the determination of when and where they should occur. There is a rich set of patient care tasks at the point of care that present persistent challenges to consistent implementation, resulting in adverse events and subsequent attention from the Joint Commission, AHRQ, CMS and others. It seems the industry – manufacturers and providers – are just now starting to come to grips with these routine clinical tasks.
Connectivity enabled medical devices send patient data right out of the medical device to a network, be it a body area network, cellular broadband network, home or enterprise network. The network then conveys this medical device data to databases and applications that store, display and manipulate the data. When a medical device is directly attached to a patient, there is no question as to which patient the device data belongs. As soon as the data leaves the actual medical device via the serial port or a network connection, the association of that data with a particular patient is no longer obvious.
Much of the data used in establishing and maintaining patient association or patient context comes from, or is stored in, the patient management database. Patient management workflow is an important enabling component in the overall connectivity solution and key to patient context management.
It is critical to reliably know that the data from a medical device belongs to a particular patient. If the data is not associated with any patient it’s worthless; should the data be associated with the wrong patient it could be deadly. When patient data from patient A is misidentified as belonging to patient B, patient A can miss out on a life saving clinical intervention that is mistakenly applied to patient B. In this example, patient A may die due to a lack of care, and patient B may be injured or die as a consequence of receiving some clinical intervention that is not needed and could be contraindicated. Consequently, safe and reliable patient association or patient context management is a foundational capability for virtually any medical device connectivity or interoperability solution.
Many patients are connected to a medical device over time. Besides accurately identifying the patient currently attached to the medical device the design of patient context management features must reliably known when the patient that’s been attached is now detached and that subsequent physiological data is from a new patient rather that the previously attached patient. Now this may seem like a no-brainer, and in many cases it is self evident. But, this is not always the case. When reviewing data retrospectively, the user has no way to know if gaps in data represent changes in patients. In actual operation, the device and patient may be out of view of clinicians and caregivers. Staff often circulates and changes as shifts change, so that in certain situations patient context is no longer self evident and how patient context management is designed becomes critical to ensuring patient safety.
Besides the obvious patient safety issues, patient context faces another difficult challenge: usability and workflow. Identifying the patient to the medical device, i.e., establishing patient context, is not something that is done when there is no connectivity feature. Consequently, any patient context workflow becomes “extra work” or workflow steps that were not required prior to connectivity. Connectivity is supposed to provide workflow automation, which implies less work rather than extra work. Users of connectivity solutions base their product evaluations on whether the new solution is easy to use and has fewer, the same, or more steps required to use the device when compared to the previous iteration of the device. Poor usability and/or extra workflow steps can spell poor user acceptance or outright rejection.
There are many ways to enable patient context, and can methods vary dramatically based on the use model of the medical device. The following are some key factors to consider when contemplating requirements for patient context:
Spot vital signs monitors are pushed from patient to patient, reading vital signs that then go into the patient’s record. Patient context is created for the time required to gather these vital signs readings (often just a minute or two) after which patient context is removed or torn down. In some systems, the act of creating the next patient’s context serves to remove the previous patient’s context.
This contrasts with continuous data. These use models include many medical devices that are attached to the patient for an extended period of time, from hours to days in length. The data produced by the medical device could be continuous (often waveforms) from a patient monitor or ventilator, or periodic data that represents an episode of care over an extended period, such as alarms or device specific therapy related data from an infusion pump or dialysis machine. In this “continuous data” group of use models, patient association is established for a relatively long period of time and must be maintained over changes that occur naturally over longer periods. Potential changes can include changes in patient location, changes or reconfiguration of the medical device attached to the patient, staff changes, and changes in the patient’s condition.
Many diagnostic patient context workflows are similar to spot vital signs. Patients are queued up and attached to the diagnostic device one at a time in a serial fashion. The patient’s location with diagnostic devices usually fits into one of two models, one where patients are brought to the device (like an endoscopy lab or cath lab) and one where a specimen from the patient is brought to the diagnostic device (like in the clinical lab).
This contrasts with patient care devices such as patient monitors, infusion pumps, ventilators – devices that tend to be attached to patients for expended periods (and longer periods than diagnostic devices). Unlike diagnostic systems which tend to be centered on individual labs or diagnostic devices, patient care devices include multiple devices that operate in the same system. For example, a cath lab control room connects to one hemodynamic recorder and visualization system, while the central station for a patient monitoring system typically displays waveforms from each patient in the unit connected to a patient monitor. These different use models impact the risk analysis, and consequently the requirements, for patient context design.
These are major factors in determining requirements for patient context. Stationary devices are tied to a particular physical location and are often networked via Ethernet – a network with a physical wire. Patients are brought to the stationary medical device, be it a CT or MRI bolted to the floor, or a wall mounted patient monitor in an Emergency Department trauma bay. With stationary devices it is tempting to use location as a key determinant for patient context – in this case, the data from device X is associated with the patient that is also at the same location. There is a risk that the patient we think is in this location is in fact in another location, and patient context is established for the wrong patient.
Portable devices are one’s that are used in a variety of locations within the hospital, within a unit, within a surgical suite, within a patient room or within various areas of a patient’s home. Typically their use model is one where the device is stationary, and only moved between uses. Here one may be tempted to use Ethernet for connectivity, but because of the portable nature of these devices, this will often result in usability and reliability problems caused when the device is moved before unplugging the network cable, or forgetting to bring the network cable to the new use location of the medical device. Moving portable devices prior to removing the network cable results in broken cables and connectors, pulled out wall plates, and sometimes broken medical devices. In almost all cases, wireless connectivity is industry best practice for portable devices.
Mobile devices are devices that are in use while in motion. This could be any patient attached medical device used during transport – inside or outside the hospital – or used when the patient ambulates. Wireless connectivity is the obvious choice for mobile medical devices. Just to be clear, many portable medical devices are only occasionally used in a mobile fashion. But if they are to be effective when mobile, product requirements must actually support mobility. For obvious reasons, industry best practice for devices that go mobile is wireless connectivity.
Wireless connectivity complicates requirements for safe and effective patient context management. Wireless connectivity is not perfect, and especially when mobile, wireless connections can fail for a period of time as wireless devices go in and out of coverage. A key issue here is that it is not always clear if the current set of acquired medical device data is from a new patient or the patient previously (or still) attached to the medical device. To ensure patient safety, the system must be confident that the same patient is attached to the medical device after the device loses its network connection and when it is restored. Assuming the data from the reconnected medical device is a new patient and forcing the user to reenter or re-associate with the same patient mitigates the mistaken identity risk, but at the cost of user acceptance. Most systems implement some sort of algorithm to determine when it is safe to assume the patient has remained the same, when a patient’s ID must be confirmed by a user to maintain an association, and when it is best (for both patient safety and workflow reasons) to assume the patient attached to the medical device is a new patient.
Wireless sensors add additional challenges to the wireless connectivity for patient context management. A key challenge here is the scarcity of user interface on a wireless sensor or gateway device that could be used to implement patient context workflows. Most wireless patient monitors will present a list of patients on the unit from which the user selects the patient that’s being attached to that patient monitor. Yes, it’s an extra step, but it is relatively quick and everything is self contained on the patient monitor. This is not possible with a wireless sensor. The typical user interface on a wireless sensor is one or more LEDs and perhaps an accelerometer or low voltage piezoelectric buzzer or speaker.
Wireless sensor patient context workflows can be further complicated by the fact that users will likely be carrying additional sensors and/or gateways in their pockets. Consequently, a scheme to positively associate sensors with a gateway and with the patient wearing the sensors cannot be designed that assumes that the sensor and gateway will be the only ones within range of each other.
Virtually every medical device made in the last 20+ years meets a basic connectivity requirement in that they output data in a machine readable format. This is done via the serial port on the medical device that uses a communications protocol that is proprietary to that device’s manufacturer (and may be specific to that model of device and even that version of that model). That serial data stream must be parsed to extract meaningful clinical data. And the serial connection must be converted to some sort of network so that the data can be efficiently moved around to the appropriate servers and client applications. The systems that acquire this serial data, parse it and convert it to a network connection are called Medical Device Data Systems.
Most hospitals implementing the clinical documentation workflow are using these MDDS to acquire data from the various medical devices that produce data that ends up on patient flow sheets in medical records.
These MDDS have traditionally been wired systems. In the early days, especially when most medical device being connected were stationary or minimally portable, these systems used stationary terminal servers to convert the serial data to Ethernet. Each terminal server had numbered ports that were associated with the stationary location of the terminal server. The industry best practice at that time was to associate a patient with location, which was then associated with a port number and patient location. This association was done in either the MDDS or EMR away from the patient. This approach worked pretty well but has certain risk management implications.
Theoretically, transactions such as establishing patient context are most accurate and reliable when they occur at the point of care in the physical presence of the medical device and patient. Abstracting the association of medical device and patient by using a terminal server port and bed location to determine patient context is theoretically less accurate and reliable. In the real world, using any medical device systems exposes to the patient to inherent risks that , once identified in a risk analysis, are mitigated by a variety of methods.
There are a number of methods can used to establish patient context. Typically, the best workflow solution is when the user first applies the medical device to the patient and the user indicates the patient being attached to the device. This process of indicating the patient can be implemented in many different ways. The user can select the correct patient from a list presented on the medical device or some sort of client device, or the system can “read” the patient’s identity via a barcode or RFID. Worst case, the user is forced to enter the patient’s name and/or ID into the medical device. Manual data entry is not only time consuming, but also prone to error.
A brief aside about barcode technology: Many medical systems use barcodes to capture data, and they do reduce the potential for transcription and typographical errors when compared to manual entry. While it is often called an “auto ID” technology, there is little that’s automatic about picking up a barcode scanner and scanning a barcode – sometimes repeatedly – until it’s read. This contrasts with technologies that are truly auto ID, like passive or active RFID tags where the system automatically senses the tag and reads the data with no human action required. (There is of course, a manual verification step required by both barcodes and auto ID systems.)
In some situations, the preferred way to establish patient context may be unavailable or inoperable and an alternative method may be required. For example, if patient data is received through an interface to the hospital’s ADT system, and that system is either down or the transactions for a particular patient is lagging, there must be an alternative method to get patient data into the connectivity solution. Or perhaps the barcode reader is broken or can’t read the patient’s barcode; again, there must be an alternative method to enter that patient data. Oh, and don’t forget emergent situations, where you don’t have time to tell the system who the patient is, and situations where you have a patient with an unknown identity. The connectivity solution must account for these variations in workflow.
This concludes the overview of patient context workflow. The goal here is to flesh out a framework to think about and discuss patient context and how it can impact patient safety and user acceptance. By necessity, much has been left out of this discussion. Feel free to suggest additional topics and issues that relate to patient context in the comments below.
In a few short weeks, TCBI will be holding their 5th annual Medical Device Connectivity Conference in Herndon, VA (the Washington DC metro area), November 21-22. It seems like the first conference was only a year or two ago.
Medical device connectivity, or the more fashionable (and some might say, more descriptive) term interoperability, has both changed significantly and remained the same over these past 5 years. Lots has changed on the regulatory and HIT governance front. The FDA has issued guidance on mobile medical apps, wireless medical devices, and cyber security – just this year. The FDASIA report on regulating HIT was presented to the ONC, FDA and FCC.
Almost in tandem with regulatory advances, there is a growing awareness of the need to improve hospital IT governance to accommodate the safety-critical medical device systems that are increasingly supported by enterprise IT infrastructure. Examples start with the promulgation of IEC 80001 in 2010 and more recently to include an article I wrote last year, The IT/Clinical Engineering Governance Gap, and this year, the ONC’s grant for the SAFER project on best practices and risk management for HIT (reference article here), and ECRI Institute’s Health IT Hazard Manager and their overall focus on patient safety and HIT.
The creation of alliances to promote connectivity and interoperability grew this year as well. Both the CommonWell Health Alliance and the West Institute’s Center for Medical Interoperability were launched in 2013 for a total of 10 similar alliances I’m tracking in health care. These alliances join organizations like the IHE and Continua Health Alliance in working to realize medical device connectivity and interoperability.
In spite of a lot of activity, there are some things that don’t seem to change. Certainly manufacturer’s lack of interest in open standards does not seem to have changed. Systems integration continues apace, continuing the strategy of “one-off” interfaces and tightly controlled application programing interfaces (APIs). Connectivity stalwarts, the IHE – and especially the Patient Care Device domain have been consistently working to implement open connectivity between different manufacturer’s products and systems.
All of the above trends and activities are reflected in this year’s agenda. Three clear trends have emerged in this year’s agenda: medical device/HIT governance and regulation, cyber security, and wireless. Our goal every year is to provide timely and actionable information at the conference. I think we’ve achieved that goal this year with a cast of speakers from many exceptional institutions.
Thanks to all of our scheduled speakers for taking the time to tell your story at this year’s conference, increasing our knowledge and advancing the cause of connectivity. Thanks too to Satish Kavirajan, Managing Director of TCBI, for managing the schedule this year, and as always, producing a great event.
I look forward to seeing you all at the Herndon Hyatt later this month.
A key feature of all connectivity solutions is a database that includes all of the patients associated with the system’s medical devices. This is called a “patient census” or ADT (admission, transfer and discharge), much like the way a hospital’s ADT system manages patient demographics for the hospital information system or EMR. Also referred to as patient management data, these data often include: patient name and ID number (permanent medical record number, episode of care number, or both), current assigned location of the patient, and the device associated with the patient. Depending on the application, these data can also include more operational or clinical things like assigned caregivers, admitting and/or attending physician, admitting diagnosis and service unit. It is also possible that this operational or clinical data may be stored in a different file, separate from patient management.
Some workflows or systems queue up patient information prior to arrival or application of the medical device, while others capture or generate patient demographics when the medical device is first applied to the patient. In any event, the connectivity solution must capture patient demographics that are sufficient to ensure correct patient identification and possibly additional information that relates to the use of the medical device (e.g., body surface area – or the data to calculate it, weight, etc.) Common methods to capture patient demographics are an ADT interface and a method of manual data entry. In some cases, it may be practical to capture patient demographics at the same time the medical device is associated with a patient.
This workflow is being tackled first in this series of blog posts because it is a foundation used by most connectivity workflows. Patient management workflow should be one of the last set of requirements completed because it must support all the workflows to be included in the product. What follows, in no particular order, are a number of issues and considerations that fall under the patient management category.
Examples of manual artifacts of patient management are the marker boards seen on the walls of nursing units, cath labs, surgical suites, ICUs and elsewhere. There they track the basic operational data that’s key to successfully completing their mission. Besides the obvious (patient name, location, scheduling or sequence data, clinicians and staff assigned to the patient) there is often information hinting at communications outside the immediate area. Pager or phone numbers for support departments like clinical engineering, radiology or respiratory therapy, on call physicians and others are often tracked on marker boards. If it’s on a marker board in the clinical area that’s the target for medical device connectivity, it’s a safe bet it should be in your requirements. And once it’s in your system, you can replace that unattractive, illegible, and often out of date marker board.
The ADT system as a source for patient demographics is somewhat problematic. Interfacing to ADT systems is not a trivial task; an HL7 ADT interface must be built into the connectivity solution, and each ADT interface must be configured at installation – this is not a “plug and play” interface. Another challenge is the fact that ADT data is dependent on users to update patient locations. Consequently, ADT data pertaining to the department/unit and bed currently assigned to a patient may be out of sync. The reasons for this lack of timely and accurate update are many, and difficult to overcome. As a result, many medical device systems include the ability to manually enter and edit patient information in their own system, separate from the ADT system.
Some might be tempted to simply acquire patient data via the reading of bar codes on patient wrist bands – and this approach may be perfectly adequate for some applications. Hospitals encode various data fields into their patient wrist band bar codes. One must ensure required information is likely to be present, and have a backup plan should critical information not be available via the bar code. Having the customer change their bar codes is only practical if you can reliably get them to actually change their bar codes. Due to how other applications read the bar codes, there may be considerable resistance to changing bar codes.
Without an ADT interface, the product developer is forcing users to manually enter patient management data – a new task they likely did not have to do before “automating” their medical device workflow. Yet, as noted above, data quality issues may preclude relying exclusively on ATD systems for patient management data. Often, the solution is to implement both an ADT interface and a user interface that allows users to enter or edit patient management data manually when necessary.
Repeated readmissions of patients are becoming increasingly important to providers as risk is pushed off to providers to ensure that discharged patients are not readmitted for the same problems. These patients typically have one or more chronic diseases where their condition degrades after an admission and they are readmitted for a clinical “tune up” and then sent back home. Often referred to as “frequent flyers”, CMS and other payors are not reimbursing providers for these frequent flyer patients when their readmission is within a specific time frame. Depending on whether the connectivity application is geared towards acute care of inpatients, disease management post discharge, or both, the management of past patient encounters data may be a desired feature. Some or all of this data may be designed to reside in the patient management database and related workflow.
One of the biggest challenges for medical device makers developing connectivity solutions is to look beyond the connection itself and design an overall solution that provides good workflow. Medical device connectivity is workflow automation through the integration of medical devices and information systems. It is the scope and quality of the workflow automation in a connectivity solution that impacts users, and not just how the connections are technically implemented.
Besides meeting a growing list of market requirements, connectivity aims to deliver certain features and benefits. Typical examples include:
Medical device manufacturers are experts in the workflows related to the direct use of their medical device. This is what I refer to as knobology, and includes applying the device to the patient (or taking a sample from the patient), powering on and configuring the medical device for use with the patient, use of the device while it is attached to the patient (e.g., remote surveillance, alarm management, adjusting therapy delivery, etc.) and finally, removal of the the device from the patient. In addition to automating manual knobology workflows, connectivity requires the automation of workflows that surround the use of the medical device but are removed from knobology. This is where manufacturers get out of their comfort zone as they seldom concern themselves with workflows that are not associated with the direct use of their device.
Any manual workflow associated with the use of a medical device has a certain number of steps required to complete a task. Good workflow automation delivers all the benefits of the connectivity solution, with fewer or at worst, no additional workflow steps required by users to complete their tasks. Bad workflow is where connectivity benefits are offset by making the user complete a greater number of workflow steps for your “automated” solution than they had to complete when everything was manual.
Like any other suboptimal product bought by a hospital, a bad workflow solution will suffer poor adoption and will likely end up hidden in the back of a drawer or cabinet, dropped in the toilet, moved to a junk closet, or simply turned off. (Every hospital has junk closets, or medical device graveyards, where poorly adopted products are hidden from sight.)
There are three categories of medical devices associated with connectivity workflows: monitoring, diagnostic and therapeutic devices. A given medical device system can include one or more of these three categories. And each category has its own inherent workflows and requirements.
The data that is acquired and managed in a connectivity solution can include:
Diagnostic modalities were among the first to receive workflow automation. Due to high patient volumes of many diagnostic tests, connectivity can greatly improve patient throughput, resulting in higher device utilization (doing more tests with the same equipment) and making the diagnostic results available more quickly (both reducing the time to final report and making access to the report quicker and easier). Most diagnostic areas are dominated by a small number of medical devices – think endoscopy or cath lab. The most obvious example is diagnostic imaging and PACS.
Another device category to receive early workflow automation was patient monitoring. Here patient safety was the driver, as manufacturers extended the functionality of their devices with central stations to provide remote surveillance and alarm notification. Connectivity solutions for therapeutic devices have lagged for a variety of reasons, but mostly due to complexity and lower utilization levels – even ventilators aren’t used on that many patients, let alone intra aortic balloon pumps or dialysis.
Here is a list of the common workflows that will be discussed in subsequent blog posts. As the posts are completed, I’ll come back here and add a link to the subsequent post.
The objective of this list is to capture all of the basic workflows that apply to multiple types of medical devices. The last two as categories are intended to contain the more highly specialized workflows. Let me know how you might revise this list.