Defining the Point of Care Market
It’s useful to segment and analyze markets for developing company and product strategy or analyzing competitor’s actions. Such an exercise helps illuminate why companies and markets do what they do – and what they might do in the future. In getting ready for this year’s HIMSS in Orlando, I’ve been thinking about the point of care (PoC) market. At the first Medical Device Connectivity conference in 2009, I defined the PoC market as the workflow and data associated with direct patient care in nursing units, the ED, surgery and related areas. This contrasts with EMRs managing orders, diagnostics, capturing charges and generally documenting things for the medical/legal record. (You can download a PDF of the presentation here.)
Many devices and software applications used at the PoC are FDA regulated medical devices because they are directly used in the diagnosis or therapy of patients. Because the PoC is where direct patient care is delivered, most PoC solutions meet the FDA’s definition of a medical device. Imagine a layer cake:
- The bottom layer is the patient;
- On top of that are patient attached medical devices;
- Next up are software applications like alarm notification, clinical decision support systems and messaging middleware; and
- Finally, the top layer is the EMR
The PoC market is bound on one side by medical device manufacturers, most of whom still think of themselves as box makers, and on the other side by EMR vendors who can get plenty clinical, but are repulsed by the prospect of being any more regulated by FDA than they already are (e.g., blood bank, PACS, LIS).
- RTLS – tracking the locations of patients, staff and assets;
- Patient flow – visibility and workflow automation for bed turnover and capacity management;
- Nurse call – supporting the communications and interaction between patients and caregivers;
- Messaging middleware – rules driven messaging and workflow automation;
- Unified communications – telephony and text messaging;
- Medical device data systems (MDDS) – acquisition and management of medical device data; and
- Data aggregation – the collection, organization and presentation of complex data optimized over time.
These days I would add clinical decision support systems for things like tight glycemic control or diagnosing sepsis. One could also argue that meds administration is also a part of the PoC market. This is far from a perfect model, and there are other messy details. For example, some part of a CPOE/infusion pump interoperable solution would fit as PoC software and (I’m expecting) will be FDA regulated.
These segments can be further divided into enabling technologies and workflow solutions. Enabling technologies are characterized by their specialized functions – RTLS for tracking locations, unified communications for voice or text communications, MDDS to acquire and manage medical device data for use by other systems, and nurse call for the call and response between patients and staff.
Enabling technology solutions tend to fall into two groups. The first group is made up of horizontal market vendors that sell enabling technology into a variety of markets – think RTLS and unified communications. These horizontal market vendors have no problem being commodity suppliers, competing on a narrow set of specifications and price. The next group is more focused on health care, e.g., MDDS and nurse call. While they may server other vertical markets (e.g., nurse call including corrections and education vertical markets) a critical mass of health care specialization limits horizontal market opportunities. In an effort to avoid the commodity status embraced by horizontal market enabling technologies, MDDS and nurse call are working to move up the value chain by extending their solutions to include workflow automation.
The workflow solution market segments facilitate the initiation and successful completion of certain tasks. Patient flow solutions aim to improve resource utilization in the ED, surgery or house wide. Emphasis may be placed on providing visibility, bed or room turn over, or more sophisticated resource planning or interfacility patient transfers. Data aggregation takes data from a variety of sources (EMR, diagnostic systems, medical devices, etc.), organizes and presents the data that often changes over time. Currently most of these systems are procedure based, like LiveData or Carrot Medical. Messaging middleware systems can leverage data on location, physiological data (diagnostic, therapy and monitoring), and care delivery data (nursing vigilance, orders to be fulfilled, coordination of care, etc.) to automate a wide variety of workflows. Some of the value propositions for messaging middleware include: alarm notification, critical test results reporting, clinical decision support to guide diagnosis or therapy, patient transport, patient flow… really, just about any workflow at the PoC can be addressed by messaging middleware.
Another interesting characteristic of the PoC market is the potential for a common architecture made up of the following components:
- Rules engine,
- Event processing engine,
- Messaging engine,
- Integration engine (for HL7 and other standards),
- Dashboard engine (for generating much of the user interface). and
Not every product in the PoC market uses this architecture. Enabling technologies that don’t automate workflow may look completely different. Also, older workflow automation solutions may have purpose built workflow automation software.
A final shared trait among PoC products is their focus on things found at the point of care: patients, medical devices, caregivers, techs and clinicians. Because of this and the preceding characteristics, at some point in the future the market segments that make up the PoC market will start to collapse into one market and a new category of enterprise software will begin to emerge.
The PoC market is a crowded one. I’m presently tracking almost 100 PoC companies:
- RTLS – 11,
- Patient flow – 24,
- Nurse call – 25,
- Messaging middleware – 18,
- Unified communications – 7,
- MDDS – 17, and
- Data aggregation – 3.