meds magazine
DESCRIPTION
May 2013 IssueTRANSCRIPT
An RTC Group Publication A Supplement to RTC magazine
MEDICAL ELECTRONIC DEVICE SOLUTIONS
MEDICAL ELECTRONIC DEVICE SOLUTIONS
MEDS
MEDICAL ELECTRONIC DEVICE SOLUTIONSMEDICAL ELECTRONIC DEVICE SOLUTIONS
MEDICAL ELECTRONIC DEVICE SOLUTIONSMEDICAL ELECTRONIC DEVICE SOLUTIONS
MEDICAL ELECTRONIC DEVICE SOLUTIONS
Using Human Factors to Shape
Device Development
Meet FDA Compliance with Lifecycle Management
The Industry Leader in Embedded ComputingCorporate names and trademarks stated herein are the property of thier respective companies. Copyright © 2013 IBASE Technology, Inc. All rights reserved.
COM Express
Barcode Scanner
Envision Quality Patient Care
Embedded Mainboards
Untitled-3 1 5/2/13 2:56 PM
May 2013 MEDS Magazine 3
MEDICAL ELECTRONIC DEVICE SOLUTIONS
MEDSmay 2013
CONTENTS
digital subscriptions availablewww.mEdSmag.COm
Medical Electronic Device Solutions (MEDS) uncovers
how embedded technology will bring the biggest breakthroughs in electronic medical devices design. Whether large or small—MEDS is the most influential source of information for engineers, design-ers and integrators developing the newest generation of complex and connected medical devices. MEDS is currently a supplement of RTC magazine, distributed in print to 18,000 engineers, and electronically to 12,000 in the embedded com-puting market. Learn more about MEDS at www.medsmag.com.
SPONSORSaxiomtek ..................................................................19
Commell ...................................................................18
congatec ................................................................ 20
iBase ..................................................................................2
Intelligent Systems Conference and Pavilion ...................4
mSC Embedded ..............................................4
UL ...........................................................................................11
PULSE8Bluetooth Health Device Profile: Compatible Communication for Specialized Devices—Part 1Florian Herrmann and Karsten Aalders, Stollmann
12FDA Human Factor Requirements Change the Landscape of Medical Device DevelopmentDavid Hirning MS and Virginia A Lang, PhD, HirnLan, Inc.
16Medical Device Manufacturers Address Compliance Mandates with Product Lifecycle ManagementEric Marks, Price Waterhouse Cooper
UP FRONT5EDITORIALMedical Devices and Remote Access—Extending the Reach of Medical ExpertiseTom Williams
6PuBLISHER'S LETTERThe Med Tech Food ChainJohn Koon
FOCUS7InnOvATIOn HIgLIgHTSA Collection of What's New, What's Now and What's Next
4 MEDS Magazine May 2013
MEDICAL ELECTRONIC DEVICE SOLUTIONS
MEDS
To Contact the RTC Group and MEDS Magazine:
HOME OFFICE The RTC Group, 905 Calle Amanecer, Suite 250 San Clemente, CA 92673 Phone: (949) 226-2000 Fax: (949) 226-2050 www.rtcgroup.com
EDITORIAL OFFICE Tom Williams, Editor-in-Chief 1669 Nelson Road, No. 2, Scotts Valley, CA 95066 Phone: (831) 335-1509
Published by The RTC GroupCopyright 2012. The RTC Group. Printed in the United States. All rights reserved. All related graphics are trademarks of The RTC Group. All other brand and product names are the property of their holders.
PRESIDENT John Reardon, [email protected]
PUBLISHER John Koon, [email protected]
EDITORIALEDITOR-IN-CHIEF Tom Williams, [email protected]
MANAGING EDITOR/ASSOCIATE PUBLISHER Sandra Sillion, [email protected]
COPY EDITOR Rochelle Cohn
ART/PRODUCTIONART DIRECTOR Kirsten Wyatt, [email protected]
GRAPHIC DESIGNER Michael Farina, [email protected]
WEB DEVELOPER Justin Herter, [email protected]
ADVERTISING/WEB ADVERTISINGVP OF MARKETING Aaron Foellmi, [email protected]
MEDS SALES ACCOUNT MANAGER Jasmine Formanek, [email protected] (949) 226-2004
BILLING Cindy Muir, [email protected] (949) 226-2021
Ultimate graphics and video performance
The MSC C6C-A7 module is based on AMD‘s Embedded R-Series platform delivering high-performance processing coupled with a premium high defi-nition visual experience in a power efficient solution. Supporting OpenCL™ it can boost the computing performance using the graphics engines for parallel processing.
AMD Embedded R-Series
Accelerated Processing Units
R-460L quad-core, 2.0/2.8 GHz R-452L quad-core, 1.6/2.4 GHzR-260H dual-core, 2.1/2.6 GHzR-252F dual-core, 1.7/2.3 GHz
AMD Radeon™ HD 7000G Series graphics Up to 16 GB DDR3 SDRAM MicroSD card socket, bootable Three DisplayPort/HDMI/DVI
interfaces VGA and LVDS/Emb. DisplayPort Four independent
displays supported DirectX 11, OpenGL 4.2,
OpenCL 1.1
COM Express™ - MSC C6C-A7
EMBEDDEDSOLUTIONS
R-SERIES APU
MSC Embedded Inc. Tel. +1 650 616 4068
www.mscembedded.com
V-3_2013-WOEI-6376
Untitled-4 1 3/1/13 12:17 PM
Untitled-3 1 5/3/13 11:41 AM
May 2013 MEDS Magazine 5
UP FRONTEDITORIAL
TOM WILLIAMS Editor-in-Chief
Stepping back and taking a “big picture” look at the world of medical devices and how they are developing, both in technology and their influence on overall health care, re-veals a complex set of interactions. For one thing, the health care landscape is about to change dramatically. With the full implementation of the Affordable Care Act, the number of insured patients in California alone is predicted to increase by about four
million. That means a huge demand on available physicians and their support personnel in the form of medical technicians, practitioners and nursing staff. This is both an opportunity and almost an impera-tive for the employment of technology to help meet the great increase in demand for care and services.
There is talk, at least in the California legislature, of modifying certain laws to expand the areas in which non-physicians such as nurses and practitioners, as well as such specialized professionals as optometrists, can provide expanded treatment without the direct supervision of an MD. This has not unexpectedly caused some alarm among the medical community. Nonetheless, it is indicative of the urgency these developments are causing. Suggestions of legislation of this type reflect a need to extend the knowledge and expertise of physicians through less trained personnel. The question is how risky that might be, and it raises the parallel question of whether advanced technology in the hands of these less trained practitioners could reduce some of the anxiety and risk involved, and also whether it could help extend the reach of the licensed physician to confidently cover more patients. There is also the even more complex question of its effects on the overall cost of health care.
It appears that the place that sophisticated medical electronic devices can really make a con-tribution to the coming situation is in conjunction with telemedicine. It might be nice to have an otoscope that produces a 32-inch high-definition image of the inside of a patient’s ear, but very few MDs are going to buy one to have in their office. However, in a remote or rural location or even in an urban clinic center where such an instrument—along with other electronic devices for blood pressure, EKG, respiration and other diagnostic activities—can be administered by trained person-nel who are not MDs, such activities can still be carried out under the ultimate supervision of an MD. Telemedicine can thus extend the reach of the MD’s knowledge and experience by enabling technicians and practitioners to competently gather diagnostic information using medical electronic devices and also to perform certain—hopefully well-defined—procedures under the direction of a licensed physician. Telemedicine also has tremendous potential in home monitoring to help patients live more independently, thus providing both a better quality of life and relieving the pressure on existing facilities and their accompanying expense.
The above scenario differs from some more ambitious ideas such as the competition currently underway to develop a portable “tricorder” that would actually be able to provide diagnosis for some 15 diseases. Such an instrument supposedly would incorporate all the sensing, imaging and even non-invasive laboratory work along with enough integrated machine intelligence to actually arrive at a diagnosis. This holds promise, but it also raises questions about exactly which conditions would be targeted for diagnosis. Presumably these would be ones without ambiguous combinations of symp-toms, i.e., areas that would not require a Dr. House to finally arrive at a correct diagnosis.
Given that, such devices could also help alleviate the burden on physicians and medical facili-ties that will surely soon arise. But let us remember—they exist primarily as extensions of medical knowledge and experience, not as replacements for it.
Medical Devices and Remote Access—Extending the Reach of Medical Expertise
6 MEDS Magazine May 2013
UP FRONTPUBLISHER’S LETTER
The medical technology ecosystem is an ever expanding and complex food chain. Most noticeable are the manufacturers building medical devices of FDA class I, II and III such as EKG machines, blood pressure monitors, blood glucose monitors, insulin pumps, ultrasound systems, implantable defibrillators, wearable devices and all sorts of wireless monitors. The list goes on and on.
The component makers go to great efforts to chase after these device makers. All the medical IC chip manufacturers such as Texas Instruments, Renesas, STMicro and Freescale come up with new silicon, modules and supporting software to help solve the device makers’ design challenges. The software companies such as Wind River, MKS, LDRA, Visure Solutions and others provide tools to help these device makers be in compliance with IEC 60601-1 (now in its 3rd edition) and FDA 510(k). Design consultants, such as LogicPD and Sterling Medical Devices, provide design expertise to solve tough design problems when these device makers run into trouble. Additionally, there is a whole host of consultants to help with FDA clearance and compliance issues.
Device makers such as Johnson & Johnson, Medtronic, St. Jude’s Medical, GE Healthcare and Philips Healthcare strategize on how to sell their products to hospitals, home healthcare, health institutions and, in some cases, the retail chains. No one wants to use unsafe medical products with unproven quality. That is why the FDA is so important in regulating medical technology. One con-sultant put it this way, “To be successful in the medical technology business, you need to have good
ideas, a good team, ample funding plus the FDA!”Big responsibilities rest upon the shoulders of hospital administrators
and those with procurement authority for medical technologies and prod-ucts. The important questions are, “How safe is safe enough?” and “How do I know about and manage the risks associated with purchasing these medi-cal technologies and products?” The stakes are high here. We hear stories about car manufacturers recalling automobiles because they accelerated un-controllably or caught fire in a collision, or of manufacturers recalling baby cribs because they were unsafe, causing injury or death. When it comes to medical technology, safety concerns are just as important. For example, a friend of mine shared his story of when his implantable defibrillator deliv-ered the high voltage shock to “jump start” his heart when his heart was
perfectly fine. A first examination revealed no problems, but when it happened again in the hospital parking lot, he went back and the unit was replaced. Another incident was a “lead problem” associated with an implantable defibrillator installation. It was a more generic design problem and that model was recalled. A recall in this situation means surgery. Another kind of risk is “hacking.” This has been discussed many times in various conferences. Imagine a device such as an implantable defibrillator or an insulin pump being hacked. It could cause major problems for the patient.
Obviously, when it comes to patient safety and risk management, a well-informed decision maker is in a better position than those who are not. An organization called Medical Device Innova-tion, Safety and Security Consortium (MDISS) has proposed a Fuzz test method to help reduce the risks with medical electronic devices.
In this May issue of MEDS, we have articles about Fuzz testing and the FDA’s Human Factors Program. In June, MEDS will sponsor the Intelligent Systems Conference in Chicago, IL, where Dale Nordenberg, MD, Executive Director/Medical Device Innovation, with the Safety and Secu-rity Consortium, MDISS, will lead a panel on “Understanding the Medical Device Procurement Pro-cess by the Hospitals.” Also included will be presentations relating to Fuzz testing, FDA 510(k) Clear-ance, a Home Healthcare panel and other relevant medical technologies. www.issconference.com.
JOHn KOOn Publisher
The Med Tech Food Chain
Software &Hardware
Components
DeviceMakers Hospitals
TestAgencies
Consultants
FDA
May 2013 MEDS Magazine 7
FOCUS
INNOVATION HIGHLIGHTSA COLLECTION OF WHAT'S NEW, WHAT'S NOW AND WHAT'S NEXT
frequently fails in the face of unexpected or malformed inputs, also called fuzz. Fuzz can happen when software encounters real-world conditions, such as interacting with humans or machines that don’t behave as expected. Fuzz can also happen deliberately if an attacker wishes to gain control of a system or disrupt the normal operation of a piece of equipment.
When failures are found, they can be fixed, which makes the software more robust and more secure. The Institute of Electrical and Electronics Engineers (IEEE) defines robustness as the degree to which a system or component can function correctly in the pres-ence of invalid inputs or stressful environmental conditions. Hav-ing a properly functioning system, despite the unpredictable, is es-sential in the medical systems world in order to keep patients alive and information confidential.
Fuzzing is appropriate for medical device manufacturers, com-puting and network equipment manufacturers, healthcare delivery organizations (HDOs), researchers, and the organizations that live in the medical industry supply chain. However, it is critical that medical devices that are being used for patient care never undergo fuzz testing. Rather fuzz testing should be performed on medical devices in an iso-lated testing laboratory or at the site of manufacture so that the tested device can be cleared of the fuzz inputs and properly recalibrated to manufacturer specifications before being used in a live clinical setting.
Device manufacturers should use fuzzing as part of their soft-ware development life cycle. Finding and fixing more bugs during product development will result in products that are safer, more ro-bust and more secure. Finding and fixing bugs before products are released results in measurable cost savings for the manufacturer, providing a significant return on investment for the cost of tools and testing because there will be fewer incidents of medical device issues that would require implementation of risk mitigation strate-gies or recalls in the postmarket period.
The full white paper (www.mdiss.org/media/6004/codenom-icon-mdiss-fuzz-framework-16.pdf) presents a framework for the application of fuzz testing as well as use cases in the medical and telecom industries.
Dale Nordenberg, MD
Executive Director
Medical Device Innovation, Safety and Security Consortium
[www.mdiss.com].
Jonathan Knudsen
Principal Security Engineer
Codenomicon, Ltd.
[www.codenomicon.com].
Medical devices are critical to our healthcare system. It is be-coming increasingly realized that the security profile of many net-worked medical devices may not be optimal, thus rendering the devices vulnerable to hacking or malware. There are a number of examples of medical devices that have been hacked including insu-lin pumps and implantable defibrillators, and it’s likely that many more medical devices are also vulnerable.
One of the key tactics hackers use to identify an exploitable vulnerability is fuzz testing. Importantly, this exact technique can be used to harden a medical device if manufacturers deploy it at the time of system design, build and testing. While fuzz testing alone is not sufficient to identify all medical device vulnerabilities, it does represent an important tool to further ensure that medical devices are as secure as possible and therefore plays an important role in the promotion of patient safety and privacy.
This article provides a brief introduction to fuzz testing, which the Medical Device Innovation, Safety and Security Consortium (MDISS) recommends using to make medical devices more secure. For those inter-ested in a more detailed review of fuzz testing and a structured approach to the deployment of fuzz testing, a white paper is accessible on the MDISS website in the latest public document section located at www.mdiss.org/media/6004/codenomicon-mdiss-fuzz-framework-16.pdf.
Fuzz testing or fuzzing is a technique for improving the safety and reliability of software and firmware in medical devices. Fuzz-ing locates unknown vulnerabilities and other defects by sending malformed and unexpected inputs to software.
Software and firmware are woven into the fabric of society. While technological advances can be exhilarating, corresponding risks have also emerged. When software or firmware does not work as intended, or when attackers use software and firmware for their own purposes, the consequences can be severe.
Nowhere is this risk more immediate than in the medical community where a patient is more likely to be exposed to one or more networked medical devices that are critical for diagno-sis or treatment. The scale of the exposure becomes clearer when one considers that the Center for Disease Control and Prevention (CDC) estimates that there are approximately 1 billion patient en-counters annually in the USA.
While the landscape of medical devices is very diverse, the software that runs each of these devices impacts quality of care and patient safety. Software quality and the process of hardening medi-cal device systems is important for all devices, including implant-able pacemakers, surgical robots, large machines delivering precise doses of life-saving radiation, or the electronic health records sys-tems that must safeguard protected health information (PHI) and the integrity of data that is used for clinical decision making.
The increasing complexity of software mandates vigilance to ensure that software works as intended. Unfortunately, software
Fuzz Testing Medical Devices: How to unmask Medical Device System vulnerabilities to Improve Safety and Privacy Profiles of Medical Devices
8 MEDS Magazine May 2013
PULSE
Profiles play a central role in the Bluetooth Specification. They define the entire proto-col stack, usually including the application layer. They
therefore allow interoperability of Blue-tooth devices on the application level. They also enable the features of a device to be limited to those necessary for the specific application, thus allowing small, energy-efficient designs.
The transmission of medical data via Bluetooth was not standardized for a long time. In general, the widely disseminated Bluetooth Serial Port Profile (SPP) has been used up to now. This ensured a certain amount of interoperability on the transport level, at least. However, SPP is merely a se-rial cable replacement and does not address the transported data. In the past this re-sulted in devices by different manufactur-ers that used different data transmission methods. As a result, every device manu-
facturer developed their own data protocol and then had to ensure that it could be un-derstood by the receiver.
For this reason, the Bluetooth SIG—the association of Bluetooth manufacturers—de-veloped the Health Device Profile. Although profiles have previously been developed with the use conditions of certain sectors in mind, the Health Device Profile is the first truly sector-specific profile. The use cases for the Health Device Profile correspond mainly to various types of patient monitoring.
With the Health Device Profile a few enhancements were introduced that are rel-evant to the transmission of medical data. These include exact time synchronization of multiple Bluetooth-connected sensors required for long-term measurements. An-other new feature is the ability to transmit different medical data in parallel over one Bluetooth interface. This is necessary when several sensors record measured values si-multaneously. Improved error correction
and resending of erroneous data have also been introduced.
The biggest difference, however, is the introduction of a protocol that describes the structure of the medical data itself. The so-called IEEE 11073 protocol replaces the former proprietary data protocols of manu-facturers, thereby enabling unprecedented interoperability on the application level. Device manufacturers can now concentrate on their own devices and do not have to provide a receiver for them. This protocol is a mandatory component of every HDP implementation.
Until now, the Health Device Profile has not been very widely disseminated. This might change in the near future as an HDP implementation is part of the Android 4.0 platform, which will allow suitably equipped Android smartphones and tablets to accept data from HDP-capable devices.
IEEE 11073While the Health Device Profile was
specified by the Medical Working Group of the Bluetooth SIG itself, the data protocol is provided in the IEEE 11073 specification.
IEEE 11073 specifies a data exchange format for medical devices. This format is independent of the transmission technology and can be used over different networks such as Bluetooth, USB and ZigBee. It defines the method used to pack and label medical data
by Florian Herrmann and Karsten Aalders, Stollmann
The Health Device Profile along with the IEEE 11073 protocol is enabling a number of specific medical devices to communicate data via multiple logical channels carried by a single master radio channel for compatible device communication.
Bluetooth Health Device Profile: Compatible Communication for Specialized Devices—Part 1
May 2013 MEDS Magazine 9
PULSE
so that the receiver can assign and display it. The protocol is based on binary data formats and includes time stamping and format-ting specifications. The standard includes so-called device specializations, similar to the Bluetooth profiles, in which individual devices are defined. The following device specializations are currently included:
• ISO/IEEE Std 11073-10404, Pulse ox-imeter
• ISO/IEEE Std 11073-10407, Blood pressure monitor
• ISO/IEEE Std 11073-10408, Ther-mometer
• ISO/IEEE Std 11073-10415, Weighing scale
• ISO/IEEE Std 11073-10417, Glucose meter
• ISO/IEEE Std 11073-10421, Peak ex-piratory flow
• ISO/IEEE Std 11073-10441, Cardio-vascular fitness and activity monitor
• ISO/IEEE Std 11073-10442, Strength fitness equipment
• ISO/IEEE Std 11073-10471, Indepen-dent living activity hub
• ISO/IEEE Std 11073-10472, Medica-tion monitor
The Health Device Profile is based on the Multi-Channel Adaptation Protocol (MCAP) and a Bluetooth stack that supports the enhanced Logical Link Control and Ad-aptation Protocol (eL2CAP) and exchanges IEEE 11073 data packets containing medi-cal user data in a defined manner over one or more data channels. eL2CAP is an en-hanced version of the L2CAP protocol that enables multiplexing of multiple logical data channels via a single radio connection. The enhancements in eL2CAP include the intro-duction of an additional error correction layer (Enhanced Retransmission Mode, ERTM) and support for streaming data transfer.
The eL2CAP Specification is included as an addendum to the Bluetooth 2.0 Core Specification and as an optional feature in the Bluetooth 3.0 Specification. Support of eL2CAP is essential for HDP implemen-tation. MCAP is used in an HDP imple-
mentation to control the establishment and disconnection of eL2CAP data channels in HDP in a defined manner. To this end, when a connection is made, one eL2CAP channel is established as the MCAP con-trol channel. Use of this channel is limited exclusively to the MCAP protocol.
MCAP then uses this control channel to control the establishment of additional eL2CAP channels for defined “end points” (MDEP), which can then be used for the actual IEEE 11073 data transmission. In doing so, each end point maps a defined IEEE device specialization. Thus, for ex-ample, an HDP device can display the ap-propriate measurement values via an “IEEE 11073-404 Pulse Oximeter” end point and provide a data channel for this end point. Several such end points with different functionality are also possible.
In summary, the structure of an HDP connection is described in Bluetooth ter-minology as shown in Figure 1. The same connection is described in IEEE 11073 ter-minology as shown in Figure 2.
Once a data channel has been estab-lished for IEEE 11073 data transmission, it can be used for transmission of IEEE 11073 packets (Figure 3). The segmentation and retransmission (SAR) functionality in eL2CAP is used here in order to transmit complete IEEE packets including packet headers. For this purpose, an IEEE applica-tion data unit (APDU), which describes a complete IEEE data packet, is transmitted as an eL2CAP service data unit (SDU). The eL2CAP-SDU can be segmented into indi-vidual protocol data unit (PDU) packets
for this transmission and then reassembled again on the receiver side using the SAR functionality. HDP is thus logically not re-alized on a byte stream transport layer but rather on a secure packet transmission layer (ERTM) that transmits complete packets.
This effort is made in order to meet the requirements of IEEE 11073 regard-ing transport characteristics. Among other things, these requirements call for secure data transmission of complete IEEE-APDUs up to 63 Kbytes in size. Incidentally, this amount comes from the fact that the oth-erwise usual 64 Kbytes has been accepted as the maximum packet size of the lower level transport layers and these layers are granted 1 Kbyte as protocol overhead. The design of IEEE 11073 took into consideration di-verse requirements regarding data integrity, uniqueness and usability in the medical and clinical environments so that internationally approvable implementations are possible.
The measurement data source is called “source” in Bluetooth HDP and “agent” in IEEE 11073, while the data sink is called “sink” in Bluetooth HDP and “manager” in IEEE 11073. The required behavior of the data source and data sink are practically identical up to this point, as both sides es-tablish and terminate connections and data channels and transmit data packets. That changes on the IEEE 11073 protocol level, as the roles are distributed asymmetrically here. The basic assumption here is that the IEEE agent is the “simple” measure-ment device that has a very specific limited functionality that it communicates to the manager prior to actual data transmission.
“radio connection”
HDP Connection
RemoteDevice
Endpunkt
LocalDevice
Endpunkt
MCAP Control Channel
MCAP Data Channel
Figure 1 Structure of an HDP connection.
10 MEDS Magazine May 2013
PULSE
The IEEE manager on the other hand is the “complex” device that can exchange data with all possible agents. The manager should therefore be generic because the IEEE 11073 protocol is structured to be essentially self-describing using the ASN.1 specification language.
Thus, the protocol allows a generic im-plementation approach in which the IEEE manager application processes the medical measurement data (e.g., displays, saves, or forwards data) without having to under-stand or interpret it in the functional sense. For example, body temperature measure-ments consist of a numerical value and unit and are shown as a measurement value with unit symbol on a display, further processed as trend curves, or saved in databases with-out a generic IEEE manager implementa-tion having to know what a temperature is or what it signifies. Of course, this approach also applies to all other existing and future device specializations of IEEE 11073.
Implementation/Practical Experience
In view of the complex specification, an HDP implementation project will prob-ably go through several phases: “Does it have to be so complicated?” followed by:“Okay, it’s actually not so complicated, and in the end the structure will produce a well-
thought-out solution.” and then:“The devil is in the details.” and finally:“It took a while but now I truly understand how all of this works together.”
The “Does it have to be so complicated?” phase of an HDP implementation occurs as the various specifications are being acquired. In the eL2CAP chapter of the Bluetooth Core Specification and the IEEE specifica-tions, in particular, it seems that mecha-nisms that are actually quite simple can only be described in an understandable way with great difficulty. The specifications use for-mal speech that in some cases deviates far from natural speech and can produce arti-ficial, difficult-to-understand and unwieldy sentences. There is definitely a reason for this, but those without experience perform-ing such tasks must work ahead to “The devil is in the details” phase to recognize this.
Once the actual implementation starts, the “Okay, it’s actually not so complicated, and in the end the structure will produce a well-thought-out solution” phase arrives relatively soon and can last until the first test runs. “The devil is in the details” phase kicks in as soon as the first design- or development-re-lated test runs take place. Here is where the specifications start to be examined again, this time with a very keen eye. It is now ap-parent that there is definitely a good reason
for many of the complicated definitions that initially seemed unnecessary. It is also now clear whether or not the theoretical prepa-rations made for the implementation were adequate. If so, the existing implementation can be fine-tuned. If not, it is advisable to start over. Successful navigation beyond this point brings you to the “It took a while but now I truly understand how all of this works together” phase, where there is still some nec-essary fine-tuning left to do.
Anyone that has had the experience of developing communication protocols based on specifications is familiar with this process in principle. The reason for this process is not necessarily poor theoretical preparation, but rather it can also be the fact that it may be impossible to link all of the hidden details of a complicated specification until its actual implementation. The message here is that the difficulty of the HDP implementation task should not be underestimated, owing to the different protocols involved and the often inherent level of complexity of these protocol layers. Incorrect decisions during system design can result in unnecessarily high demands on system resources (CPU, RAM, Flash). Once the HDP implementa-tion is finished, however, the very generic and well-conceived system approach behind HDP ensures that the result will be suitable for universal use in the home setting as well as in medical and clinical environments.
This broad application range can be attributed to the fact that the individual specifications were developed by groups of technical experts including representatives of companies active in the respective sec-tors. These experts spent several years de-bating with each other about the various details and requirements. The list of com-panies that collaborated on the specifica-tions includes Stollmann, which actively participated in the Bluetooth SIG MED Working Group and the IEEE 11073 Working Group.
Don’t miss Part 2 of this article, which will drill down further into special design considerations and integration details. Com-ing in the next issue of MEDS!
Stollmann E+VHamburg, Germany.+49 (040) 89088-0.[www.stollmann.de].
ACL Connection
MCL Connection
RemoteDevice
MDEP
LocalDevice
MDEP
Control Channel
MDL
Figure 2 Structure of an HDP connection with IEEE 11073.
PDU 1 PDU 2 PDU n
IEEE 11073 APDU
SDU start segment SDU continuationsegment
SDU endsegment
msgheader
msgheader
msgheader
Figure 3 Data transmission with IEEE packets.
UL and the UL logo are trademarks of UL LLC. © 2013. BDI 30317
Full lifecycle testing, certifi cation, regulatory, quality systems and regulatory-focused
learning support for the Health Sciences industries. Our line of services includes:
CMDCAS
MDDIVDD
LEARN WHERE YOU CAN GO WITH UL, VISIT US AT WWW.UL.COM/MEDS
WITH ULGO FURTHER
Untitled-8 1 3/26/13 12:45 PM
12 MEDS Magazine May 2013
PULSE
whether at the blackjack table or in the mar-ketplace, is it not preferable
to have the deck stacked in your fa-vor? Wouldn’t you rather play blackjack knowing you have a significant advan-tage of winning? The same is true with developing new products. With develop-ment and production costs continuously escalating and profit margins shrinking, anything that can be done to minimize development costs and maximize mar-ket preference will improve product profitability.
When the FDA started requiring human factors/usability testing of medi-cal devices, they were actually stack-ing the deck in favor of medical device manufacturers. Yes, that is right. Hu-man factors/usability testing is actually
a win/win for medical device manufac-turers. Let me explain.
Human Factors Engineering is based on research, scientific/experimental method, statistics, human physiology and cognitive information processing. It is the combination of engineering, human physi-ology, behavioral performance and cogni-tive science. Human Factors Engineering is a scientific discipline that studies how humans interact with devices, products and/or systems. It approaches design with the user as the focal point. Human Factors Engineering ensures that devices, products and systems are safe, effective and usable by their intended users.
The FDA requires device manufac-turers to create a use-based risk analysis for their products. By creating this risk analysis, medical device manufactur-ers do a thorough examination of their product(s) from the point of view of the
user. The risk analysis then becomes the basis of the human factors/usability test-ing. One important aspect of the risk analysis is the proposed mitigations for high-risk/high-frequency tasks. Instruc-tions for use, training and product patient inserts are no longer considered appro-priate mitigations. Instead, appropriate mitigations must be related to the design of the device. So, how do you know that these design mitigations are accurate? That is where human factors/usability testing comes into the picture.
Here is where you can start stacking the deck in your favor. You see, Human Factors have methods to evaluate those mitigations early in the product develop-ment cycle. The FDA calls these forma-tive testing/methods. These tests are eval-uative in purpose. Getting your product in front of users will quickly tell you if your design mitigations are accurate. In addition, it will give you the opportunity to make changes to your product very early in your product development cycle. As you know, identifying product prob-lems early in the cycle will enable lower cost changes than if you waited until just before launch. What goes into a forma-tive test?
Formative testing uses a prototype of the device and puts it into the hands of
by David Hirning MS and virginia A Lang, PhD, HirnLan, Inc.
Get ahead of stringent design cycles by evaluating the human factors and usability of a device early in the process. When the demands for meeting these requirements come from the FDA, as they almost certainly will, your product and your team will be ready.
FDA Human Factor Requirements Change the Landscape of Medical Device Development
May 2013 MEDS Magazine 13
PULSE
users (Figure 1). But how do you identify the users of your products? The first thing is that users and customers are not always the same. Users are those who will person-ally use your product. There could be more than one user of your product. You need to identify all the users and how they would use your product. You are identifying these users for the purposes of testing your prod-uct, not for marketing. You are identifying these users so that you can put your prod-uct into their hands early in the product development cycle.
How many users do you need for the formative testing? The magic num-ber is eight, yes eight—eight from each user group that would have the highest risk/highest frequency tasks using your product. For example, if the device were a ventilator, then there are several dif-ferent types of users: the technician who calibrates the ventilator, the respiratory therapist, the nurse, the caregiver and the physician. Do you need eight of each for the formative testing? No. You need the users who perform the highest risk/high-est frequency tasks. In this case it would be the technician, the respiratory therapist and the caregiver, for a total of 24 test par-ticipants. Why the caregiver? The FDA is paying particular attention to caregivers who use medical devices, even if it’s just to monitor the output. The reason the FDA considers caregivers to be the highest risk user group is because they are not profes-sionally trained.
Your next questions are probably: how long does formative testing take, and how much does it cost? In terms of time, two weeks of preparation, two to four days of testing and two weeks to obtain the report. Yes, that amounts to about five or six weeks. Now, the cost—that depends upon a number of different variables. If your user groups are medical professionals, then it is going to cost more for participant recruiting and incentives than if your user groups are caregivers or patients. There are costs for the facili-ties used for the testing, creation of the
test plan, facilitation of the test and the report writing. I know you would like a number. Formative tests can cost as little as $25,000 up to about $55,000. These are only rough estimates.
The FDA recommends formative hu-man factors/usability testing, but does not require it. So why should you do it? Remember, you are trying to stack the deck in your favor for getting a prod-uct that is safe, effective, usable and ap-proved by the FDA in the shortest time possible. Finding out you have some se-rious design problems with your device early in the development cycle will cost less to fix than if you find out at the end of the product development cycle. You might actually want to do two or three rounds of formative human factors/us-ability testing. Then when you get to the summative testing, you are assured that you have mitigated all of the risks through design changes.
What is a summative human factors/usability test? The summative test is the
final test, which renders a pass/fail judg-ment on a device, product or system. This test validates that the device, product or system is safe, effective and usable by the all intended user groups. It differs from the formative test in that now you have to use a device that represents exactly the device that is going to be launched to the market. So you are not using prototypes. In addition, you must have at least 15 users for each and every user group that will use your product. In the example of the venti-lator, that means you would have five dif-ferent user groups, or a minimum of 75 test participants. Each user group in this case would have different tasks with respect to using the ventilator and so the test tasks will be different for each group. I think you can figure out that the cost of a summative human factors/usability test is considerably more than a formative human factors/us-ability test. I am sorry to say that provid-ing an estimated cost is very difficult. With that said, in our experience we have found that the minimum cost is about $50,000.
IFU Summative Testing
Formative Testing
Expert Review / Risk Assessment
Number of Possible DesignsCost of Change
Envisioning Planning Developing Stabilizing Deployment
Figure 1 Formative testing sits at the center of the development cycle to align the actual model of human interaction with the ultimate design of the device or system.
14 MEDS Magazine May 2013
PULSE
That is for one user group comprised of non-medical professionals.
Here are a few questions I am fre-quently asked:
Question 1: If formative tests are not required, why should I spend the money?
Answer: Formative tests provide an-swers in the early stages of product devel-opment, when changes are relatively small compared to changes required after a sum-mative test.
Question 2: Why should I conduct a formative test on my information for use?
Answer: In much the same way a for-mative test looks at a prototype providing design insight early for design mitigation, the information for use evaluation study (a formative test) can mean the difference of passing/failing a summative test. We have seen summative test disasters directly re-lated to the information for use.
Question 3: Marketing has already put the product in front of users and the users all liked it and would purchase it. The users even said they thought it would be safe and usable. Why can’t I just use those results?
Answer: Marketing uses product con-cepts and asks users to give their opinion. Human factors/usability testing is evaluat-ing user performance using the product in an environment that is similar to where the product would be used. These are one-on-one testing sessions using strict scientific/experimental methods.
Question 4: I understand everything, you are right and I will incorporate Human Factors Engineering into my next product. However, I am at the end of the product cycle. My product is ready to ship—what do I do now?
Answer: It’s never too late to in-volve a human factors engineer. You should have a human factors engineer perform an expert review to fully under-stand the risks moving into a summative test. You should have an Information for Use evaluation study (a formative test) completed to be sure your Information For Use does not hinder the user from successful completion of the summative test tasks. The next step, as appropri-ate, is to complete the summative test. Just remember, you may not pass the summative test without product design modifications.
Question 5: You keep mentioning a human factors engineer. How do I know if I am engaging a reputable firm/individual?
Answer: That’s a tough one. It would be simple to say look for an individual with a PhD in Human Factors Engineer-ing. But remember, Human Factors Engi-neering is the intersection of engineering, human physiology, behavioral and cogni-tive science. I would suggest a graduate degree in any of those fields with experi-ence. I would look to recommendations from friends and/or colleagues. I would be careful if the team running your testing is not the same as the team you talked to in the beginning. If it’s too good to be true—it probably is.
Question 6: I didn’t budget for hu-man factors/usability testing. Can I submit my 510(k) to the FDA anyway?
Answer: Yes, you can submit the 510(k). However, if your device is consid-ered a Class 3 or Class 2 device, is a com-bination device, an infusion pump, a ven-tilator, a surgical instrument, a monitoring device, or a device used by patients and or/caregivers, then you will get “the letter.” The letter will state that you need to do hu-man factors/usability testing.
So imagine a blackjack table that al-lows you to turn over all the cards and actually arrange the cards before they are dealt. This is what the FDA has provided with the human factors requirements. With each formative test you get to arrange the cards. You will know early in the develop-ment cycle what the risks are and will have mitigated them—when the cost of change is still minimal. Run an evaluation study on the Information for Use (a formative test). You will then know that the Infor-mation for Use is accurate, understandable and easy to use.
It’s now time to run the summative test. How much did it cost to engineer/design your product? Don’t worry, let it ride. The cards are dealt...blackjack! But you knew that, you stacked the deck. You submit your 510(k) to the FDA…black-jack again! But again, you knew that, you stacked the deck. You followed best prac-tice during the product design/develop-ment process.
The recommendations and require-ments of the FDA to do human factors/
usability testing are actually the same best practice for creating safe, effective, usable and profitable products in any industry. Minimize development costs, maximize market preference—the result, profitable products. Sound familiar? How many iPhones are used everyday? Em-brace best practice, build safe, effective and usable products. Stack the deck. The FDA’s recommendations and require-ments empower you to stack the deck in your favor.
Medical Device Human Factors by HirLanCarlsbad, CA.(619) 301-2073.[www.MedicalDeviceHumanFactors.com].
Th e Medical Electronic Device Solutions Magazine provides you with the convenience of Print editions, eBook versions, PDFs and the MEDS magazine website. Th e online editions have additional updated press releases, articles and interviews of leaders in the medical technology industry. Stay up to date with all the latest MEDS news through the MEDS eNewsletter.
Signing up for the eNewsletter is simple.
You’ll receive a message about confi guring your subscription and a confi rmation.
www.medsmagazine.com
TEXT THE CODE MEDS TO 33233
OR SCAN THIS CODEAND SEND THE MESSAGE
medsmobile_v1.indd 1 5/3/13 3:01 PM
16 MEDS Magazine May 2013
PULSE
Based on industry statistics, it is obvious that intensi-fied regulatory scrutiny has become a harsh reality for medical device manufac-
turers. Over the last several years, medi-cal device companies have been hit with injunctions, undergone product recalls, or found themselves operating under Food and Drug Administration (FDA) consent decrees. FDA regulations seem to impact every step of the medical device lifecycle from properly classifying a device and de-veloping a regulatory strategy, to preparing FDA submissions. So, just how are suc-cessful medical device manufacturers cost-effectively achieving compliance while at the same time meeting their product de-livery targets?
Keeping the Pace: Technology is Key
The Millennium Research Group, an authority on medical technology market intelligence, anticipates that device manu-facturing executives will rely on technol-ogy solutions to overcome some of these regulatory burdens and save costs in hopes of recuperating lost profits from the Pa-tient Protection and Affordable Care Act of 2010’s recent addition of excise tax on medical devices.
Due to the fast pace of new technol-ogy, emerging market opportunities and competition from start-ups, medical device executives find themselves in an environ-ment where they must continually innovate with flawless execution to survive. They are turning to their IT gurus and engineering
architects for technology solutions and discovering that next generation product lifecycle management (PLM) systems may very well be the most valuable investment medical device manufacturers can make for their medical device development process. Identifying a clear methodology and an ef-ficient and cost-effective path through the medical device development lifecycle can increase a manufacturer’s speed to market while ensuring compliance. According to Frost and Sullivan’s Industry Analyst Saju John Mathew, “what is key is that the right steps are taken at the right times and are properly documented for FDA compliance and approval, avoiding the need to repeat phases—a misstep that can be extremely costly in both time and capital—and can throw a medical device manufacturer way off course.”
An inherent need to streamline busi-ness operations is driving more and more medical device companies to adopt PLM technology in order to be able to properly design safe, effective and compliant prod-ucts. The mandates outlined in the FDA regulations related to medical device de-velopment protocol such as Part 11 of Title 21 of the Code of Federal Regulations (21
by Eric Marks, Price Waterhouse Cooper
A paper trail is no longer acceptable. Meeting the stringent requirements for FDA compliance as well as meeting challenging time-to-market deadlines requires automation. Product life cycle management systems can make a big difference for both goals.
Medical Device Manufacturers Address Compliance Mandates with Product Lifecycle Management
May 2013 MEDS Magazine 17
PULSE
CFR Part 11) and 21 CFR Part 820 Qual-ity System, cover everything from device design and manufacturing to training and installation, to processing inquiries and/or complaints.
Meeting the requirements of CFR Part 11 and Part 820 regulations can determine the success or failure of a medical device manufacturing company. To be compli-ant with the Part 11 regulations, manu-facturers who track their documentation electronically must meet the electronic records and electronic signature guidelines set forth by the FDA. Part 820 requires manufacturers to have a quality system for the design, manufacture, packaging, la-beling, storage, installation and servicing of finalized medical devices. Clearly these regulations require exceptional informa-tion management techniques and can of-fer a daunting challenge to manufacturers, many of whom have traditionally relied on manual or semi-automated solutions to manage product development. Attempting to manage and access this information in a paper-based fashion can prevent medi-cal device manufacturers from adequately complying with FDA regulations.
As a central database, PLM manages the numerous bill of materials (BOMs), engineering changes, parts and associ-ated documents created during the de-sign process. Medical device manufactur-ers can easily maintain, access and report on required information such as a device master record (DMR), design history re-cord (DHR) or design history file (DHF). Additionally, in following CFR Part 11 guidelines for managing information elec-tronically, PLM technology can support the required password protected signoffs, authorized electronic signatures and his-tory tracking for complete electronic audit trails. Security features to control accessi-bility to information such as defined user roles address security guidelines. Lastly, next generation PLM systems typically offer quality management and training records management capabilities, which support requirements for meeting Part
820 Quality System guidelines. The abil-ity to manage the complete product record and address quality system requirements with PLM can save device manufacturers time and money by streamlining the entire product development process and eliminat-ing the need to invest in separate systems.
Case in Point—The Pathway to PLM
One such company, Pathway Medi-cal Technologies, a Kirkland, WA-based innovator of endovascular treatments for Peripheral Arterial Disease (PAD) and maker of a device that clears out blockages in clogged leg arteries, uses PLM technol-ogy and received FDA 510(k) clearance in 2009 to market its Jetstream G3 periph-
eral atherectomy catheter for use in the treatment of PAD in the lower limbs (be-low the knee).
Ken Perino, Sr. Director of Quality Assurance & Regulatory Compliance at Pathway Medical Technologies, was the one to spearhead Pathway’s initiative to au-tomate their product development process. Having worked in previous medical device start-ups, Mr. Perino had become well versed in the benefits of a PLM system to support his efforts. Perino implemented the Empower PLM solution from a company called Omnify Software in order to stream-line the entire engineering change process, implement better control with document vaulting, improve Bill of Material (BOM) management, and make product informa-
Figure 1 Jetstream Navitus from Pathway Medical is designed with an expandable cutting tip for use in debulking and treating vascular disease in the periph-eral vasculature. The catheter includes distal ports located at the tip, which are designed to provide independent infusion and aspiration functions for the active removal of fluid, excised tissue and thrombus from the peripheral vascular treatment site.
18 MEDS Magazine May 2013
PULSE
tion (drawings, blueprints, revisions and supporting materials) easily yet securely ac-cessible to appropriate team members.
His guidance to other medical device companies is that they should look for PLM solutions that are easy to use, fast to deploy and very affordable without skimp-ing on essential PLM functionality. Too often the biggest problem with many PLM tools on the market is that they have be-come more complicated without becoming more functional. It is very difficult to solve a complex problem with a complex tool ,and a much better solution is choosing a PLM approach that is straightforward. At Pathway Medical, document control, en-gineering change, BOM and regulatory conformance processes are managed via the Omnify Empower PLM system (Figure 2). All departments that have governing procedures are using the system including: design engineering, quality, regulatory, manufacturing engineering, purchasing operations and even facilities management. Any changes made to any procedures are performed and managed within the PLM system.
“Gone are the days that a physical folder is being passed around and emails are flying around in regards to where the folder is in terms of going through the different teams for an engineering change,” said Mr. Perino. “Because Omnify completely automates our
process, when you submit your engineering change for review, the system sends it out to everyone who is a signer or observer in paral-lel, and the engineering team can view engi-neering changes in real time.” This level of automation not only makes Pathway Medi-cal’s process more efficient, but also provides a better documentation trail for auditors and compliance purposes.
Simplifying the Audit Process
Medical device manufacturers are re-quired to have formal processes in place to manage data for all facets of design and development such as: change control, sup-plier management, corrective and preven-tive actions (CAPAs), inspection and test procedures. In addition, evidence must be presented that formal processes are being ad-hered to. Not only can a system that provides traceability and clear tracking of procedures and sign-offs facilitate this, it’s the law.
PLM technology delivers a controlled environment for managing and tracking product data through automated processes, which is critical to achieve compliance. The visibility into the complete product record and management of all product information within one environment cer-tainly helps to ease the audit process. In the case of Pathway Medical, the company is required to meet International Organi-
Figure 2 The Empower PLM system from Omnify Software covers all phases of the product life cycle including product management, training records, BOM and change management, documentation, vendor data and much more through a single database that is available to and can be configured for all project members in terms of their specific functions.
Untitled-7 1 4/3/13 10:42 AM
May 2013 MEDS Magazine 19
PULSE
zation for Standardization certification (ISO 9001:2008 international standard). ISO auditors check to see how Pathway (or any company they are auditing) man-ages its product documentation, change orders/change management and engineer-ing processes. Prior to automating with a PLM system, Pathway Medical would have had to show and explain its manual pro-cess, walk an auditor through all of their documentation, and search for requested documents in folders and file cabinets—a cumbersome process.
Adopting a PLM system to central-ize all product-related information and properly track data allows medical device manufacturers like Pathway to easily find required information for auditors, gener-ate custom reports as needed and prove out their processes. PLM systems make all this required information available at a person’s fingertips so that it can be easily presented to auditors.
Successful StrategiesWhat is top of mind today among
medical device manufacturers is the need to attain a better understanding of which strategies are being successfully used to en-sure device quality in the face of regulatory uncertainty. Cambashi, a global industry analyst and market consulting firm, sees that while the global market and supply base for medical device manufacturers offers new opportunities for innovation and growth, it also brings new challenges for keeping costs and risks low, especially in such areas as R&D, sourcing, manufacturing, quality assurance, regulatory compliance, supply chain and financial operations. Cambashi has recently conducted a study to identify the major challenges to and approaches for balancing innovation, cost, growth and risk among medical device companies and their trading partners. It explores whether com-panies are deploying the strategies that regu-lators suggest, and the information systems to support them. It aims to outline practices and systems that medical device compa-nies should consider to ensure optimum throughput and quality.
Compliance Dynamics, a services company specializing in helping medical device companies with their business man-agement systems, operational and regula-tory compliance needs, knows this well and
has been helping medical device companies navigate their way around these obstacles through the use of sophisticated systems and technology. “It’s no longer just about proving to the FDA that your company has effectively addressed the required (regu-lated) processes, but that you’re a soundly run business as well. This is where a solid PLM system implementation can shine. The FDA has made it clear that they want companies to fulfill the regulatory require-ments while demonstrating they can be successful as businesses. After all, having a medical device on the market and the manufacturer out of business is a loss-loss for all parties involved,” said Roger Martin, President of Compliance Dynamics.
Rapid industry growth, competition, the regulatory environment and an in-herent need to streamline operations, are driving more and more medical device manufacturers to adopt technology solu-tions like PLM. The bottom line for medi-cal device companies trying to compete in today’s high-tech world is that adopting new software technologies is no longer a luxury or superfluous to a company’s suc-cess. Rather, it is an essential key to success in an industry that has become overwhelm-ingly competitive and regulated.
Price Waterhouse Cooper[pricewaterhousecooper.com].
CambashiCambridge, UK.+44 (0) 1223 460439.[www.cambashi.com].
Compliance DynamicsSunnyvale, CA.(408) 462-9222.[www.mycdyn.com].
Millenium Research GroupTotonto, Ont.(416) 364-7776.[www.mrg.net].
Omnify SoftwareTewksbury, MA.(978) 988-3800.[www.omnifysoft.com].
Pathway Medical TechnologiesKirkland, WA.(425) 636-4000.[www.pathwaymedical.com].
Untitled-7 1 3/26/13 12:44 PM
Does beating your competition to market matter? We think so!Get your medical product to market quicker with congatec’s conga-TS77.congatec...we are Computer-On-Modules.
conga-TS77 3rd Generation Intel® Core™ processor-based platform
COM Express® Type 6 Module with PCI Express®, SATA, USB, 3x HDMI / DisplayPort
Improved Graphics Performance, DirectX®11
adv2.indd 1 7/31/12 4:32 PM