The first part of this article looked at the basic idea of devices and computer systems that can deal with loosely connected actors, human and mechanical. This part takes it further into current experiments in health care.
Devices Must Adapt to Collaborators’ Needs
To be a useful agent, a computer system must understand the context in which it is operating. Take pulse oximetry–the measurement of oxygen in the blood. It’s an easy procedure to perform, and is used in hospitals to tell whether a sick patient, such as one with lung problems, is in danger. The same technology can also be used by fitness buffs to tell whether they’re getting a good workout.
These are obviously very different goals–and the device used for pulse oximetry will also be used in different ways. In a risk monitoring situation, samples may be taken less often than during a healthy fitness workout. At the minimum, a device should be configurable so that it gives the timing and accuracy needed in a particular setting. It should also be easy to turn a device on and off if it is needed for a limited time period, such as a workout.
Diego Alonso, a researcher at MD PnP, points to analgesia (the administration of pain killers) in the hospital as an example of competing needs that must be reconciled by a supervisor, human or machine. So long as the patient is stable, the pain killer should be administered. But if a monitor notices a drop in the patient’s vital signs, the painkiller’s dose must be reduced.
A popular standard for exchanging data among devices is the Data Distribution Service (DDS). The standard is rich and complex, typical of those produced by the Object Management Group. But among its virtues are an ability to specify how often you want data from a particular device. OpenICE uses DDS, among many other systems.
In short, the frequency and accuracy of data collection should be configurable. As patterns of human behavior are better understood, devices may become even more responsive to the contexts in which they are needed.
Even before the current move to standards, Capsule Tech managed to get devices to talk to EHRs through the grueling effort of interpreting the inputs and outputs of each system and crafting protocols to make them work together.
Started in 1997, the company has recently expanded from merely sharing data to developing useful tools based on data, such as alerts and a modest amount of analytics. Some of these tools demonstrate a kind of adaptability reminiscent of a human-agent collective.
For instance, alerts are crucial in any hospital environment, but notorious for crying wolf–90% can be false. In addition to sending data to the EHR, Capsule’s SmartLinx’s Medical Device Information System sends near-real-time alarm data to its Alarm Management System. This helps hospitals manage their alarms, in line with the Joint Commission’s National Patient Safety Goals.
SmartLinx does not suppress any information, but when reporting it through the Alarm Management System to the clinician’s mobile device, includes some context to help the clinician decide whether the alert needs a response. Some context involves basics such as who, where, when, and which device was activated. Other context can consist of physiological data such as the patient’s heart rate and how long the alarm has been sounding.
Additionally, to provide actionable, timely information that aids in human decision making, Capsule has built an early warning scoring system application that uses vital sign information to calculate an immediate general health status score for patients and to identify those likely to deteriorate. The application also guides the care team through appropriate actions. This may be the beginning of an intelligent, integrated health system.
Computer Systems Must Be Sensitive to Bad Input and Failure
An unfortunate tenet of human-agent collectives is that agents can’t be trusted. The most basic example is system failure. If you don’t hear from a device, does that mean the patient is fine or that the device’s battery has run out of power? DDS offers a handshake or heartbeat, the common way for distributed computing systems to determine whether part of the system has gone bust.
Provenance is another requirement for collaborative environments. This means recording when a measurement was taken, and what person or device was responsible. There must also be ways to protect against data that arrives late or is assigned the wrong timestamp. When data is entered by humans, errors can be assumed as a matter of course, even in something as simple as spelling the name of a medication manufactured by your company.
More subtle is input from inexact devices, and worse still is the potential for malicious manipulation. I heard of instances where people who got rewards by their employers for reporting exercise put their fitness devices on their dogs. Using analytics, a health care system should be able to tell that a series of sudden 20-mile-per-hour rushes interrupted by inactivity are not a human activity.
Ethical and Technical Considerations
Lots of issues come up as simple human-computer interaction evolves into collaboration among agents. I’ve already mentioned error detection and provenance. Other issues include flexibility in computers taking or relinquishing control (agile teaming), legal responsibility, providing each agent with the right incentives, considering when to engage the user’s attention (instead of taking action behind the scenes), and offering the proper interface to do so. Connected health is a deep concept offering a lot to explore, and technologies will get better as we understand more of it.