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.

Has anybody wrestled with the idea of placing patient-care applications on the laptop COWs (Computers on Wheels) in Hospitals?

There is a new series of USB-connected Ultrasound transducers that can do many ultrasound procedures, including Bladder Scanner functions.  It operates on any laptop, when loaded with the manufacturer’s software.  I can foresee many other patient-care functions vying to share the computers already in the patient vicinity.

Any guidance on this subject?

Here’s my reply:

As others have pointed out, you are right to be concerned about the safety of mixing regulated medical device applications and applications from any other source on the same computer. Moving forward without the proper information does expose your hospital to additional risk. At minimum you may be using the device “off label” if you unwittingly fail to follow the manufacturer’s instructions. (Note that the FDA’s interest in “off label use” centers on patient safety, where manufacturers may promote products for uses they were not designed and tested, or when manufacturers make an application with an easily cleared intended use knowing the market will buy and use the product for a more difficult intended use.)

You will need some information from your medical device vendor with the USB scan head and associated software.

Questions on General Purpose Computers

How specific are their specifications for the computer (hardware configuration, operating system, any additional libraries or applications) that is used to run their medical device?

Regardless of how specific their specifications may be, you must use and maintain your system (the USB scan head heads, application software and general purpose PC) in accordance with the vendor’s directions for use, or you will be using the system “off label.” The actual specifications can be high level, indicating a PC of any make or model as long as it includes a specific processor class and minimum speed, and meets minimum required memory and disk space, and a minimum version for the operating system. Alternatively, the vendor may be obsessively specific, calling out computer manufacturer and model, the specific CPU, the required version of BIOS, and even specific versions of operating system components.

Neither approach, generalized or detailed specifications, is inherently superior. Generalized specifications provide a lot more flexibility in what computers to buy — and important consideration given the product life cycle for a PC is about 18 months. Detailed specifications limit you to buying a particular make and model that will soon be discontinued, forcing your manufacturer to complete verification testing on new models and possibly making “last time buys” of discontinued models to sell to their customers (until the verification testing is successfully completed).

Coexistence Issues Beyond the Computer

The above information is typically readily available. The trickier part in all this is to determine how accommodating their product development approach was regarding coexisting with other applications on the same computer. These are general purpose computers, and one should not be surprised when a customer wants to use it for more than one thing. Some medical device manufacturers anticipate this need, while some don’t. The framework for software specifications and coexistence is similar to the systems specifications above.

Don’t neglect to consider networking issues. Is the medical device in question intended to operate only on a standalone computer? Can the product “tolerate” a computer that’s part of a network? And if the medical device is a system that actively uses a network, there’s a similar (but more complicated) set of considerations regarding coexistence.

Start with the vendor’s service department (or sales if you’ve not yet bought), and ask for a written document detailing any restrictions there may be regarding installing other software applications on the same computer as the medical device.  Also inquire about possible restrictions on running other third party applications at the same time as the medical device. Don’t be surprised if your vendor has a hard time understanding your questions, let alone digging up the answers. Some manufacturers haven’t quite come to grips with the fact that medical devices are becoming information appliances, and not black boxes that they exclusively design and control.

The ability to support third party apps on a PC that’s a medical device is highly dependent on the design approach and verification testing used by the manufacturer. The verification test lab is a frequent bottleneck in R&D departments, so designing products that need to be retested any time Microsoft or Dell make a product change — or a customer wants to run some third party application — is a recipe for disaster.

“It’s the FDA’s Fault”

Don’t be surprised if the FDA comes up as an excuse somewhere along these discussions with device manufacturers — much like it has regarding operating system patches. The FDA does not define how manufacturers must or should specify or design their products. If a manufacturer wants to sell you a discontinued PC because that’s the way they specified it when the product was first developed (and they haven’t gotten around to doing the verification test for a new model), that was the vendor’s decision not the FDA’s. If the vendor chose that route, they can’t just do something else later because they now realize it would be easier — the FDA does insist that vendors follow their own processes. (That’s not to say the vendor can’t make a change like that, they just have to follow their quality system to plan and implement that change.)

