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 Nuvon or iSirona) 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 MDDS is 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.
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, it’s easy to miss this fact. 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’ve 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 expertise. 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, 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.]