Medical device manufacturers in markets that have managed to resist creating connectivity solutions are facing increased pressure from providers adopting EMRs. I mean, what's the use of automating the EMR if users have to write down numbers read from medical device displays and then manually type them into the EMR? That's certainly not "automation." This feature is already a required and necessary feature in some device markets, and rapidly becoming a necessity in many other device markets.
Manufacturers in this situation (needing an interface to EMRs for clinical documentation) often come to me with a plethora of questions. Before we get started, let's frame the discussion. In this post you will be introduced to a framework for clinical documentation connectivity. I do not get into details on product design or features. Rather we look at a basic framework and external factors that come to bare on any manufacturer contemplating a connectivity feature for their products. What follows is a sketched in foundation or starting point for manufacturers to use to plan for and implement what is probably the most basic connectivity application.
Let's run through the basics.
What are the basic components of a clinical documentation solution for a medical device?
Here are the most basic components:
- Your medical device must have the ability to export data in a digital form. This is relatively easy, as most medical devices are digital and have a serial port. An alternative (and industry best practice) is a network connection right in the medical device.
- A centralized computer or server that aggregates data from your medical devices. This server may do other things like convert units of measurement, relabel data, store the data in a temporary database, or provide users the means to review and edited acquired data (referred to as "validation") before it is pushed into the EMR.
- An HL7 interface that takes your device data, in your proprietary protocol, converts it to HL7 and sends it on to the EMR.
Geez, just three components? Can't I just outsource this whole EMR integration thing to a third party? Maybe. One can certainly partner with one of several MDDS vendors (like True Process, Bernoulli Health or CapsuleTech, now part of QualcommLife) who will acquire data from your existing serial port, and then push it to an EMR via an HL7 interface. This approach might well take this whole connectivity thing off your lap, but there are drawbacks:
- The principal business of MDDS vendors is to provide connectivity for multiple types and manufacturers of medical devices, especially legacy devices that don't have built in network connectivity. These MDDSs are purchased on a departmental or enterprise wide basis. What if you partner with another MDDS vendor, such as Capsule, and the prospect has deployed Cerner's CareAware house wide? The hospital will not be keen to installing any MDDS other than the one they, you know, already bought. Bottom line: prospects who have bought (or are planning to buy) a competing MDDS and not the one you chose are unlikely to buy your solution.
- Remember that medical device connectivity is not about the connection - it's all about workflow automation through the integration of medical devices and information systems. Another drawback of MDDSs is that you are dependent on them for the quality and extent of their workflow automation. Now some of these MDDS are pretty good at workflow, but they are not all equally good at all workflows for all device types. Nor are they as good as a well designed connectivity solution that's fully integrated with the medical device. Bottom line: compared to built in connectivity, a third party MDDS is probably a compromise. You are likely to face a competitor with a demonstrably better connectivity solution.
- By handing the connectivity portion of your solution to a third party, they now control a portion of the pricing of your sale. They may or may not be interested in discounting to win a sale that's important to you. And the incremental cost of your connectivity solution is also controlled by your partner. Bottom line: a hight priced solution.
Wait, wait, wait! HL7 is a standard, so isn't it just "plug and play"? Unfortunately, the HL7 standard and how interfaces are effected is far from ideal. HL7 is not a plug and play interface because:
- The HL7 standard was built (mostly by vendors) to include many options and exceptions. Consequently, there are many ways to configure one side of an interface that are all legitimate and consistent with the standard.
- Many HIT applications installed in hospitals have been modified by the IT department. It's not unusual for a mid sized hospital to have 100-200 software developers in the IT department writing code and modifying software purchased from vendors. Consequently, an interface that works with one hospitals EPIC EMR may not work for another customer also running EPIC because of customer modification.
- Like any other software business, EMR vendors regularly come out with new versions or releases. There is no general tendency among hospitals to keep up with vendors and stay on the current release of software. Consequently, when two or more customers have the same EMR vendor and product, they are seldom running the same release. This means that the HL7 interfaces in each hospital may have to be configured differently because the hospitals are running difference versions of the same application.
Please tell me there's an established industry method for dealing with the medical device connectivity for clinical documentation! Sure, but it's not pretty. EMR vendors in acute and long term care markets have a common way of dealing with HL7 interfaces. (The ambulatory market does too, but it is quite different and outside the scope of this post.)
- All HL7 interfaces are table driven with associated specification documents describing how they can be configured.
- EMR vendors only want to engage with another vendor to do an interface after there is a sale to a common customer (it's hard to find an EMR vendor who will work with you on a product development project, although it is possible).
- Providers prefer to have an aggregator for medical device data and a single HL7 interface for clinical documentation, rather than individual medical devices talking to the EMR.
- Once a customer sale is made that includes clinical documentation, the medical device and EMR vendors exchange HL7 interface specification documents, technicians from each company review the other's specification document and discuss how each side of the interface can be configured to effect a working interface. Each technician configures a test fixture in their lab and tests the interface over the Internet. Once a working configuration is proven out (through verification testing), each technician sends their configuration file to their own field technician (or the customer) for installation at the customer site. A second test on site validates the interface and the customer goes live.
- THIS PROCESS IS REPEATED WITH EVERY SALE.
- Any subsequent failure of the interface - a more common occurrence that you might hope - causes a repeat of the above process.
Two changes have emerged intended to smooth the rough edges around HL7. The first is FHIR, a new flavor of HL7 that is intended to be easier to implement and maintain, and cloud based integration platforms based on proprietary APIs (such as Redox Healthcare and Sansoro Health).
I get the message that I probably can't push this off to anyone else. So what do I need to develop, deliver, install and support these clinical documentation interfaces?
Let's start with product development.
Imagine you have to gather requirements and design a product that is unlike anything your company has ever designed before. Connectivity is like that, except because it uses your medical device as a starting point, and it's sold to and used by your existing customers. Medical device makers are great at gathering voice of the customer requirements for the actual medical device - what I call "knobology," the direct operation and use of the medical device. But when you start asking customers how want automated clinical documentation to work, please know that they're just guessing - because they may have never done what you're asking them about. This is fundamentally different from asking a customer about how an evolutionary improvement or new feature on a medical device might work.
The key to getting good requirements for connectivity features is going out to customer sites and directly observing how they do their jobs and documenting this in formal use cases. The scope of this workflow must extend beyond the direct operation and use of your medical device; how far depends on your application.
NIST has some very cool HL7 test fixtures exposed to the Internet that are ideal for testing during product development (obviating the need to work with an EMR vendor). Validation testing must include an HL7 interface to the customer's EMR.
Now let's summarize the internal resources you'll need to sell, install and support HL7 interfaces:
- Sales support will be required to sell the HL7 interface engine. The degree of sales support required varies depending on your product design. A conference call by a technician during an on site sales call by your sales rep may suffice. If your systems are larger and more complex, on-site sales support may be needed to close the sale. Over time this need will decline as reps gain experience.
- A test lab with your HL7 interface running on a server (current released product) that is exposed to the Internet. (You'll need this to develop the interface anyway.) After the sale, this test lab will be used to configure and verification test HL7 interfaces with whatever HL7 system your interface is integrating with.
- A technician with HL7 configuration experience to work in your lab. This person does not have to be a software engineer and, depending on their work load, can provide customer support services in addition to configuring HL7 interfaces.
- A network engineer is required to install the product. If you're device is network enabled, this engineer will have to be on site at installation to ensure that your devices and server are properly configured and operating on the customer's enterprise network. (Networking and network integration are a lot like connectivity, but that's a topic for a separate blog post.)
- Don't forget to build into your product the ability to remotely access to the servers installed in customer sites to be able to diagnose problems, apply patches, upgrade software, etc., remotely.
- In addition to the above, customer support will require a solid foundation of general purpose enterprise IT. This can be one just one person, but I would have at least two. You also need resources that can support the application software running on your server, and networking expertise to trouble shoot and fix network integration, performance and reliability issues.
- Tools will be required to trouble shoot and confirm the resolution of installation and ongoing support issues. If your medical device includes wireless networking, you'll need a spectrum analyzer (you can probably just rent this when you need it in the beginning), a packet sniffer, site survey tool, and probably a few other things. You will, of course, need staff that is competent in the use of these tools.
Resist the urge to train existing installation and support staff to gain the knowledge and experience required to support connectivity and networking; your customers will suffer while your existing staff struggles to become proficient, and as a consequence, so will you. Hire a core of really knowledgable folks, and then think about training some existing staff to complement your new hires.
You will of course, want to charge a software support fee for the HL7 interface (as well as the rest of the software services running on the server). Pricing for HL7 interfaces is pretty well established (and these prices are trending down, not up):
- The HL7 interface itself sells for between $5k to $10k.
- There is a project management fee associated with the interface technician's efforts that can range between $10k and $20k.
- Support for this kind of application code ranges between 12-20% of the list purchase price of the application software, per year.
You must sell this support contract to IT, who buys maintenance contracts on everything; Biomed departments tend to resist buying support contracts on medical devices. Even though Biomed is in no position to support your connectivity features, don't count on convincing them of this and gaining their endorsement of your connectivity service contract.
So, there you have it. A compendium of basic approaches to connectivity for clinical documentation. Remember that this is all high level stuff, and that the devil is in the details. Also, there are exceptions to everything. This should serve well to generally set management's expectations, and to sketch out an initial project plan. Success in this area is greatly dependent on a solid discovery process that identifies all the important market requirements and results in the most cost effective operations.
With the advent of Meaningful Use, and all that implies, we are all connectologists now. Whether we aspire to be, or not.
[Pictured is the medical device connectivity lab from a hospital in the Northeast - yes, it's a brave new world for them too.]
This post was updated June 14, 2017.
Tim,
To date, FDA has steadfastly indicated that EMRs/EHRs and NOT medical devices and as such are not currently regulated. Additionally, the MDDS FR specifically excluded “electronic health record software” from the scope of the MDDS. Is there anything on your radar that would seem to challenge this existing interpretation? I know the “noise” would indicate potential inclusion as a medical device, but currently I believe the exclusion still stands?
Steve,
Myself and numerous others believe it is only a matter of time until FDA regulates some portions of EMR software. And the Director of CDRH at FDA, Jeff Schuren has signaled in public testimony late last year and early this year that FDA is moving in this direction.
Heres a link to a recent post about this topic: http://medicalconnectivity.com/2010/10/08/impact-of-potential-fda-regulation-of-emrs/
At the end is a link to an article I wrote in PSQH magazine on the likely FDA regulation of some EMR software.
Great timing — you hit the nail on the head with “We are all connectologists now.” What’s your take on the gap between the working interface configuration (lab-tested) and the interface that gets implemented at the customer site (real-world)? We’re seeing this as a scoping issue among our users and potentially an implementation bottleneck.
Sovita, unfortunately there are potential sticking points at each step along the way.
You do raise an interesting point. What if the EMR vendor can’t provide a test fixture that matches what’s installed in the customer site? In this event, the medical device manufacturer is dependent on the provider for providing interface specifications, initial configuration and verification test. If the provider lacks the interest or ability to perform this role competently (not to mention in a timely fashion) this will likely result in additional costs for the medical device maker.
A likely outcome is greater involvement by the manufacturer’s HL7 technician (perhaps onsite).
It is to everyone’s advantage to explicitly define everyone’s roles and responsibilities for this process. Then when a party fails to meet their commitments, the other parties can have a basis for renegotiating who does what, for how much.
Sovita’s company, Caristix, has some interesting tools for supporting the HL7 interface process. http://caristix.com/why-caristix/where-we-help/
I am surprised that this article did not include one of the more important developments in device to EMR/EHR connectivity - the efforts of the Integrating the Healthcare Enterprise - Patient Care Devices (IHE-PCD) domain. (Full disclosure I am an IHE-PCD co-chair).
IHE-PCD creates fully specified, testable and tested integration profiles (precise specifications) to solve many of the issues that were brought up in the article. We obtain Use Cases, ideally from provider organizations, which address real world problems. We apply existing standards (such as HL7 and IEEE 11073) and create testable specs around these Use Cases. We then develop test jigs (actually NIST does this for us as referenced in the article) to test vendor implementations. We then conduct face to face Connectathons where product vendors test their devices and systems with other vendors using test scripts. We also demo the results at meetings such as HIMSS.
All this is done in an open environment - you can go to our FTP site, our web site or our Wiki. All specifications are freely available on the FTP site and are only given “Final” status after they have gone through at least 2 years of testing.
At this point there are ~20 devices/applications which have announced compliance with one or more IHE-PCD profiles. The most popular profile is the DEC profile for communication of results (heart rate, airway pressure, infusion rate, etc.) from devices to consumers such as EMRs or Clinical Information Systems. (This profile is also used by Continua to report results from their systems to IT systems.) We expect another 20 devices/applications to be released by the end of the year.
We invite all vendors to participate. We invite all provider organizations to start writing IHE-PCD compliance into their contracts and RFPs and to start exercising these profiles. As Tim’s article so clearly points out, the current situation burns money, burns time, burns man-hours, can result in safety issue and is not supportable in the long term. Adoption of IHE-PCD profiles is one giant step to start the process of weaning ourselves from the high costs and efforts of integrating medical devices with IT systems.
Tim - thanks for bringing these issues to the attention of device vendors. The Patient Care Devices (PCD) Domain of IHE http://www.ihe.net/pcd# strives to solve the problem of variability in the HL7 standard (and other communication standards) thereby eliminating most of the barriers you mention.
By leveraging IHE PCD Profiles my organization can implement medical device to EMR integration much easier, faster, cheaper, and potentially more safely. By writing one-line specifications into purchasing contracts we are able to tell vendors exactly how we want the integration including how the HL7 messages are structured, how the information is encoded and enumerated, and the transport method so we get both syntactic and semantic integration.
Tim: Thanks for sharing several great points in regards to why the medical device community should be thinking about how they plan to integrate the date from their devices to the patient record – EMR/EHR’s now.
While the FDA may not be directing or dictating ‘interoperability’ standards others are moving in that direction. You hit the nail firmly on the head that hospitals, long-term care facilities, physicians practices and the like - those who have and are planning to implement EMR/EHR’s - are thinking about how “Meaningful Use” will impact the medical devices and systems they have in place and those they plan to purchase now.
Ask anyone who has been focused on selling healthcare technology solutions and they will agree whole heartedly that ‘IT’ is all about workflow. They will also agree that those who purchase our IT solutions and medical devices are not spending any extra money on new systems they do not absolutely need. ‘They’ the hospitals, clinics and the like are thinking about the interoperability of systems and device data. Device manufacturers should also be aware that ‘they’ are listening closely to the ONC (the Office of the National Coordinator for Health Information Technology), the policy committee which is advising the CMS. The ONC has been suggesting that ‘Meaningful Use’ criteria for Stage 3, due out this summer, will include quality measures and criteria including medical device interoperability. This is all the more reason to be planning an integration strategy now.
HI Tim,
We believe ONC sponsored IOM study on EHR role in patient safety - errors caused by EHRs - will play huge role in FDA oversight decision. Report due January 2012.
We’ve never seen a midsize hospital have 100s of developers (programmers)even with self-developed EHRs. We see analysts doing implementation work (table coding, screen building, report writing) and interface coders but how many hospitals write code that touches vendors’ source code for core application? This negates support agreements and causes issues with new vendor upgrades.
Can you clarify here and provide data if you have any?
Thanks.
Ann
Tim,
I wish you had a better understanding of Nuvon’s solution, in which case you could have identified how Nuvon addresses many of the issues that you point out. Nuvon is not an MDDS system like iSirona (we are in a different category) and goes far beyond Capsule’s capabilities to integrate easily into a provider’s environment. Nuvon’s intelligent architecture and HL7 integration engine allow straightforward interoperability across devices and systems, enable low cost scalability and low-overhead integration into the IT environment that saves many of the costs that you identify, and provide a powerful interoperability platform - including the standards that Ken Fuchs identifies. Customers come to Nuvon to solve many of the issues that you raise.
Hospital connectivity has never been a major issue for us since our DICOM implementation almost 10 years ago. The current struggle IS with the ambulatory market. The bulk of EMR vendors in this arena seem blind to the DICOM standards. Even if they only implemented a DICOM secondary capture (basically an electronic document scanner with the patient ID as clear text), the medical device community would have an easy way to gain basic connectivity in this market (“easy” means many would use it). There’s also a wealth of open source solutions, to help EMR vendors with this solution, such as Mirth, DCM4CHE and also professional vendors such as Merge Healthcare. I fail to see why Docs who want this connectivity (I see our equipment in a lot of local cardiologists offices) wouldn’t plunk down extra $K as an add on for their EMR. It would allow the floodgates of connectivity to open for many devices (versus $K for each one-off HL7 connection and $K to maintain it).
There HAS to be a standard way to get into the ambulatory EMR. Whether it’s DICOM, HL7 (ORU?, CDA?), or a pushed PDF file with a filename convention, a standard needs to be drawn. This basic workflow would save time lost to sneaker-netting the data (or god-forbid scanning a printout), not to mention the initial setup savings (don’t forget the HIPAA issues!). Once we pass this milestone, a standardized basic “DICOM worklist” style functionality shouldn’t be far off.
EMR vendors: are you listening?
As a physician end-user and pragmatist this article was insightful, simplifying concepts for better understanding. Clearly it is not written for the rank and file non-IT individual, but it is not far off. These connections don’t have to be that hard. If I can go to a different bank, but still get my money (albeit with a healthy charge), I should be able to move healthcare data around just as easily. I set up my own one-way lab interface a few years back (Orchard Harvest to GE Centricity), and the HL7 white papers are really not that hard. What I would like to see is better translation for the average guy. Most of the above talk is clearly for larger organisations. I want to limit the obstacles to entrepreneurial physicians. Most reading this will agree, their doctor visits are not ideal: too long to wait, too much data to exchange (typically starting with clipboards and, ahem, paper), and suboptimal communication throughout (“doc, my prescription’s not at the pharmacy like you said it would be,” “I thought my co-pay was $25.00?!”). Let’s change this, starting at the ground level with the doctor and his office, the root of your relationship in healthcare.
1. We have our own LIS solution.
2. We need to have a bi-directional interfacing with Lab machines.
3. Do you have such Lab Interface Solution ?