I was listening today to the CE-IT Webinar on CE and HIT from the 2014 AAMI conference in Philadelphia. Much of the session reviewed what has happened over the last five years and it got me thinking about my experiences and what I’ve seen over the last ten years in medical device connectivity and remote monitoring. It’s been an interesting ride and yet I realize there are a few basic ideas that have resonated over the years. These basic ideas are:
Ten years ago, I was working for a very large integrated healthcare system as a clinical engineer. One of my projects was to choose and implement the medical device integration system for integrating patient monitoring and ventilator data into the ICU charting portion of our EMR system. There were three main vendors at the time which weren’t part of the large medical device companies and eventually we chose one of the major ones for the system. My responsibility was to ensure the device data went from the device at bedside to the device integration server and out to the interface broker to the EMR application.
While choosing the device integration product, I had to keep in mind my healthcare enterprise infrastructure. I had thirteen hospitals that needed to connect to the two separate instances of the EMR application. Being able to standardize on the device integration system implementation design and management became one of my paramount concerns as I needed to be able to scale the solution over the infrastructure. Additionally, I knew that if I was successful in that particular region, the solution would need to scale over to other regions and nationally.
During that time, I also was involved in some of the organizations promulgating the use of standards at the medical device integration system/interface broker interface. The standards organizations wanted me to include the standards as requirements in my procurement documents. And yet, I resisted because I did not see the standards as either being mature enough or being overly burdensome requiring adherence through all layers of the OSI 7 layer model.
In retrospect, I believe I should have insisted on the use of at least the data standards from the devices embedded in the messaging standards (HL7). We were using HL7 at the output of the device integration server, but the EMR application separately mapped each data item to a data base element and had to use the device vendors’ HL7 implementation guide to figure out what the data items meant. If we had specified IEEE 11073 device data standards (perhaps even later on as we evolved), we would have been able to more easily change medical device vendors in the future, if desired, and not have to worry about ‘breaking’ the interface to the EMR interface broker.
With regard to the other standards, physical, networking, etc., I’ve found that the IT industry does a good job of defining standards and then converging to an interoperable solution. Those standards are required across various vertical markets, so there is more demand for the convergence of the standards and products with those standards. What is unique to healthcare is the data and messaging information. And, that is what is most important to the clinicians and patients – consumers of the data. All of the other standards are mostly mechanisms for transmitting the data from where it is generated to where it is acted upon in some fashion.
I see the same thing happening in remote monitoring and mHealth. Buyers are too focused on short term and immediate issues and not realizing that specifying data standards can help them be interoperable in the long run. Again, not having to worry about the data format of another vendor’s sensor data being integrated into the EMR can save time and money as well as allow quicker scaling across your organization.
However, there are other players on the scene now, which may make the buyer’s job a bit easier. With ACA in the USA, the term meaningful use (MU) has led to the establishment of standards which EHR applications must use in order to be certified to allow the US government to reimburse some of the costs of EHR implementation. In fact, the first MU stage was going to include remote monitoring standards to include certain medical devices data (HITSP IS77), however, it was eliminated for that stage. It is anticipated that the last MU stage will require medical device interoperability. The original date for that was projected as 2015, however, the MU stage 3 has been postponed, so, that will most probably postpone the medical device standards identification for MU. Nevertheless, medical device interoperability requirements for MU which will specify medical device data standards will be coming in the near future to the USA.
In other countries, they are also using government to select and mandate data and messaging standards for remote monitoring. The Danes have issued a reference architecture which specifies Continua guidelines for remote monitoring solutions to interact with their national health network and EHR. Norway, Sweden and Finland may follow Denmark. The EU has many projects it has funded which have recommended the use of interoperability standards for remote monitoring. These recommendations usually have been using products that adhere to the Continua Guidelines and/or specific IHE profile conformance. It is no secret that the underlying standards in those guidelines and profiles are very similar. For medical device data it is IEEE 11073 and for messaging it is HL7.
Industries outside the normal healthcare market are responding as well. The mobile operators are very keen to be involved in the healthcare market and ‘disrupt’ it. They have a unique proposition in that they have a one-to-one relationship with their customers and have developed back-end business infrastructures and processes which facilitate that relationship. Moreover, they have managed to build their customer base from ~1 million to ~7 billion worldwide by identifying and enforcing standards adherence beginning with the 3G/PP initiative (which started in 1998, the same year HL7 was started!).
Examples of required standards for 3G/PP include transmission protocols, security requirements (encryption), and user identification (uniqueness). Basically the mobile operators do not allow a handset that does not adhere to the standards to connect to their transmission network. In another example, mobile operators wanted to be able to sell services for images and required that all handsets have cameras and adhere to specific image data standards. It is nigh on impossible now for someone to purchase a handset without a camera and the proliferation of products and services that have sprung up for the management and sharing of these photos is phenomenal. This is due to the mobile operators insisting on data standards for a specific use. Because the standards were specified and enforced, interoperability soared and market penetration and size soared as well.
With that in mind, it is also interesting to note that the most recent handsets have integrated sensors in them which lend them to being used in mHealth applications. The Samsung Galaxy has a 10 sensors built in; a gyro, barometer, fingerprint, hall, accelerometer, heart rate, proximity, RGB ambient light, gesture and compass. Each of these can be used individually or in a combination to measure or provide remote monitoring in a healthcare sense.
In addition, with the use of short range networking (BTLE, ANT, NFC, etc), other sensors can use the mobile handset as a ‘ramp’ to the network. The ‘wearable sensor’ market depends heavily on mobile handsets for data display, computation and network transmission. As before, the mobile operators could require that medical device sensors adhere to certain standards or they will not allow the handset to use the transmission infrastructure.
Other developments have occurred with the handset manufacturers and other technology companies. All of them have announced some type of health data aggregation product with development kits for entrepreneurs (Apple Healthkit, Samsung Digital Health Initiative, Google Fit and the ongoing Microsoft HealthVault). While several initiatives by some of the same companies have failed in the past, many believe now is the tipping point for involvement in mHealth. There is recognition that leveraging the now ubiquitous mobile telecommunications infrastructure to solve some of more pressing healthcare issues is a ‘no-brainer.’
Therefore, medical device connectivity (or medical sensor connectivity) is becoming more prolific and will most likely end up being more extensive outside the currently controlled healthcare enterprise infrastructure. It is imperative that at least data standards be specified and enforced at the different interfaces to ensure true healthcare data interoperability across all of the disparate infrastructures. Healthcare providers currently have a lot of control over this market, however, there are forces outside that will in the future define large parts of the market and may make it easier for the standards to be identified and enforced.
Pictured is the Vital Connect healthpatch patient worn sensor. The Vital Connect business model is based on the assumption that their product will be interoperable with a variety of gateway devices such as smartphones.
A while back I had the opportunity to chat with Todd Dunsirn, the CEO of True Process. True Process provides products and services to both hospitals and various manufacturers. The company is focused on the point of care market offering a medication administration solution and a medical device data system.
What was the genesis for starting True Process?
I started the company in 2004. I have an engineering background, and had several other companies doing IT consulting and then web development, and application development. Then I had a friend contact me to develop a bar-code point-of-care simulation so that sales reps that were selling infusion pumps could demonstrate the five rights process with the pump. So, of course he said, “Hey can you do this? It’s gotta be done in three months.” And keep in mind, I had never heard of bar-code point-of-care [chuckle] prior to this, so I’d really never thought about infusion pumps.
So I was on the road for weeks learning the technology, spent time in hospitals seeing how it’s used and developed this application. When it was complete, the client was just about to release their wireless suite of products and they said, “Hey, you’ve done all this research, why don’t you do the first installation because over the last three months you became the expert at doing this?” So I became the installation department and there was one site, then another site and it quickly grew from there.
It was apparent to me that, okay, there’s a need here. These medical device companies didn’t have the resources or core competencies on the IT side of things, in their companies right now, and that’s how it started. So we scaled up, and we had created a business out of this single opportunity. We made a conscious decision to just stay focused in healthcare, because it’s a unique industry and a unique space with regards to IT, and I didn’t want be bouncing around across vertical markets.
We’ve branched out in recent years with other companies and other technologies that are in healthcare. Right now we’re doing a lot of work in the RTLS (real time location system) space, with asset management and workflow studies based on the actual location of people and things. We’ve seen a lot of growth in that area, a lot of interest for what we do. So, it’s starting to be an interesting blend of technology now with medical devices and other things like RTLS.
Are these RTLS projects for RTLS manufacturers or are they for medical device companies that want their products tracked? Or are they for hospitals?
Right now we are working primarily with the RTLS hardware manufacturers and system integrators of these types of platforms. The systems integrators have a vendor neutral platform that can use RTLS hardware and provide a variety of tracking and workflow automation applications. Then they have a rules engine so they can trigger things based on location or how long a device or a patient has been in a certain location; they also provide analytics. These systems can do some really interesting workflow optimization and awareness things. So we’re working with a lot of companies like that.
True Process is pretty unique in that you work for both manufacturers and hospitals. Based on that perspective, what industry trends jump out at you?
The biggest that that sticks out in my mind is that it always feels like health care behind the times. It feels like it’s the last industry to try and catch up. Sometimes it feels like things are made more complicated than they need to be. A lot of medical device manufacturers look at wireless as this high-end premium feature when really in every other industry it’s a given that you have that. It’s not something that really should set you apart anymore. It should be assumed that every device is connected as wireless and can communicate. Another thing that jumps out is that there hasn’t been a lot of movement from the device manufacturer’s side, and there hasn’t been a lot of pressure from the buyer’s side to work towards some level of standardization with respect to how devices communicate.
We have all these standards going on with the EHR and health exchanges and all that, and that’s great. But when you look at the medical device side, everybody’s doing it differently. The messages are different. How they connect is different. The security is different. It’s baffling that in an industry where you can have devices that are recalled and unavailable, the vast majority of products are tied to proprietary messaging and wireless infrastructure.
Take the infusion pump manufacturers for example, and the recent product recalls. If you’re a hospital and you have this gateway and these devices and there’s a recall, you’re done. You’re not communicating or you can’t just get another manufacturer’s pump and put it in there because the messaging is all different, the platform’s all different. It’s like if you had to replace your cable modem or router in your house and you had to replace all your devices accessing the Internet. Nobody would ever do that. But hospitals and healthcare, they currently do that.
I think device manufacturers in general would benefit from some sort of standardization, because they’re all really trying to do the same thing. And I think what it would allow them to do is really just follow some best practices for connectivity and really put their focus on the functionality of the product itself and what it’s supposed to do, and how it’s supposed to deliver a medication or monitor a vital or whatever it is.
I don’t know how that’s going to change. I would think some of the large purchasing organizations would be able to really drive that. I’ve seen different initiatives to try to standardize the buying process of connectivity and say, “Hey, this is how we want to do things and it’s got to meet these requirements, and if it doesn’t, we’re not buying it.” They just haven’t taken that to the next step, and I don’t know where it falls in the priority list of things that hospitals are doing with the recent last few years of EMR integrations and changes, but I think as connectivity moves forward we’ll see that happen.
Tell us about your MDDS platform, ViNES. What is it and what are its capabilities? And do you sell it to medical device manufacturers, or do you sell it to hospitals?
Today in hospitals they have these 10 to 15 different device gateways that they have to manage for all these different medical devices devices, and the data’s all scattered into these separate gateways – or just streamed into the bit bucket. We saw this and thought about this for years. And we saw the need to develop a platform that is vendor neutral, where anything can connect to it, and it stores the data in a common format on a common platform. We use the standards that are out there, whether they’re ones from IHE or Continua Alliance or IEEE. We try to use those standards when we develop our database so that all data is stored the same way, so it can be accessed the same way.
As we got started, it became apparent that what we were developing was more then just a device gateway. It really developed more into an integration platform that included medical devices and other HIT systems. Take for instance, getting an ADT feed, getting vitals data. It doesn’t matter what the data source is, we can take that data and we can accept it and we can organize it based on the structure that we created. And then we wanted to make that data accessible through an interface that really allows hospitals or even a device manufacturer to access that data however they want, whenever they want in a known format that they can control. So that was really how we got started with ViNES, we looked at this vendor neutral device gateway platform.
What about ViNES sets it apart from other connectivity solutions and what do you see as important differences between connectivity solutions.
First, ViNES actually stores and organizes the data. So it’s not just routing data, it’s not just a serial-to-serial connection that’s getting data from the device and sending it to the EMR. We’re actually storing the data, so we have this whole data warehouse structure. The goal was to collect everything from every device, store it in a patient-centric way, and then be able to organize it by unit, or hospital or however you want. So that’s one of the unique things, it’s not just a connectivity engine, it’s a connectivity and data warehousing engine.
Everybody talks about big data and analytics, but this is mostly applied to data in the EMR and claims data – all abstracted and summarized data. If you look at how much data is generated at the point of care in a hospital just from devices, it’s staggering. It’s this full resolution physiological and therapeutic data that, when combined with the HIT data we have now, will really transform big data into a took with a transformational impact on health care delivery. And that’s why we created ViNES to collect all that data and organize it intelligently. Even if it’s not being used today that data in another year or two – just having access to it, you’re going to be able to do some very interesting things with it.
Also, we’re really tried to create something that is developed around current technology. We use a lot of open source technologies to keep current and to keep the cost down. Consequently, we’re able to approach the market with a very scalable and flexible licensing agreement. Take for instance, low census devices like intra-aortic balloon pumps, dialysis machines or, somebody that has five scales that wants to integrate them. Our approach to licensing can scale down to these small deployments to price ViNES so that it can be affordable in most situations.
In the future, ViNES is designed to be cloud based so we can host customer data on an Amazon cloud, and provide connectivity for somebody that didn’t want to have manage the infrastructure. The goal is to enable a hospital had ViNES, to be able to go onto a screen, select whatever device they wanted to connect, configure it, and be up and running without really any intervention from us. We’re also moving to modularize software as plug-ins and provide the ability to send data to a data warehouse where we really don’t have to be involved. And that goes back to the standards.
We’re not looking to create some sort of system where they have to pay a lot of money to get the data out of their platform. It’s their data, they should have access to it, and we think there are opportunities and growth in other aspects of developing the product other than charging them data access usage fees and things like that.
Unlike some medical device manufacturers I can think of.
That’s how the industry is, and we’re just trying to be different. We’re trying to shake things up, and the more we talk to hospitals, CIOs and people that are in charge of these efforts, you see the movement and the frustration. It’s like when are we going wake up and do things the right way and take control of this and demand solutions that meet our business needs, meet our cost structure, and are technologically done the right way.
That’s a great segue to my last question. What are the trends that you’re seeing in the connectivity market? Is growth increasing? Are we starting to peak because of the meaningful use roadmap? Are buyers getting better informed? Are they asking harder questions, or are they still just buying whatever their favorite vendor wants to sell?
I think medical device manufacturers are starting to really look at the value of a prospective connectivity solution. We’re working on several opportunities right now, two opportunities in the last week, where companies that are with a current provider had said the cost is just unsustainable. What I’m hearing it like, “This is great, but I’m not going pay all this money to do it just because I can. It’s got to mean something. And it’s got to fit into our strategy.” So that’s a trend that we’re seeing. You look at how much some of these connectivity systems cost, and that’s being driven by what they’re doing and also how the work is done. It seems like nothing’s really turnkey, and there’s a lot of time and a lot of effort to get things done. And I don’t know if that’s because of the technology itself or their design approach.
Take the core cost of a system – the software licenses and hardware costs – and now add on all this consulting and development time to get things working, and it can easily become a black hole of cost. With ViNES, we’re really trying to change that paradigm and to make it more efficient.
The final trend we’re seeing is a glimmer of recognition regarding the value of medical device data beyond clinical documentation in the EMR. Not everybody understands right now the value of this data. Everybody talks about big data, but few people know what they’re really talking about or what it really means or how it applies to them. This is true for both medical device manufacturers and the data their devices produce, and hospitals and the data generated from their patients. A lot of data now is used really in the short term. It’s used right away, but it’s not mined or analyzed to learn what really happened here, and what were the events that happened, and how this lines up to what was actually done, and the ultimate patient outcome. That’s just not happening now.
The photo above is from the True Process booth at HIMSS14.
The previous post in this series suggested a set of characteristics to define the messaging middleware market and described the typical product architecture for these systems. In this post, we’ll look at ways the market may be segmented and how the market is adopting these systems.
Market segmentation is the dividing of a broader market into subsets of potential buyers who have common market requirements who then become the target for your product, sales and marketing. Using my favorite market adoption model, Geoffrey Moore’s Crossing the Chasm, this is the bowling alley strategy. Software developers in the messaging middleware market are currently pursuing a variety of market segments or bowling alleys.
One high level way to segment the market is to draw a distinction between those messaging apps that target users within an enterprise, usually a hospital, and those messaging apps that target users outside of a single enterprise, typically physicians and/or patients and associated staff at various hospitals, pharmacies, labs and physician practices within a health care community.
Secure messaging, alarm notification and certain workflow automation solutions (routine tasks like bed turns, patient discharge, room turnover and patient flow, patient transport, on-call physician scheduling, etc.) are inherently enterprise-centric applications. For example, there is little demand to notify a user in one hospital of a patient alarming in another hospital. This contrasts with solutions intended for use by people that work across multiple enterprises.
Messaging solutions where physicians are the primary intended users are often characterized by workflows that span more than one enterprise. For example, physicians with admitting privileges at one or more hospitals who also see patients in ambulatory settings, e.g., physician offices or clinics, engage in communications that span multiple enterprises. In this ambulatory messaging environment the population of potential users – either who want to communicate with others or to whom physicians might want to send messages – is defined by the health care community.
We’re going to define health care communities in detail here because this impacts the kinds of messaging that may occur and because the community circumscribes the network effect (which we’ll talk about later). The health care community is made up of all the people and entities that deliver and pay for care within a specific geographical area. These people and entities start with physician groups, hospitals and their staff where the physicians have admitting privileges, local pharmacies, ancillary providers like physical therapy groups, diagnostic services like regional clinical labs, and payors.
The geographical boundaries of these health care communities are variable. Generally, the size of a health care community is defined by the distance a patient is willing to drive to see a doctor, receive treatment at a hospital or fill a prescription. Rural communities are, by necessity, geographically larger than suburban or urban communities. The practical distances for receiving service also varies by the type of health care community member; payors are state wide, regional labs and compounding pharmacies may also serve geographical areas that are larger than the typical patient is willing to drive for service.
By defining the health care community, we define the universe of potential actors engaged in communications, workflow automation and care coordination. This defined universe becomes the foundation for vendor’s market requirements and the features supported by their messaging solutions. Currently, most messaging solutions target a narrow portion of the health care community, either a subset of entities and users, or entities and users engaged in specific workflows like prescription refills, hospital bed management, or alarm notification. Prospective buyers and messaging product developers should define their needs and plans based on a thorough understanding of both their immediate objectives and how they fit into the broader health care community – eventually all of these separate tasks and products will be connected in some fashion.
In the blog post on HIMSS14, I noted that there are a lot of messaging middleware vendors competing for business (I’m presently tracking 100 companies) and yet they each tend to run into a very small number of competitors – a handful or less – on a regular basis. Within a broader market segment, the market can be further divided in subsets of potential buyers based on their pain-points, or the particular problem they want to solve. Hospital examples include:
Each of these needs represents a market segment, and each is currently populated by a small number of messaging solutions. Likewise, a different but similar list can be found in the ambulatory segment:
Another reason why messaging solution companies that are otherwise competitors don’t run into each other lies in how they are sold. These different go-to-market strategies result in a kind of de facto market segmentation. Let’s take the broad market segment of physician communications. Some companies sell this solution to individual hospitals and then pull in additional paying users through the contacts of that hospital’s physicians. Other companies start with large physician groups and then seek to pull in additional users in a similar way. A third approach is to go to the state or county medical society that credentials physicians and physician specialty associations. With the above examples competing vendors will likely not compete directly with companies going to market through different channels.
A final way to segment characterize messaging solutions is whether they are broad or deep. Messaging solutions with a broad focus support a very wide variety of users in most if not all of the entities and roles found in a health care community. This approach contrasts with deep solutions that include multiple detailed features that handle the communications and workflow requirements of a specific type of solution. The predominant example of broad messaging solutions is the secure messaging market segment. Companies in this segment are many, and include CellTrust, ConversePoint, Cureatr, Doc Halo, Global Relay, Imprivata Cortex, MD Chat, qlikSoft, TigerText and Zipit Wireless. Common features to these broad solutions include:
Companies in the deep messaging solutions segment include Amplion Clinical Communications, Ascom, Cardiopulmonary Corp., ConnexAll, Extension Healthcare, HealthFinch, Mobile Heartbeat, PatientSafe Solutions, Spok (was Amcom), Starling Healthcare (acquired by Hill-Rom), and Vocera. A few examples of deep solution features include the broad solution features, plus:
Almost every task and activity that occurs in the delivery of health care requires coordination between various actors such as physicians, hospitals and payors, pharmacies and their employees. These workflows are often multi-step, require more than one actor, and include interaction with one or more information system or medical device system. Virtually all of these workflows can be automated using a variation of the engine-oriented software architecture described in the previous post. Software developers have only started to scratch the surface.
For buyers market segmentation helps identify a group of potential suppliers based on the characteristics of your organization and what you’re trying to accomplish. A fundamental question for vendors is which market segments are the largest, growing fastest, and which adjacent segments could best be targeted to maintain or increase growth?
As dynamic and seemingly different many of the aforementioned market segments are, it is important to recognize that ultimately there are basic market needs driving the adoption of messaging middleware solutions. A byproduct of current efforts to increase automation has contributed to the market forces giving rise to messaging solutions. These root causes are manifesting themselves in a multiplicity of ways as buyer pain-points associated with market segments for which buyers seek specific solutions.
I have repeatedly heard from messaging solution providers that EMR adoption is sucking the oxygen out of the health care market for other types of solutions. Regardless of budget availability, people are just too busy implementing EMRs to do much else. Ironically, while many hospitals and physician practices are indeed fully engaged in EMR adoption, a consequence of this increased automation is bringing to light the need for improved communications needed to realize the full potential of EMRs. The following are a number of drivers behind this increasing need to improve communications.
It turns out that the use of EMRs themselves results in an increased need for better communications as various users work to orchestrate activities to successfully complete tasks that are documented via the EMR. Today, the EMR remains a retrospective medical, legal and financial record of the diagnosis and treatment of an episode of care. Over the past several years, the industry has worked to stretch the EMR beyond this evolving role to “automate” ever more of a clinician’s daily activities. As the HIT industry extends their value proposition ever closer to the actual delivery of care, there’s always a learning curve where vendors learn through their customer’s experience. A great example of the current state of this learning curve is CPOE.
A lot of the interaction, collaboration and communications between physicians and the caregivers and staff, who are expected to fulfill the orders generated in CPOE, is either not very well understood, or not addressed in current CPOE systems. The most current iteration of Order Entry, now called CPOE, often includes a clinical decision support system (CDSS). This CDSS is used to not just document and communicate the order, but to bring automation closer to the actual delivery of care – in this case, the thought processes a physician uses to write an order. The inevitable learning curve creates the need for new levels of communications that must be orchestrated and monitored if the tasks “automated” in the EMR are to be completed in a reliable and timely manner. Understand that I’m not bashing EMRs; none of us are omniscient. It’s just that the way things are working out is creating a market opportunity that a growing number of hospitals are spending money to fill.
Mobile messaging is also provided by many EMRs and a cursory look at those capabilities could lead a hasty hospital to conclude that a third party messaging solution is not needed. Enterprise software applications like EMRs are intended to be used by people in front of a display, mouse and keyboard. This is especially true with system generated alerts or messages – the user has to be in front of a client app to be able to receive any system notifications. Because health care delivery is inherently a mobile endeavor, few physicians, nurses or techs spend much time interacting with enterprise software. The mobile messaging or alerting provided by many EMRs only supports EMR generated messages. This alerting does not include the care coordination or orchestration resulting from the use of the EMR or communications requirements that are totally separate from the EMR.
In the ambulatory market, still mired in fax machines and phone tag, basic communications inefficiencies have been around for many years. Here automation trends, EMR and mobile device adoption, are driving the market, but in different ways. The advent of smartphones and texting showed clinicians a better way to communicate, and many took it – to a degree, patient care trumps HIPAA any day. Entrepreneurs saw the market opportunity for secure messaging and many start ups were launched in response (many founded by physicians). As in hospitals, spot solutions are also compelling to ambulatory market buyers as they look for solutions to specific pain-points around patient rounding, admission/discharge, avoiding re-admissions, and various types of patient communications.
This market is evolving like other markets in health care over the years. The market starts out with no experience buying or using messaging middleware, but recognizing they have specific problems or pain-points they want fixed. Early on, buyers don’t know how to properly define their needs and match those needs with the “best” solution available. They don’t know the questions to ask vendors, and often don’t understand the answers to the questions they do ask. This results in protracted procurement cycles that often seem to veer from non sequitur to non sequitur as buyers attempt to become confident with their purchase decision.
The risk for first and perhaps even second time buyers is investing in the wrong solution. Poorly understood needs, combined with selecting an imperfectly understood solution often results in a poor match between actual needs and the actual capabilities of solution. When this happens, unmet needs are just that and user adoption becomes a struggle, if not an impossible goal. Ultimately, the buyer must replace their initial purchase with a more suitable solution, or look for ways to fill those solution gaps.
Getting into something for the first time is a common experience and there is a body of thought that’s arisen around this common challenge. One’s knowledge deficit in these situations can be divided into a number of areas:
Both buyers and sellers can mitigate their risks by finding and using experienced resources who have already learned things the hard way. Without assistance, buyers are left to figuring things out on their own – often trying to finagle their prospective suppliers to educate them. The challenge for vendors is to not only sell their solution, but simultaneously, show the customer how to buy it. The term I’ve heard repeatedly is, “showing the customer the way.” To do this, marketing, sales tools and the sales process itself must be developed to accommodate both these objectives, selling and educating.
As markets become more educated and mature, the characteristics of the market change. Presently, many buyers are becoming aware of their needs to improve communications and automate workflow. Entrepreneurs tend to be highly skilled at identifying emerging market needs, and the existing market segments closely reflect the pain-points prospective buyers are seeking to ameliorate. As these market segments continue to emerge, disruptions can arise to complicate things for buyers and sellers both.
Market disruptions are factors that cause changes among buyers, sellers or both. Besides taking note of, and compensating for current disruptions in the market, it is important to anticipate and plan for future disruptions. One obvious potential disruption is the proliferation of messaging solutions. Over time within a health care community, individual users who overlap with various entities will be put in a position to install different messaging apps on their smartphone in order to communicate with the rest of their patient care team. The potential impact of having to use two, three, or even more messaging apps is something to consider. Does your message/worklist queue lose effectiveness when you have more than one? Will push messages or alerts appear on your phone regardless of what client is on the screen? How easy will it be to manage and respond to your message flow when it comes from multiple apps? It could be this will be no problem depending on what your role is, your message volumes and how your messaging apps behave. Or it could be that this becomes a big problem, rendering all or some of your messaging apps ineffective.
Another potential disruption might occur in the enterprise or hospital market. In this example, messaging solutions proliferate but the messages are all received and responded to through one smartphone app. This kind of proliferation – a systems of systems proliferation rather than a proliferation of messaging client apps – is occurring now. Currently a number of broad messaging solutions are partnering with deep messaging solution providers to fill in gaps in features desired by some prospective buyers. For example, TigerText partners with Amion (for on-call physician scheduling) and xMatters (for emergency mass notifications) to offer a more complete messaging solution. Another market leader, Imprivata Cortex partners with Amion, HIT Notifi (for critical test results reporting), and Extension and ConnexAll (for medical device alarm notification) for the same reasons. Were these deep market solution providers’ products designed with the intent of relying on an other messaging system for message receipt and response? What degree of verification and validation testing was conducted – using what specific use cases – for these deep market solutions to qualify as technology partners for the broad market solutions? At what point will the market start to demand all of these features from the same vendor? Likewise, when will some of these messaging solution vendors broaden and deepen their solutions eliminate the need for these partners?
Of course this system of system proliferation of messaging solutions isn’t necessarily limited to the hospital market. I’m sure any secure messaging solution targeting the ambulatory market would love to partner with a company like HealthFinch to include managing prescription refills into their overall messaging solution. Other specialized capabilities revolving around managing patients at risk for re-admission, patient engagement for chronic disease management, and providing structure to care team coordination. Whether in the hospital or ambulatory market segments, systems of systems proliferation remains both an opportunity and a potential problem.
Let’s not forget the perennial role of HIT vendors as spoilers for smaller niche solution providers as a future market disruptor. As noted earlier, EMR vendors already provide messaging to mobile devices for EMR generated alerts. Some also provide worklists for caregivers based on patient specific orders. How many sales reps from large HIT vendors whispered into CIO’s ears, “don’t buy that messaging solution from that little company, we’re working on that – it will be out… soon.” And in fact, one of the largest HIT vendors already does have a messaging solution, Cerner’s Alert Link (no link as it appears that Cerner doesn’t has a landing page for this product). The big HIT vendors entering or dominating this market is not a foregone conclusion for a variety of reasons.
The granddaddy of all disruptions might be when the market transitions from the current multiplicity of pain-point solutions to enterprise class solutions that are both broad and deep. In a very real sense, messaging is messaging – once you have the plumbing and enabling features like scheduling and rules engines, brand extension becomes an exercise in developing configurations to tackle as yet unmet needs. This disruption will come from both buyers and sellers. At some point buyers will recognize that they’re dealing with proliferation issues and market demand for broader and deeper – more complete – messaging solutions will begin. On the vendor side, there will be a natural tendency to add capabilities to gain competitive advantage. Eventually messaging solution provider’s product roadmaps will lead to enterprise class applications.
You can find a post Messaging Middleware Defined here. In the coming weeks posts on Strategy Implications, and HIPAA will be published. Be sure to check back!
Pictured above is the new SpectraLink Pivot Android-based enterprise smartphone from HIMSS14.
What do secure communications, care team coordination, patient engagement various workflow automation solutions and alarm notification have in common? They’re all examples of messaging middleware solutions found in health care. Which begs the question, what the heck is messaging middleware? This label is a term of art that was first coined by Emergin in the early to mid 2000s. As the name of a product category, it’s descriptive of the underlying technical functions of the product, but has nothing to with how the products are actually used – which can vary considerably.
All of this said, the term messaging middleware is terrible because it’s too generic and the term middleware usually doesn’t mean anything to people outside of IT. A survey of the market shows that many companies are avoiding messaging middleware and using words that describe their product in terms of their target market segment – secure messaging and alarm notification as two examples. In this series of blog posts, the terms messaging middleware, secure messaging, and messaging applications are used pretty much interchangeably.
Messaging middleware provides integration with and transport for data or communications between users, applications and medical devices. The data streams between these entities are mediated by software to orchestrate secure message flow, message payload and can even generate new messages based on the content of data streams. These systems also provide closed-loop communications where the transmission, reception, reading and response of a message is tracked, with messages resent or redirected (i.e., escalated) in response to a variety of possible delivery failures. All of this communications is recorded and logged in a database to provide management information and big data analytics opportunities. Messages sent to or from users typically entail some sort of mobile device, a wireless voice over IP handset or smartphone running a client app. Such systems also have web based clients that can be accessed on PCs for users to both send and receive messages. These systems can include a number of common features:
In the IT world, middleware or messaging middleware (messaging-oriented middleware) refers to infrastructure that enables applications; in health care, messaging middleware is the application. How these messaging applications are positioned and sold – and the kind of additional features used to differentiate and provide a competitive advantage – are quite varied. Examples of messaging middleware applications include secure physician-to-physician and physician-to-caregiver communications, physician- or hospital-to-patient communications (appointment reminders, prescription adherence), workflow automation applications (patient transport, bed management, rounding, prescription refills, etc.), alarm notification, and mass notification systems to name just a few.
All of these seemingly quite different applications can be implemented using the same basic product architecture. This architecture is made up of a number of highly configurable modules that are integrated and configured (via scripting and tables) to accomplish specific tasks. These modules, or software engines are very powerful, and an integrated constellation of these engines can provide very sophisticated enterprise-class capabilities. Not all of the solutions in this product category include all of the components noted in the diagram, and there are often qualitative differences between the different software engines included in a particular vendor’s solution. There are also key features in some vendor’s systems that are not included in this diagram (e.g., physician or staff scheduling).
The reasons for this shift to highly configurable software engines to replace purpose written source code are many. One fundamental shift is the considerable reduction in the scope of source code development and an increase in configuration as the primary means to define software functionality. Now, rather than having software engineers coding specific product features and workflows, engineers work on the basic enabling capabilities of the software engines. The task of implementing features and workflows for users can now be done by application specialists who tend to have direct work experience with those clinical workflows as nurses and techs. And besides having a vastly improved grasp of user requirements than engineers, application specialists are currently a less expensive human resource.
Another important consequence of this new product architecture is a substantially reduced time to market and associated reduced product development costs. A team of a dozen engineers would need 3 to 5 years or more to write source code from scratch to implement a basic messaging middleware system. Using engines, a half dozen engineers and a few clinician application specialists can launch a very competitive product in 18 months.
On a weekly basis, posts on Market Segmentation & Adoption, Strategy Implications, and HIPAA will be published. Be sure to check back!
Pictured above is the Voalte smartphone client on the Apple iPhone.
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.