In summary, if the medical device manufacturer anticipated customers running third party applications along with theirs, you are free to do so. But you may have to poke and prod and dig to get this answer with some vendors. Those vendors who are obsessively specific and design their products to run on their own dedicated computers may represent a hidden cost if you would like to run them on other computers available at the point of care. This hidden cost can manifest in 2 ways, the incremental cost to buy a dedicated computer, or the added costs to support discontinued PCs and/or running behind on OS patches as part of your enterprise IT infrastructure.

A while back Ann Farrell was nice enough to bring an interesting paper to my attention. Titled, “Workarounds to Barcode Medication Administration Systems: Their Occurrences, Causes, and Threats to Patient Safety” the paper is a fascinating read for several reasons. The authors studied barcode medication administration systems (BCMA) at 5 hospitals, and identified 15 types of workarounds and 31 types of causes of workarounds. This paper provides the most detailed and comprehensive description of product and implementation shortcomings centered on the point of care that I’ve ever seen. It’s devastating. Really.

So what’s this got to do with medical device connectivity?  Two words: workflow and barcodes. Medical device connectivity is the automation of workflow through the integration of medical devices and information system. Likewise, BCMA is the automation of workflow through the use of auto ID (barcode labels and scanners) and information systems. With connectivity, attention centers on the connection; with BCMA, attention centers on the barcoding. Where should the attention be focused? Workflow.

Workflow is the Rodney Dangerfield of point of care systems. Everyone, manufacturers and clinicians both, focus on the tangible stuff, like serial cables and network connectivity or barcodes and readers. The invisible stuff, like water is to fish, is the workflow that occurs at the point of care. There are two key workflow data points that are required for a well designed product. First is capturing the complete workflow process in which the technology solution is to be used.

Framing the workflow should extend beyond the scope of the actual product, so that everything flows well at both the initiation and end of the workflow. Whether you’re a provider looking to define requirements for a vendor selection process, or a manufacturer developing a new product, use cases are an ideal tool for capturing workflow. Use cases are easy for non-engineers (product managers, application specialists, clinical analysts) to understand and use and can be structured to provide engineers with something that can easily be translated into software specifications.

The other key factor for good product design is managing workflow variability. After you’ve done a few workflow exercises you’ll see that most of any workflow is remarkably similar across users. But there’s always some portion(s) of the workflow that are highly variable. These areas of variation must be identified. Then the challenge is to define the degree of variability for each of the variations you’re willing to support in your product.

For every percentage of variability your product does not support, you can expect a certain percentage in lost sales or dissatisfied customers who make the mistake of buying a product that doesn’t match their workflow. Thoroughly understanding  workflow variability enables you to make an informed decisions about how much of your addressable market you want to trade off against the added R&D cost to support the target market’s full variability. Once you’ve captured the variability in your target workflow, you can make informed trade off decisions — and if you decide to support all or part of that variability you’ve likely captured what you need for requirements.

So let’s go back the Koppel paper on BCMA. First, the methodology used to gather the data for their study was similar to what a would be required to capture workflow. They used a combination of structured observations where they directly observed clinicians going about their work over a variety of representative time frames (in representative units, over each shift, at shift change, etc.). This is typically the first phase in gathering use cases. Next, the authors held unstructured and semi-structured interviews with groups of participants. This is a good method to nailing workflow variability, building on a solid understanding of the basic workflow gathered by direct observation. Finally, a couple of the authors participated in staff meetings about BCMA use.

I am sometimes amazed at the amount of “voice of the customer” data a manufacturer can collect, without actually understanding and documenting the actual workflow. Providers too tend to miss the workflow opportunity — on site clinical trials of new systems are a common vendor selection tool, but it is very rare when a provider actually documents their workflow and uses that to provide detailed requirements to prospective vendors.

These missed workflow opportunities, with vendors early in product development and providers at vendor selection, are why reading this paper just makes me cringe. The authors divided BCMA-related workarounds into 3 groups:

• Omission of process steps;
• Steps performed out of sequence; and
• Unauthorized BCMA process steps.

Probable causes of BCMA workarounds fell into 4 categories:

• Technology related;
• Task related;
• Organizational; and
• Patient related.

Reading the actual descriptions of workarounds and their probable causes points to the following shortcomings:

