Many medical device makers contemplating connectivity for the first time, prefer to build everything into the embedded system device rather than using a server to implement most of the connectivity features. This design approach is rarely taken, but why? The following is a quick look at the strengths and weaknesses of building connectivity into the embedded device and using a server.

Before we launch into the pro's and con's, let's identify the basic functional requirements for connectivity:

  1. You must have the ability to get machine readable data out of your medical device. Most all electronic devices have this ability, provided by a serial port. Alternatively, the device can use an Ethernet and/or Wi-Fi (or perhaps some other wireless technology).
  2. Next the proprietary data format from the medical device must be parsed and converted into something the target system understands, typically HL7.
  3. At some point the medical device data must be associated with patient from whence it came. There are many ways to do this, but the key is to make it as automated and reliable as possible.
  4. There must be a target system to communicate with. The common standard used for this communications is HL7. The target system can be a hospital's HL7 interface engine, or the HL7 interface module of an application like an EMR.
  5. The ability to communicate between the medical device (or connectivity server) and target system is necessary when you need to resend data that may be garbled or capture (and in a perfect world respond to) error messages from the target system - like, "don't send me any more data, I'm busy right now."

The two design options we're considering are building the function requirements above into the embedded systems device (a.k.a. the medical device) or to push all but the first function off to a server that provides requirements 2-5 for multiple embedded systems.

One more caveat before we start. We're not entertaining a connectivity solution based on USB drives, which is often referred to as "sneaker-net." Connectivity is supposed to entail workflow automation, and forcing users to manually download data from one device, transport it to the target device and then upload the data - not to mention housekeeping like purging data that accumulates on the USB drives - does not provide a very compelling value proposition. In fact, such a solution would likely require as much or more time from users as manually writing down data read off the medical device, and then typing it into the EMR (or some other system). I'm not saying there are no use cases where USB drives don't offer a meaningful connectivity solution, but they are very few and far between.

Pro Embedded

  • Eliminates a component (the server) from the system - less to develop, manufacturer, install, service and support (yeah!)
  • The COGS (cost of goods sold) of the overall embedded system, plus connectivity, will likely be lower due to the elimination of a server

Con Embedded

  • Industry best practice for health care IT systems integration is to run application code on general purpose computers. This presents additional challenges when doing an implementation on an embedded system, adding additional scope and complexity to project (e.g., in crease in UI on embedded device to support configuration, troubleshooting and use of the connectivity by end users).
  • The embedded approach conflicts with market requirement for a single server supporting multiple devices for connectivity because customers want 1 HL7 gateway to manage rather than one for every connected device.
  • Developing and maintaining embedded system code is more expensive and time consuming compared to application code on general purpose computers. Given that connectivity code, and especially HL7 interface configurations, will change over time, sustaining engineering efforts will be most costly and time consuming.
  • Implementing connectivity in a distributed fashion eliminates a central management and configuration facility, potentially adding to design complexity and development cost, e.g., due to things like log files, dbms, patient context, and HL7 interface configuration.
  • Increases sustaining engineering costs as any change to HL7 interfaces requires changing embedded system software (this is not a simple configuration change that can be done by the customer).
  • Distributed embedded solution increases installation and support costs (and cost of ownership) as access to, and modification of individual embedded systems is much more difficult and time consuming than supporting application code and scripts on a single server - trouble shooting can be more complex when compared to finding a problem on a single server.
  • Due to scope and complexity, the distributed embedded approach will likely go to market missing major features (e.g., forcing users to take manual steps like entering patient ID rather than automating that process), necessitating a follow on project of similar cost and effort.
  • Any effort spent creating tools to reduce the costs and complexity of managing connectivity on distributed individual embedded system devices adds to overall development costs.
  • Getting Biomed to agree to purchase support for the embedded device (due to the embedded connectivity) will be difficult at best, and often results in a refusal to buy, which will cause the customer to incur time and expense charges for connectivity support (esp. reconfiguring HL7 interfaces) creating the perception that the cost of ownership of the device is unreasonably high.

Pro Server

  • The market requirement is for a centralized, server based connectivity solution that is easy to use (has efficient and complete workflow automation), avoids a potential competitive weakness, and is easier to sell as it is what IT buyers are looking for.
  • It is much easier to use open source software on a server to lower development costs, time to market and COGS, compared to implementing on an embedded system.
  • Reducing scope of the embedded system device reduces embedded development costs and time to market for the embedded device.
  • Reducing scope of the embedded system device may result in a reduction in COGS.
  • By investing the time otherwise spent integrating connectivity into the embedded system, it is possible to deploy a more feature rich and competitive server-based connectivity solution.
  • It is possible to sell support contracts to virtually all customers to cover support costs and minimize perceived cost of ownership (not to mention hassling over service charges every time someone needs to touch a device with embedded connectivity).

Con Server

  • Adding a server to the project may be perceived as "scope creep" by management.
  • Many embedded system R&D shops lack a core competency in developing application software for general purpose computing platforms. This can be an important issue, but one that is pretty easy to overcome through new hires and/or outsourcing.
  • A server may be perceived as adding cost and complexity to the solution (although the opposite is true).
  • Management may not want to get into "the software business" - however, any medical device vendor adding connectivity is, by definition, in the software business.
  • Most standalone embedded system product development projects are complete before product launch, except for minor sustaining engineering projects for things like parts obsolescence or fixing latent defects; server software development is more of a sustained R&D spend, keeping up with emerging market requirements and changing technology (development tools, operating systems, and hardware).

The pro's and con's of a server deployment are pretty balanced. Including a server in your design does take real effort. But the deciding factor between going embedded or with a server in most cases is a desire to avoid the disadvantages of implementing connectivity on the embedded system.

The current industry best practice for connectivity solutions is to aggregate the data from multiple devices on a server. Depending on the data volume and other factors, the server may serve an entire enterprise (multiple hospitals), individual hospitals, or individual care delivery or diagnostic areas. The data aggregation function of the server is important for several reasons.