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:
- Specifying those requirements that are unique to my situation are where I have the most control in acquisition;
- There are other players in the market who may change the landscape of what is available to me; and,
- The government may require something which can constrain my options.
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.
There’s a similar standards battle brewing in the “internet of things” world — see links below. Continua is great, but I wonder why the medical device community doesn’t take advantage of these larger market connectivity solutions? Is my WiFi-enable blood pressure cuff that much different from my house thermostat?
Open Interconnect Consortium
AllSeen Alliance
Thread Group
@Bob, thanks for your comment and the links.
Perhaps I wasn’t clear enough in that I believe the area over which healthcare providers have control is those areas unique to their industry. In the case you state above, a thermostat is different from a blood pressure cuff in the context and use. I’d say a better analogy would be a thermostat and thermometer as the end data item measured is temperature.
In that case, the thermostat would be sending a piece of data related to the temperature of a zone in a space. The thermometer is sending a piece of data related to the temperature of a patient from a specific zone, or area of the body. Therefore a unique data item representing that and its context would be of value. However, for all of the other ‘standards’ needed for transmission, one could use the same standards as for other industries.
In the case above, you wouldn’t want the temperature of the home to enter into the EHR application and then be acted upon by the clinician based on its value. Therefore, one needs to make sure the uniqueness of that item is preserved so that it is stored and acted upon in the proper system.
Continua is working to provide a ‘plug-and-play’ solution, so they need to worry about the other standards and constraining them to meet the ‘plug-and-play’ claim. However, at a data and messaging level for industry-specific systems, many of those transmission and connectivity issues can be ‘delegated’ to outside the industry standards.
So, I generally agree with you outside of needing to ensure uniqueness where it is required for the industry.
The question is who will impose standards on the industry? In many tech markets (mobile phones, cable TV, IT, high-end stereo equipment) vendors, customers or both come together to agree upon a minimal set of standards to provide sufficient interoperability and consequently value to drive market adoption. Such a process is never pretty and there is often duplicate groups with competing solutions working to impose their vision of interoperability on an industry.
In health care, there are numerous factors contributing to barriers to entry and change that have forestalled such interoperability alliances until the last few years.
As Bridget points out, in mHealth it looks like a combination of enabling technology providers (like wireless carriers) and governments are going to define the set of standards to facilitate interoperability.
How and whether this bleeds into the conventional medical device market remains to be seen.
It would be helpful to point out exactly where in the current version of the proposed Meaningful Use Stage 3 requirements there is an actual requirement for medical device interoperability. I say this because I can’t find it. Moreover devices populating the EHR have been I think imagined to be part of mandated Meaningful Use from the onset but have never actually been there. This doesn’t mean that interoperability could not be a way to achieve Meaningful Use, but that is different from interoperability being required to meet Meaningful Use.
It is also helpful to remember that capital M capital U Meaningful Use (i.e. that which is required under the EHR incentive program) can be different from common-speak meaningful use (i.e. that which is a good idea because it can contribute to the value of EHRs and presumably quality of care.
Or to put it another way, one can do things that are not required by the government, and some of those things might actually be good. But lets not confuse government requirements and good ideas which may or may not always correspond.
Thank you for your thoughtful comments - I see that you wrote on MU and medical device interoperability 2 years ago on this blog (I also did a presentation on MU2 regarding the requirement of some physiological data to be present in the EHR but no requirement that the data be electronically entered, i.e., it could be hand entered into the EHR application). http://medicalconnectivity.com/2012/12/27/ehr-mu-interoperability-but-of-what/
You are correct in that if one reads the requirements for MU and certification, it is implied and not explicitly stated that medical device interoperability/connectivity will be required as much of the data required to be available in the EHR is derived from medical devices. I hearken back the efforts of HITSP (now defunct and/or folded into the ONC activities) and their IS77 (disclosure, I was involved in parts of the negotiation and definition of that effort specifically with regard to the WAN interface standards definition) and see that if so desired, the US government can compel the use of standards at the system interfaces which most believe will bring about better interoperability between systems. This requirement to meet standards for data and messaging between systems is more easily done via electronic means or medical device connectivity.
Your comment regarding MU and mu is a good one as well. MU in the regulatory sense has strict definitions, functionalities and standards with which the EHR application must adhere for the ‘carrots and sticks’ to be applied. mu in the ‘goodness’ sense means to me the best application of technology to enable better healthcare. So we are in agreement with regard to the differences in that term.
My overall message in the blog post was to point out that there are many players in this area and they each have strengths which they can leverage towards their goals. For the average clinical engineer working away in their healthcare setting, their awareness of these players can sometimes be obscured until they are working on a project and find some of their efforts constrained. Many times, as described above, there may not be an explicit requirement, but an implicit one which will drive the implementation decisions.