• Just plain old poor user interface design — shame on both the vendor and the providers who bought systems with these problems.
• Poorly automated workflow — either the vendor didn’t understand the workflow, or made a decision to “just have the user do it this way” in spite of the recognized workflow, and again shame on providers who didn’t recognize these shortcomings due to a lack of understanding their own workflows.
• Poor planning or implementation — buying computers on wheels (COWs) that don’t fit through doorways or actually reach the bedside (30′ cords for barcode readers are not the answer) are the responsibility of the vendor to ensure the customer buys the right thing, and ultimately the responsibility of the buyer to, you know, buy the right thing.

Now we come to one of my pet peeves, barcoding. I don’t really understand why the terms “auto ID” and “barcode” are used together. The set up for this requires the production and application of a barcode to a drug, device, patient, etc. And the user must manually pick up the reader and scan the barcode. This works great in the grocery store, but not in hospitals. If it wasn’t for the fact that (when they can be read) barcodes eliminate the potential for typographical errors, barcodes would represent more work than simply using a keyboard. Barcode’s saving grace is that barcode labels are pretty cheap, and in the best utilization of the technology are printed by the manufacturer as part of the product packaging. Again, think of the grocery store.

Barcodes are so simple conceptually, that many discount the planning and engineering required to design and implement a system that works reliably. Many of the workarounds noted in the Koppel paper result from the inability to read the barcode. Getting barcodes that can be reliably read on patient’s wristbands is not a trivial task. You must assemble the right combination of barcode printers, ink, wrist band material, and barcode symbology and orientation (you can’t read a linear barcode that wraps 2 inches around the patient’s wrist — you’ll never get it flat enough to scan). Another big problem with BCMA is that many of the barcodes on the meds administered to patients have to be produced and applied by the hospital.

Earlier this week I was interviewed for a magazine article singing the praises of barcodes in general, and meds administration in general. I asked the writer what market adoption rates for BCMA they’d uncovered. Over the past two years adoption grew from 23% to 25%. Certainly we’ve know about the need since the publication of the IOM’s publication of To Err is Human in 1999. The adoption of BCMA is not low and slow because hospitals don’t care. Koppel’s paper does a lot to shine a light on some of the reasons adoption has lagged. I’ll be surprised if I get quoted in the barcode story.

Chris Gill from Washington University in St Louis, introduced the second technical session.

The papers in this session will touch on distributed control and sensing in networked medical device systems. These are real time embedded networked system infrastructures for MDSS, and the development, assurance and medical practice-driven models for high confidence medical device software.

These systems are characterized as being made up of interlocking systems of (control) systems – interoperability, where devices in the system have an overall control structure. Such systems also embody various algorithms for processing data from sensors or other systems. There is invariably a human in the loop when operating these systems. As they develop, these types of systems must overcome systems integration and performance issues. A formal framework for embedded and hybrid systems is also needed.

Other key issues that must be addressed for these systems of systems include:

• Interoperable data, devices, computation, communication
• Security and privacy
• Large-scale medical information management
• Interaction of devices with different levels of criticality (e.g., managing safety and criticality)
• Multiple-level QoS tradeoffs and QoS guarantees
• Design for certification

Give the interoperable nature of these systems, co-development and co-assurance is a given. From and model based analysis, design and implementation of a system must be considered early on. Achieving user-centered designed for medical devices is also a challenge.

Finally, two additional issues for consideration: How do we balance highly configurable interoperable systems made up of multiple devices. Also, new ideas in “science of certification” and regulatory practice are for “Cyber-physical Systems” in HCMDSS.

Formal Methods Based Development of a PCA Infusion Pump Reference Model: Generic Infusion Pump (GIP) Project
David Arney, Raoul Jetley, Paul Jones, Insup Lee, Oleg Sokolsky, University of Pennsylvania, FDA/OSEL

This project developed a generic pump safety model, based on a study of accepted formal techniques for developing safety critical embedded systems. They applied an extended finite state machine system model to create a hazard model.

GIP system structure includes a pump controller, patient monitor, alarm manager, caregiver interface, hardware and generic infusion pump. All of this is connected to a network to log data. Requirements were gathered from numerous sources for a generic PAC pump. Sample requirements were provided.

The hazards and FMEA were divided into software, hardware and usage scenarios. Hazards were divided into failure mode, description, severity, probability, delectability, causes, and mitigating strategies. Sample hazards included calculation error, wrong does entered, air in line, and output occlusion.

A conventional state machine model was used to create a reverence model for pump operation. Multiple communicating state machines to model operation scenarios.

Test generation covered all states, transitions between states, and modified conditions/decision coverage. Test cases were used with a test driver or application interface that mapped variable sin the model to structure or functions in the implementation.

The testing was successful and an open source package will be available for device manufactures to use. Future work will put together a full running system.

They’ve had a very hard time to get any pump manufacturers to work with them. Right now they are looking for future collaborators to extend their testing and implementation research.

The have also considered what would be involved in putting this software test system through the medical device approval process. Current FDA process does not clearly map to software generated software.

This is similar to automated software testing done by software vendors – something that the vast majority of device vendors have little or no experience.

Point-of-Care Support for Error-Free Medication Process
J. W. S. Liu, C. S. Shih, P. H. Tsai, H. C. Yeh, P. C. Hsiu, C. Y. Yu, W. H. Chang, Academia Sinica, National Taiwan University, National Tsing Hua University

Jan Liu, from the Institute of Information Science Academia Sinica (http://sisarl.org/), presented Point of Care Support for Error Free Medication Process. The process starts with a prescription, the creation of a prescription order, ending with a personal medication dispenser. Liu presented their motivation and goals, use scenarios, architecture and implementation, and ended with calls for collaborators.

Over 25% of admissions to nursing homes related to improper use of meds, and 125,000 die annually due to non-compliance with meds. Medications regimens can be very confusing – take one twice a day, one 4 times per day, another 3 times with meals, etc. Consequently, a number of patient dispensing products have been developed – all with considerable limitations (like programming the old VCR).

The project made the following assumptions: a personal dispenser manages all meds and health supplements of the user; directions used by the dispenser are based on complete medication record of the user; and some network connection is available. They also assumed that the pharmacist knows all the meds a patient is taking (rather than an individual physician). The user’s habits and preferred meds times are taken in to account when possible. And the dispenser is allowed to monitor and record medication history.

The system receives data on prescriptions via a third party prescription order entry system. The system takes the orders as input to an authoring tool that looks at ordered drugs, drug interactions, the patient’s EMR, and then creates a medication schedule specification (presently XML).

The dispenser contains wells into which individual bottles for each medication are housed. The bottles will have RFID tags for automatic reading (bar codes were rejected due to the complexity of having users scan the tag). They dispenser knows which drug is in which socket due to RFID. An annunciator (on the dispenser or via cell phone message) indicates when to take a medicine, and a tray opens with the drug to take.

If compliance errors occur, appropriate messages are generated for the patient. They identified 8 events and actions that could occur alone or in combination. Recognizing that similar scheduling and compliance issues exist in acute care delivery as with self administered drugs, they have also targeted ambulatory and acute care systems. They noted that current acute care medication dispensing systems are not well integrated into other systems. Detailed workflow for meds administration in an acute care environment was presented.

Core competencies include underlying models and algorithms for medication scheduling and dispatching; component-based dosing, the architecture and implementation of dispensers; and device software quality assurance. They’ve been challenged developing reliable dispensing mechanisms. Questions remain regarding device and user interaction, and user behavior models (e.g., what if patient wants to travel and can’t take dispenser).

This dispensing is based on accurate and complete drug data that is in a format that can be used by the system. They are currently using drug libraries to take advantage of their concise and consistent descriptions. In addition to creating a consistent nomenclature and structure for describing a prescription, there are also interactions to take into consideration. Numerous constraints like temporal distance, diagnosis, maximal and minimal constraints must also be supported for safe and effective medication administration.

They are looking for collaborators in medication prescription content and representation. They would like to work with physicians, pharma, and over vendors in the meds administration chain.

A Survey of Software Engineering Techniques in Medical Device Development
Raimund Feldmann, Forrest Shull, Christian Denger, Martin Huest and Christin Lindholm, Fraunhofer Institute, Lund University, SWEDEN

This was the most depressing presentation of the entire workshop. The cozy insular world of medical devices has caused the industry to sorely lag similar industries with regards to product development methodologies and resulting embedded software quality.

The motivation for the survey was that software is integral to embedded systems and clinical workflows. There is a tremendous amount of innovation in the IT field, and software makes up a major portion of embedded system product and development costs. Studies predict that medical device R&D investments will increase to 33% of the overall budget by 2015. In 1996 10% of medical devices recalls were caused by software-related issues. In June of 2006, software errors in medical devices make up 21% of design defects.

They wanted to characterize medical device software regarding software engineering methodologies, benchmark this with other embedded system industries, and to explore current challenges. The goal was to use the results as input for better integration of software engineering standards into applied processes and to develop new methods tailored to the medical device domain.

The survey targeted medical device and medical information systems with a web based survey. The survey addressed countries world wide, and was done June to September 2006. The survey was promoted on the Internet and via direct mail.

The survey was not fully randomized, but appears to be consistent with similar studies. Admittedly, the survey may not be indicative of the state of the entire industry; however, large percentage of respondents was alike in having a primary focus of safety critical software. Results seem to be consistence with experience of domain insiders from which the received feedback.

Unlike many US centric studies, this study’s respondents were from around the world. North American respondents only made up 13% of the sample. Software teams were made up of 1 to 10 engineers made up 49% of respondents. The importance of software to the final product was rated as very important in 84% of responses. And safety-critical devices were involved in 76% of responses.

Most vendors both develop their own software and use some third party software. Only 36% of engineers were computer scientists – respondents noted difficulty in finding these engineers. The activity that causes the most software problems was reported to be the activities related to requirements (63%). Next biggest problem was architecture (16%), then related to implementation (10%). Analysis of survey responses indicated vendors have problems with changing requirements, out of date embedded software architectures, generally miss opportunities for software component reuse potential, and have poor code maintainability. Improvements in requirements engineering seems most promising to gain significant improvements. This contrasts with the fact that most effort is spent on test (40%).

So, how are requirements specified? Natural language dominants requirements as always or frequently used (52%). Structured notations (e.g., use cases) are only used by 40% of respondents, and only 2% use formal languages for describing requirements, architecture and design. Even Microsoft uses more robust requirements gathering that that used by most medical device vendors.

Tool usage was infrequent, with poorly defined processes. A scant 12% use tools to automate testing. Tools are most frequently used in risk management (63%) with Microsoft Excel noted as the most frequently used risk management tool.

Techniques to ensure software quality lead with black-box functional testing (74%), inspection and reviews (56%), structural testing techniques (29%), and software risk analysis (FMEA) at 18%. Less than 5% of medical device vendors collect code and design metrics for all their projects. Sadly, if you don’t measure it, you can’t manage it.

The studies conclusions noted that there was no significant difference of the perceived challenges between small and large companies, who where focused on usability, maintainability, reliability, and safety. While the importance of software is well appreciated, less formal processes, notations, and tools are predominant. Most software quality problems occurred in the early development phases.

Defect prevention instead of detection is sorely needed by the industry. The industry also needs to optimize requirements activities. Systematic techniques for requirements elicitation and management are needed; traceability is key. Investing in software architectures is needed, and could serve as a foundation for plug and play interoperability. This would include systematic reuse with software product line architectures and component-based development.

In my experience, the major barrier to software product line architectures is the way companies in the medical device industry are organized. The vast majority of companies are organized into silos that match their target markets, divide along product categories or both. Each silo group has their own marketing and R&D, sales is usually less fragmented. Getting these individual R&D groups to agree on a product line architecture is near impossible without the very active participation of senior management to provide adult supervision.

A very low adoption of configuration management, combined with the long life cycle of medical devices, creates problems in resolving software errors, and determining where and when the error was introduced. This only gets worse when connecting devices into a system.

Raimund also noted the Department of Defense is publishing best practices for software

If you want a full report, email Raimund at rfeldmann@fc-md.umd.edu

Technical session questions:
I asked if vendors have a hard time finding and maintaining engineers because product life cycles are so long and projects so infrequent. The survey did find this to be an issue. Another attendee noted that many graduated computer scientists are not educated with the appropriate skills for embedded systems engineering. This was acknowledged, and it was noted that the accumulated knowledge and training is key.

With their research in other industries, how did the medical device compare? Compared with the automation industry and some other industries, the medical device industry is way behind.

In Taiwan, vendors have found that computer scientists are poorly prepared for developing consumer electronics embedded systems. They have turned to electrical engineers for embedded software.

The amount of software errors has doubled over the period reported in the study – it was noted that the functionality in medical devices has also increased, and it was suggested that in fact, error reports by functionality may have gone down.

Requirements at Kaiser are frequently gathered by clinicians trained as systems analysts because it is easier to train them to write requirements than to take a systems analyst and train them on nursing. They also use natural languages because the training hurdle for structured requirements languages is very high. Raimund noted that requirements can certainly be gathered initially via natural language, but subsequent analysis should elicit structured consistent requirements for generating specifications.

After the Technical session, there was a brief period where Abstract Talks were presented. Here are some of the abstracts that were presented.

SOA Medical Device Interoperability

Model Driven Architecture: OMG (not “oh my god” but “object management group”) – model driven architecture solutions. Case Study: tele-surgical robot.

MD PnP Case Study: Use Case Demo: X-ray and Ventilator. During surgery ventilation is frequently interrupted to take certain x-rays, the system provided a reduced ventilation rate and synced the x-ray with breaths at either inspiration or expiration. This was another example of simple device interoperability that does not exist commercially.

Workflow Based Integration Framework for Medication Use: to eliminate drug related injuries, focused on communications and avoiding drug interactions. To reuse existing technology, they used a workflow engine to integrate disparate systems at authoring, database, prescription entry system, and dispenser. The workflow includes doctor, pharmacist and user/patient as actors.

Software Certification for Distributed, Adaptable Medical Systems: Challenges and Paths Forward, from BBN Technologies. BBN works on highly distributed high reliability defense systems and wants to transfer their techniques to medical devices. The new generation of distributed adaptable software systems presents numerous challenges. These complex systems have distributed resource usage and system configurations which change in real-time. They are designed to allow more effective usage of limited resources to meet evolving user needs by dynamic adjustments and reconfigurations. These systems are difficult to Certify due to required (implicit and explicit) scheduling of distributed interactions while maintaining system safety. Conventional approaches like exhaustive testing, documentation, code review, and other formal methods for high-confidence software are no longer economically feasible for highly complex, dynamic, distributed systems. As complexity increases there is the inherent potential problem of state explosion – where permutations and variables rapidly increase to become unmanageable.
A particular stumbling block is absence of methodology for dealing with dynamic resource management. Current methods assume the static allocation of states. Interesting.

Christopher Gill presented Cyber-Physical Systems Software for HCMDSS. Chris suggested that current operating systems and middleware are not well suited to controlling even single physical domains. Lee has several good observations about how time got left out of computing; abstractions, like processing threads that don’t consider time. Patient physiology requires that the semantics of multiple domains be integrated rigorously. Failure cascades involving multiple cyber and physical elements can occur. New work has laid a foundation for better dealing with cyber-physical systems. Timed coordination models, timed futures and hierarchical scheduling are useful. A new cyber-physical operating system and middleware would be ideal.

Tammara Massey from UCLA presented, Towards Reconfigurable Embedded Medical Systems. This presentation went to crossing the chasm from individual embedded systems to broader systems that ranged from multiple different peripherals to multiple interoperable embedded systems. She described two different projects, one a reconfigurable gait study system, the other was fabric based sensors.

Marwan Abdeen presented FDA: Between Process and Product Evaluation. Process oriented software validation and certification has been adopted by the FDA. While the FDA recommends that software validation start at the beginning of the software development process, it does not specify specific development processes or models. This paper questioned the clarity and effectiveness of the FDA’s process oriented approach to software validation, contrasting the FDA approach to a more proscriptive one that included specific tools and methodologies. They concluded that the FDA validation approach leads to confusion in the minds developers. The absence of requirements for metrics and measurement of the development process was presented as a shortcoming of the FDA’s approach. The Common Evaluation Methodology (frequently used for security and defense applications) was offered as a more rigorous alternative to the FDA’s QSR.