The recent recall (links below) for McKesson’s Anesthesia Care system raises interesting questions about potential information system failure modes as well as what system/software functions cross the imaginary line between unregulated EHRs and regulated medical devices.
First the facts. The FDA announced McKesson’s voluntary recall of its Anesthesia Care system in several on-line (here, here and here) postings. This trio of postings is interesting because the first links only to the second, the second does not link to either of the other two. The third also does not link to the other two, and was not part of any of the announcements, but it is the most complete.
The statement of the reason for the recall is that, “There was an occurrence where the patient case data did not match the patient data when the case was recalled in the anesthesia care record (ACR) in that it included data from another case.” It was further noted that, “Use of this affected product may cause serious adverse health consequences, including death.” In the third link the FDA identifies the product as,
“…a computer based system which collects, processes, and records data both through manual entry and from monitors which themselves are attached to patients, such as in the operating room environment. The system provides clinical decision support by communicating potential Adverse Drug Event alerts proactively during the pre-anesthesia evaluation and at the point-of-care. The system is generally indicated in the anesthetizing environment when the anesthesia provider decides to perform a patient assessment, to generate a paper and/or electronic record of the administration of anesthesia to a patient, and to document care.”
At this recall posting, the FDA identified the cause of the data mix-up as a software design problem. In response to my inquiry to McKesson for additional information on this matter they referred me to www.fda.gov which is not exactly helpful since this is, of course, the FDA’s main home page.
The kind of misfiling of patient data seen here is an often identified potential problem of all patient data systems including EHRs, or EHR-like products. Related problems are patient data simply getting lost (as opposed to e-filed elsewhere) or garbled/changed. An example of lost is an earlier McKesson recall of an imaging archiving system in which when merging two patient records into one the resulting patient record, “…is missing the Contrast Allergy information for the second patient record,” i.e., part of the data disappeared. Examples of changed are included in my recent discussion of two reported EHR errors in which an entry in inches was converted to centimeters, and 2.5 entered the record as 25.
The McKesson Anesthesia Care recall was determined by the FDA to be Class I which by definition means that there is, “…a reasonable probability that the use of or exposure to a violative product will cause serious adverse health consequences or death.” Violative here expressly means that the device is not in compliance with the laws and regulations administered by the FDA. Presumably a system cannot be violative unless it is in fact a medical device that was subject to these laws and regulations in the first place. This then raises the interesting question of what made this system a medical device as compared with other EHR or patient record products that are not being regulated as medical devices. In this regard McKesson’s explanation of what the McKesson Anesthesia Care system is that it is an “Anesthesia Information Management System (AIMS) that streamlines anesthesia preoperative and intraoperative workflow. This anesthesia information management system supports fast, accurate clinical documentation and helps to reduce the risk of medication errors.”
Besides the recall, that the McKesson Anesthesia Care system is a medical device is further illustrated by the fact that at least Version 15.0 was brought to market under the FDA’s 510(k) process. According to the FDA 510(k) record it was cleared in April, 2012 under the product code BSZ, Gas Manchine, Anesthesia. What is not in the public record is how this route to market came to be, or whether there were earlier versions that were not FDA cleared. In this regard some version of McKesson Anesthesia Care was available as early as 2008, as noted here. The Gas Machine designation is also curious since McKesson does not actually provide the gas machine but only the information system. Unfortunately the 510(k) record does not include the usual 510(k) Summary which would provide some more details. This lack of a Summary is a deficit, and an inadvertent one I have been told, in the FDA 510(k) database in the time period.
So this information system is a medical device, but why? One reason may be that it functions as an accessory to a specific medical device, the gas machine, and accessories to medical devices are generally regulated with the same classification as the underlying device. The ability of the system to interface directly with monitors for data gathering may also play a role here as compared to the more common EHR-type product in which data is primarily entered by the human operator. If this is the case, then there might be interesting questions with respect to current efforts to have a variety of medical devices “communicate” directly with the EHR, which makes it begin to sound like a Medical Device Data System (MDDS) which is a regulated medical device. However MDDS’s have restrictions that might put such functionality beyond that of an MDDS. That the McKesson Ansesthsia Care system also provides Clinical Decision Support (CDS) might also influence its status as a medical device. Although the FDA clearly regulates some CDSs, it has yet to declare that it can, should or will regulate all CDS. CDS is another overlap with EHRs which are mandated by Meaningful Use (MU) to provide CDS and yet EHRs are not regulated as medical devices. Note that the ONC created certification of EHRs for MU purposes is far different from FDA regulation based on it’s safety mandate.
That this recall happened at all is another factor in the medical-device-or-not story. McKesson is said to have communicated directly with its customers with a Clinical Alert, and such communication is certainly a good thing. However a “clinical alert” is not necessarily a recall, and other information system providers might not be so diligent.
Mixed terminology can also cause confusion when such information reaches the end user. The official status of recall, in my opinion, raises the ante above that of other forms of voluntary communication. At the least it creates a public information stream, which is how I found out about it, which transcends the immediate issue to include general elucidation of the potential problems of patient data systems. Also on the subject of public information, I did not find anything on this alert/recall at McKessons’s website which, unfortunately, is not uncommon for other manufacturers and recalls. I suppose one could argue that if you aren’t a current customer you don’t need to know about it, but I don’t find that argument satisfactory.
This recall also re-raises the question, at least for me, of which patient data systems are or should be FDA regulated. This in turn reminds us that such regulation is not just a market gate-keeper function but also involves design controls, quality systems, postmarket surveillance, complaint handling, mandatory adverse event reporting (MDRs) , public disclosure –and of course recalls, all of which are or maybe absent in unregulated products.
The HIMSS conference is so big, with so many different kinds of attendees and exhibitors that it’s almost impossible to have one big theme for any given year. Yet the question of theme for any given HIMSS is something we all talk about. The themes one perceives are at least partially defined by our own interests and area of focus. Consequently, the #HIMSS14 themes for me were:
Two of the market segments that I track with big shifts in value proposition were medical device data systems (MDDS) and messaging middleware. We’ll talk about specific shifts in a moment, but I think it worthwhile to consider why this change in value propositions has occurred. One obvious factor among MDDS vendors is acquisitions. Capsule Tech (registration required), Accent on Integration and iSirona have all been acquired. Acquisitions are major events when everything about a company is reevaluated in an effort to wring greater value from the acquired company. The other factor I think is the growing adoption of MDDS for clinical documentation into EMRs may have caused sales growth to temper a bit, causing vendors to look beyond clinical documentation and explore for ways to add value and differentiate. Let’s look at some examples.
Capsule Tech has released a new version of their Neuron device and transformed it into a vital signs monitor (pictured right). I’ve explored the virtualization of medical devices before in past conference presentations. This is where the core functionality of the traditional medical device is reduced to its essence and combined with an off the shelf computing platform. Imagine an ultrasound transducer, spirometer or EKG leads with a USB connector. Such products are delivered with software that runs on a laptop or desk top computer, tablet or smartphone. Simply install the software and plug in the sensors via the USB connector, and you have a fully functional medical device. (A more technical description of this may be found in this paper, from the Intel Technical Journal, published in 2006.)
Capsule has taken the general purpose computing functions that make up most of a conventional embedded system device and implemented them in the Neuron. Next they’ve taken sensors with miniaturized electronics that acquire and process the sensor data and convert it to a standard USB interface. Plug a temperature probe, SpO2 sensor, non invasive blood pressure module and similar sensors into the Neuron, and you have the new SmartLinx vital signs monitor, part of Capsule’s medical device information system. This new approach allows sensor vendors and Capsule both to add value at the expense of conventional vital signs monitor manufacturers.
In addition to SmartLinx, Capsule showed a new terminal server called Axon with power over Ethernet and Wi-Fi connectivity, and what they called “clinical analytics.” Capsule’s clinical analytics, really a clinical decision support system, is presently targeted at identifying patients with a deteriorating clinical condition and diagnosing patients with sepsis.
Accent on Integration (AoI) was acquired by Iatric Systems. AoI has extended their value proposition beyond MDDS and clinical documentation to include infusion pump interoperability whereby their software will be used to program infusion pumps based on orders from CPOE and pharmacy systems. This is one of the first pump interoperability solutions to come from a third party (i.e., not from a pump or EMR vendor). Iatrics is using Meditech’s proclivity to avoid systems integration to enter the pump interoperability market.
Nant Health is a health care IT and medical device company created by serial entrepreneur Dr. Patrick Soon-Shiong. The company’s atypical product portfolio ranges from mHealth to revenue cycle management. Since iSirona was acquired by Nandt Health, the company has received FDA clearance and brought to market an alarm notification solution for acute care. This pulls iSirona squarely into the messaging middleware space.
The company also showed HBox, a new terminal server and connectivity hub with a similar design and capabilities of Qualcomm’s 2net. The HBox includes wireless connectivity via Wi-Fi and a proprietary radio in the Sensium wireless sensor package from Toumaz (what they call a “sticking plaster” in the UK). It appears that Nant Health will be selling the Sensium into the acute care market as a means to identify patients with a deteriorating clinical condition. The HBox will be used as a gateway communicating with the Sensium device and connecting it to the enterprise network, and later HBox will be used to provide connectivity in patient homes.
Besides the changes at the MDDS acquisitions above, similar moves up the value chain away from conventional MDDS solutions are wide spread.
In the recent past the MDDS market was dominated by the acquisition of medical device data to populate flow sheets in EMRs – an important but basic enabling technology for higher value activities like alarm notification, clinical decision support systems and other tasks more directly related to patient care and outcomes. After just a few years – lightening speed for the health care market – the MDDS market is undergoing major changes.
Geoffrey Moore’s, Crossing the Chasm, is my favorite market adoption model because it fits health care technology markets so well. At this year’s HIMSS, I was struck by a parallel. Much like the bowling alley strategies described by Moore, what is called the messaging middleware market is driven by a variety of spot solutions. With Moore’s model, once sufficient bowling alley strategies have succeeded, the market enters the tornado where a brief period of rapid adoption occurs where buyers shift from the early adopters to the much larger early majority of the market. These spot markets for messaging middleware all revolve around facilitating communications and automating workflow. Examples of spot solutions include:
These spot solutions match a series of pain points for health care delivery organizations. Various messaging middleware vendors target one or more of these pain points with spot solutions. Since HIMSS14, I’m up to 25 companies that I track in messaging middleware. The product architecture and capabilities of these different company’s solutions are very similar, if not virtually identical. Yet few of these companies see more than a hand full of competitors in their sales efforts. This is because different companies are targeting different sets of pain points with spot solutions. These spot solutions can exist in customer sites as separate systems or they may be integrated to provide different capabilities to the same sets of users.
At some point the market is going to start to swing from spot solutions to enterprise solutions. Much like the transition experienced by Emergin years ago, buyers are going to wake up and recognize they’re buying multiple spot solutions that are technically very similar for their various pain points. The question will arise, “Why can’t we meet these various needs with one solution rather than having to buy one for each problem?” At this point, messaging middleware companies will start to recast themselves as enterprise solutions able to address a wider variety of pain points.
As manufacturers continue to draw outside the lines of conventional market segments, the challenges increase for buyers to select solutions that will serve them for more than the short term. Hospital buyers must complete rigorous requirements assessments to enable a meaningful assessment of competing solutions. And manufacturers will have to stay close to the pain points of buyers if they want to drive sales.
The best I could tell population health is something enabled by health information exchanges, or something. It seems vaguely like what the NSA does with our phone calls, smart phone apps, locations, email, webcams, Twitter, Skype, Facebook, Google, etc. Is there real value in all this? The NSA seems to think so. But I wonder if a panopticon of electronic health care data will be any more specific, sensitive or cost effective than conventional double blind clinical trials. Robust clinical trials are not cheap, but then extending the surveillance state to health care won’t be cheap either.
This blog post is part of the #HIMSS14 Blog Carnival #4, Looking Back at HIMSS14. Be sure to check out the carnival to see what other HIMSS14 Social Media Ambassadors though about this year’s event.
Finally, I’d like to thank the folks at HIMSS for letting me attend this year’s event as a Social Media Ambassador. I hope people got something from my tweets during the conference, and this wrap-up blog post.
I wrote in the beginning of 2012 that perhaps that year was the year for mHealth to ‘breakout. ‘ I cited several proclamations and organizational activities to support that claim. mHealth and the use of remote monitoring as an integrated healthcare offering is still not as prevalent as one would think it would be two years later. Even in the Telemedicine & E-Health LinkedIn Group, one sees angst at the low adoption rate of the use of telehealth solutions. Inevitably, when I speak with my colleagues and other people involved in healthcare, economic and clinical effectiveness questions prevail. Two specific conversations I had with clinicians stand out. In one, the cardiologist had not seen enough evidence that the quality of care and cost would justify a large addition or change to the existing healthcare offerings. In another, the clinician reminded me that with chronic diseases, one is attempting to get patients to change their behavior, which is very difficult, regardless of any technology involved.
With the above in mind, I’d like to offer the following results from the Renewing Health (RH) project in Europe, a randomized control trial which endeavored to compare the use of remote monitoring technologies and workflows with traditional workflows in the management of chronic disease in both economic and clinical terms. While the final results of the whole study are due out this summer, Veneto, Italy, has presented their findings for congestive heart failure (CHF) and they are fairly impressive.
Veneto, Italy, had to redesign their clinical workflow to accommodate a telehealth center which functioned as a data aggregation, filtering and analysis point for the data flowing from a patient home. This telehealth center then interacted with the patient, emergency services and clinical personnel based on a set of ‘clinical rules’ regarding the data received. This helped to alleviate data overflow and false alarms sent to the clinician and only ‘actionable’ information was forwarded when clinical intervention was needed. This also helped to gain the trust of all parties in the study; patients felt they were being monitored appropriately; clinicians were notified when it was truly necessary for them to intervene, and yet they could retrospectively review the data if required; and, emergency services were called appropriately and also were able to retrospectively review data if necessary.
After adopting this architecture and workflow, Veneto, Italy had the following results from their pilot study. Economically, their traditional healthcare model cost 4.72 Euro per day, whereas the remote monitoring healthcare model cost 3.47 Euro per day for a cost reduction of 16.5%. The clinical outcomes really improved with a 35% reduction in CHF hospital admissions, a 42% reduction in the number of specialist visits for CHF and a 32% reduction in specialist procedures for CHF. These are excellent results and Veneto will be using this model as their standard of care for future management of CHF patients. One of the main keys to attaining these results was the re-engineering of their workflow architecture to include the telehealth center in the middle of the data flow. For a more detailed view of these results, you may go here.
Additionally, the RH results will be forthcoming regarding Diabetes and Chronic Obstructive Pulmonary Disease (COPD). A follow-on project which is studying remote monitoring for chronic diseases called United4Health is requiring a standard system architecture of the pilot sites as well as ensuring remote monitoring workflows are part of the standard of care for the pilot site. It is not a randomized control trial, so the power of the results as compared to RH will probably not be as high, however, the insistence that the remote monitoring workflow be a part of the offered services and not a ‘one-off’ will be of value for the study of the ‘normalization’ of remote monitoring technologies in the standard of care for chronic diseases.
To contrast, the results above from RH are in complete contradiction to the general results from the Whole System Demonstrator (WSD) Project which finished up in early 2013. The conclusion of that study stated that “Telehealth does not seem to be a cost effective addition to standard support and treatment.” To be fair the WSD results were for all three chronic diseases of CHF, Diabetes and COPD. It remains to be seen if the RH combined results will be similar. Nevertheless, for CHF, it seems as though remote monitoring can be a better approach both clinically and economically for disease management as long as the system architecture and clinical workflows are designed to facilitate the proper interventions.
As an aside, from a clinical engineering viewpoint, it is interesting to note that Veneto outsourced both the telehealth center and home monitoring functions. If you drew a vertical line at the output of the telehealth center, that would be where the Veneto healthcare organizations interfaced with the rest of the remote monitoring architecture. With other pilot sites, they only outsourced the home monitoring function, so the healthcare organization provided the telehealth center functions of aggregating, filtering and analyzing the remote monitoring data. This interface point and function decision is important in the context of what parts of the telecommunication and function infrastructure does your healthcare enterprise wish to control and is a prime example of what was discussed in the previous blog post on mHealth.
Disclaimer, I am involved in the Renewing Health (RH) and United4Health projects as a technical manager of the industry advisory board. In that role, I worked with the pilot sites to document their system architectures and identify any issues with which industry could assist them. You can find details in the system architectures and technical issues at both the beginning and end of the RH study here. United4Health is in its beginning stages and the public documents have not yet been released. Nevertheless, the website listed above will contain those documents as they are released over the length of the study.
Introduced in the House back in October was the wittily named Sensible Oversight for Technology which Advances Regulatory Efficiency Act of 2013 which has the acronym SOFTWARE. Not to be outdone on the creation of legislative acronyms, now comes the Senate version with a bill entitled Preventing Regulatory Overreach To Enhance Care Technology, which of course gives us PROTECT. Both of these bills seek to define and sub-define medically related software, and then to take part of what they have defined away from the FDA, and do something else with it that has not yet been clearly identified.
The premise of these bills is that the FDA inhibits entrepreneurs by peskily requiring, at least in some cases, that the developer meet regulations that are supposed to provide some measure of safety and efficacy before these products are used for or by the public. These issues arise in part because the definition of a medical device does not explicitly include or exclude software. This has allowed the occasional debate about whether and what kind of software is or is not a medical device. The FDA’s position is to simply look at the function of the software and the definition, and then to say that if what the software does meets the definition then it is a medical device. Debating this with the FDA is typically not a fruitful endeavor. Some other countries have explicitly included software, presumably to try to end the discussion. For example the UK explicitly includes “software” in its list of the multiple categories of things that may be a medical device.
We have of course seen this theme played out before in the form of the FDA’s regulation of Medical Apps which is now manifested in the Medical Mobile Apps Guidance for Industry and Staff, and the associated mobile apps web presence. The FDA has sought to define what kinds of apps are or are not medical devices, and among the latter which the FDA would focus on using its regulatory discretion. It is worthwhile remembering here that Guidance Documents are not regulations but instead reflect the FDA’s “current thinking”, and that the FDA can adjust its thinking on these matters relatively easily. On the other hand, codifying such distinctions in legislation is a far more rigid and potentially slower enterprise, and if bills such as SOFTWARE and PROTECT are ever passed it would be relatively hard in today’s environment to modify or undo what they do if that proved necessary or desirable.
Both SOFTWARE and PROTECT offer definitions of ” clinical software” and “health software” that seek to distinguish them from other types, notably software that directly drives what is generally understood to be a medical device. The SOFTWARE bill also defined “medical software” as software that (1)(A) is intended to be marketed to directly change the structure or any function of the body of man or other animals; or (B) is intended to be marketed for use by consumers and makes recommendations for clinical action that (i) includes the use of a drug, device, or procedure to cure or treat a disease or other condition without requiring the involvement of a health care provider; and (ii) if followed, would change the structure or any function of the body of man or other animals; (2) is not software whose primary purpose is integral to the functioning of a drug or device; and (3) is not a component of a device. Having provided this definition the act removes such medical software from the definition of a device, but then assigns such software to CDRH to regulate it in the same manner as a device. Exactly what this accomplishes eludes me.
Focusing now on the more recent PROTECT bill, clinical software is defined as “decision support software or other software (including any associated hardware and process dependencies) intended for human or animal use that ‘‘(A) captures, analyzes, changes, or presents patient or population clinical data or information and may recommend courses of clinical action, but does not directly change the structure or any function of the body of man or other animals; and ‘‘(B) is intended to be marketed for use only by a health care provider in a health care setting”. One key factor here seems to be that it does not directly effect the body, presumably meaning that the effect is mediated through the human healthcare provider. This falls into the general category of software whose errors are not of direct consequence because the clinician is supposed to catch any such errors before they reach the patient. In standard risk management parlance this allows severity and frequency of the hazard to be offset by detectability, i.e., if the hazard manifests itself the clinician will prevent the hazard from causing harm. Of course the theoretical ability of the clinician to second guess the explicit or implied advice provided by the software is not the same as this actually occurring.
Heath software is defined as “software (including any associated hardware and process dependencies) that is not clinical software and ‘‘(A) that captures, analyzes, changes, or presents patient or population clinical data or information; ‘‘(B) that supports administrative or operational aspects of health care and is not used in the direct delivery of patient care; or ‘‘(C) whose primary purpose is to act as a platform for a secondary software, to run or act as a mechanism for connectivity, or to store data.” I find this definition more cryptic than the one above. A key exclusion here appears to be not used in the direct delivery of patient care, although this begs the question of how remote from patient care it has to be in order to qualify.
Both clinical and health software are further constrained by the limitation that they do “not include software ‘‘(A) that is intended to interpret patient-specific device data and directly diagnose a patient or user without the intervention of a health care provider; ‘‘(B) that conducts analysis of radiological or imaging data in order to provide patient-specific diagnostic and treatment advice to a health care provider; ‘‘(C) whose primary purpose is integral to the function of a drug or device; or ‘‘(D) that is a component of a device.’’. Clause A would appear to exclude patient used apps that provide diagnostic information based on information that the patient provides either manually or otherwise. The imaging limitation is interesting because it seems to distinguish imaging clinical decision support from other kinds of such support, implying that there is greater risk in the former than the latter. I do not know if there is any evidence for this.
Given all this, the PROTECT bill then removes clinical and health software from the purview of the FDA. One thing to be analyzed here is whether the new definitions draw clear and unequivocal lines within the medical software space. The answer is probably no. Secondly, even if it did, does deregulating what is defined here as to be deregulated serve the public health with respect to a reasonable level of assurance of well designed and reliable software. Assuming that FDA regulation has merit for medical devices in general, these exclusions are not likely to be fully rationale, or to improve upon the current regulatory flexibility that the FDA currently has and exercises.
Whether anything more is heard from these bills remains to be seen, especially since our current congress has not demonstrated its ability to consider and pass much legislation.
Pictured with this post is U.S. Representative Marsha Blackburn, sponsor of the SOFTWARE Act.
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 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).
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:
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: