MEDS magazine

MEDICAL ELECTRONIC DEVICE SOLUTIONS MEDICAL ELECTRONIC DEVICE SOLUTIONS

MEDICAL ELECTRONIC DEVICE SOLUTIONS

MEDICAL ELECTRONIC DEVICE SOLUTIONS

MEDICAL ELECTRONIC DEVICE SOLUTIONS MEDICAL ELECTRONIC DEVICE SOLUTIONS

MEDS MEDICAL ELECTRONIC DEVICE SOLUTIONS

Using Human Factors to Shape Device Development Meet FDA Compliance with Lifecycle Management An RTC Group Publication

A Supplement to RTC magazine

Envision Quality Patient Care ZLWK ,%$6( (PEHGGHG 6ROXWLRQV $V DQ LQGXVWU\ OHDGHU LQ (PEHGGHG &RPSXWLQJ IRU PRUH WKDQ D GHFDGH ,%$6( FRQWLQXHV WR SURYLGH TXDOLW\ 2(0 2'0 GHVLJQ DQG SURGXFWLRQ WKDW WDLORUV WR \RXU HYHU\ KHDOWKFDUH VHUYLFLQJ QHHGV /HW XV NQRZ KRZ ,%$6( FRXOG EH SDUW RI \RXU KHDOWKFDUH H[SHULHQFH

,%$6( (PEHGGHG 6ROXWLRQV ZLWK $0' (PEHGGHG $38 7HFKQRORJ\ 3DWLHQW &DUH 0HGLFDO 6\VWHP %67

Â? (PHUJHQF\ %XWWRQ 'XDO 6SHDNHUV Â? 5),' 5HDGHUV Barcode Scanner Â? %XLOW LQ 3KRQH +DQGVHW

Â? ,& &DUG 5HDGHU ([SDQVLRQ 6ORW Â? )LQJHUSULQW $XWKHQWLFDWRU 2SWLRQDO

Â? (WKHUQHW /$1 &RQQHFWLYLW\

u,%$6( LV &HUWLILHG ZLWK ,62 4XDOLW\ $VVXUDQFH DQG ,62 LQ 'HVLJQ DQG 0DQXIDFWXULQJ 0HGLFDO 'HYLFHVv

Â? v /&' ZLWK ,3 6HDOHG )URQW 3DQHO Â? &DSDFLWLYH 3RLQW 0XOWL WRXFK 3DQHO Â? $QWL %DFWHULDO 0LWHV $OFRKRO :LSH 3DQHO Â? :HE &DPHUD ZLWK ,QGLFDWLRQ /LJKW

Embedded Mainboards p 'LVN 6L]H 6%&V

COM Express

Â? $0' (PEHGGHG 1 / 3URFHVVRU Â? &RPSDFW ZLWK /RZ 3RZHU &RQVXPSWLRQ Â? ([SDQVLRQ 6ORW '9, /9'6 $YDLODEOH Â? 4XDOLW\ &XVWRPL]DWLRQ 0DQXIDFWXULQJ Â? 5LFK , 2 RQERDUG *E( /$1 56 6$7$ ,,

Â? $0' (PEHGGHG 1 / 3URFHVVRU Â? '9, /9'6 $YDLODEOH Â? 4XDOLW\ &XVWRPL]DWLRQ 0DQXIDFWXULQJ Â? 6XSSRUWV 'XDO &KDQQHO ''5 0HPRU\

6WHZDUW 'ULYH 6XQQ\YDOH &$ 86$ _ 7HO _ (PDLO LQIR#LEDVH XVD FRP _ ZZZ LEDVH XVD FRP Corporate names and trademarks stated herein are the property of thier respective companies. Copyright Š 2013 IBASE Technology, Inc. All rights reserved.

The Industry Leader in Embedded Computing

MEDS CONTENTS

MEDICAL ELECTRONIC DEVICE SOLUTIONS

may 2013 UP FRONT

PULSE

5

8

EDITORIAL

Bluetooth Health Device Profile: Compatible Communication for Specialized Devices— Part 1 Florian Herrmann and Karsten Aalders, Stollmann

Medical Devices and Remote Access—Extending the Reach of Medical Expertise Tom Williams

6 publisher's letter

The Med Tech Food Chain John Koon

FOCUS 7 innovation higlights

A Collection of What's New, What's Now and What's Next

12 FDA Human Factor Requirements Change the Landscape of Medical Device Development David Hirning MS and Virginia A Lang, PhD, HirnLan, Inc.

16 Medical Device Manufacturers Address Compliance Mandates with Product Lifecycle Management Eric Marks, Price Waterhouse Cooper

M

edical 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, designers 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 computing market. Learn more about MEDS at www.medsmag.com.

SPONSORS Axiomtek...................................................................19 Commell....................................................................18 congatec................................................................. 20 iBase...................................................................................2 Intelligent Systems Conference and Pavilion....................4 MSC Embedded...............................................4 UL............................................................................................11

digital subscriptions available

www.medsmag.com

May 2013 MEDS Magazine

3

EMBEDDED SOLUTIONS R-SERIES APU

MSC Embedded Inc. Tel. +1 650 616 4068

MEDS MEDICAL ELECTRONIC DEVICE SOLUTIONS

info@mscembedded.com www.mscembedded.com

PRESIDENT

John Reardon, johnr@rtcgroup.com

PUBLISHER

COM Express™ - MSC C6C-A7

John Koon, johnk@rtcgroup.com

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 definition 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 GHz R-260H dual-core, 2.1/2.6 GHz R-252F dual-core, 1.7/2.3 GHz

V-3_2013-WOEI-6376

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

EDITORIAL EDITOR-IN-CHIEF Tom Williams, tomw@rtcgroup.com MANAGING EDITOR/ASSOCIATE PUBLISHER Sandra Sillion, sandras@rtcgroup.com COPY EDITOR Rochelle Cohn

ART/PRODUCTION ART DIRECTOR Kirsten Wyatt, kirstenw@rtcgroup.com GRAPHIC DESIGNER Michael Farina, michaelf@rtcgroup.com WEB DEVELOPER Justin Herter, justinh@rtcgroup.com

ADVERTISING/WEB ADVERTISING Untitled-4 1

3/1/13 12:17 PM

VP OF MARKETING Aaron Foellmi, aaronf@rtcgroup.com MEDS SALES ACCOUNT MANAGER Jasmine Formanek, jasminef@rtcgroup.com (949) 226-2004

BILLING

Cindy Muir, cmuir@rtcgroup.com (949) 226-2021

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 Group Copyright 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.

4

Untitled-3 1

MEDS Magazine May 2013

5/3/13 11:41 AM

UP FRONT EDITORIAL

Medical Devices and Remote Access—Extending the Reach of Medical Expertise

S

tepping 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, reveals 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 imperative 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 contribution 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 personnel 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 symptoms, 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 facilities that will surely soon arise. But let us remember—they exist primarily as extensions of medical knowledge and experience, not as replacements for it.

Tom Williams Editor-in-Chief

May 2013 MEDS Magazine

5

UP FRONT PUBLISHER’S LETTER

The Med Tech Food Chain

T JOHN KOON Publisher

Software & Hardware Components

Device Makers

FDA Consultants

6

MEDS Magazine May 2013

he 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 consultant 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 prodHospitals ucts. The important questions are, “How safe is safe enough?” and “How do I know about and manage the risks associated with purchasing these medical technologies and products?” The stakes are high here. We hear stories about car manufacturers recalling automobiles because they accelerated unTest controllably or caught fire in a collision, or of manufacturers recalling baby Agencies 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 delivered 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 Innovation, 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 Security Consortium, MDISS, will lead a panel on “Understanding the Medical Device Procurement Process by the Hospitals.” Also included will be presentations relating to Fuzz testing, FDA 510(k) Clearance, a Home Healthcare panel and other relevant medical technologies. www.issconference.com.

FOCUS

INNOVATION HIGHLIGHTS

A COLLECTION OF WHAT'S NEW, WHAT'S NOW AND WHAT'S NEXT Fuzz Testing Medical Devices: How to Unmask Medical Device System Vulnerabilities to Improve Safety and Privacy Profiles of Medical Devices Medical devices are critical to our healthcare system. It is becoming increasingly realized that the security profile of many networked 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 insulin 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 interested 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. Fuzzing 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 diagnosis 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 encounters 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 medical device systems is important for all devices, including implantable pacemakers, surgical robots, large machines delivering precise doses of life-saving radiation, or the electronic health records systems 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

frequently fails in the face of unexpected or malformed inputs, also called fuzz. Fuzz can happen when software encounters realworld 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 presence of invalid inputs or stressful environmental conditions. Having a properly functioning system, despite the unpredictable, is essential in the medical systems world in order to keep patients alive and information confidential.

Fuzzing is appropriate for medical device manufacturers, computing 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 isolated 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 software development life cycle. Finding and fixing more bugs during product development will result in products that are safer, more robust 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 strategies or recalls in the postmarket period.

The full white paper (www.mdiss.org/media/6004/codenomicon-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].

May 2013 MEDS Magazine

7

PULSE

Bluetooth Health Device Profile: Compatible Communication for Specialized Devices—Part 1 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.

by Florian Herrmann and Karsten Aalders, Stollmann

P

rofiles play a central role in the Bluetooth Specification.

They define the entire protocol stack, usually including the application layer. They therefore allow interoperability of Bluetooth 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, energyefficient 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 serial cable replacement and does not address the transported data. In the past this resulted in devices by different manufacturers that used different data transmission methods. As a result, every device manu-

8

MEDS Magazine May 2013

facturer developed their own data protocol and then had to ensure that it could be understood by the receiver.

For this reason, the Bluetooth SIG—the association of Bluetooth manufacturers—developed 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 relevant to the transmission of medical data.

These include exact time synchronization of multiple Bluetooth-connected sensors required for long-term measurements. Another 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 simultaneously. 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 manufacturers, 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 11073 While 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

PULSE

so that the receiver can assign and display it.

The protocol is based on binary data formats and includes time stamping and formatting 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 oximeter • ISO/IEEE Std 11073-10407, Blood pressure monitor • ISO/IEEE Std 11073-10408, Thermometer • ISO/IEEE Std 11073-10415, Weighing scale • ISO/IEEE Std 11073-10417, Glucose meter • ISO/IEEE Std 11073-10421, Peak expiratory flow • ISO/IEEE Std 11073-10441, Cardiovascular fitness and activity monitor • ISO/IEEE Std 11073-10442, Strength fitness equipment • ISO/IEEE Std 11073-10471, Independent living activity hub • ISO/IEEE Std 11073-10472, Medication 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 Adaptation Protocol (eL2CAP) and exchanges IEEE 11073 data packets containing medical user data in a defined manner over one or more data channels. eL2CAP is an enhanced version of the L2CAP protocol that enables multiplexing of multiple logical data channels via a single radio connection. The enhancements in eL2CAP include the introduction 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 implementation. MCAP is used in an HDP imple-

“radio connection” Local Device Endpunkt

HDP Connection MCAP Control Channel MCAP Data Channel

Remote Device Endpunkt

Figure 1 Structure

of an HDP connection.

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 control 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 example, an HDP device can display the appropriate 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 terminology as shown in Figure 1. The same connection is described in IEEE 11073 terminology as shown in Figure 2.

Once a data channel has been established 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 application 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 individual 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 realized 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 regarding 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 otherwise 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 diverse 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 establish 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” measurement device that has a very specific limited functionality that it communicates to the manager prior to actual data transmission.

May 2013 MEDS Magazine

9

PULSE ACL Connection MCL Connection Control Channel

Local Device MDEP

Remote Device MDEP

MDL

Figure 2 Structure

of an HDP connection with IEEE 11073.

IEEE 11073 APDU

msg header

SDU start segment

msg header

PDU 1

SDU continuation segment PDU 2

msg header

SDU end segment PDU n

Figure 3 Data

transmission with IEEE packets.

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 implementation approach in which the IEEE manager application processes the medical measurement data (e.g., displays, saves, or forwards data) without having to understand or interpret it in the functional sense.

For example, body temperature measurements 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 without a generic IEEE manager implementation 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 probably 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-

10

MEDS Magazine May 2013

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 specifications, in particular, it seems that mechanisms that are actually quite simple can only be described in an understandable way with great difficulty. The specifications use formal speech that in some cases deviates far from natural speech and can produce artificial, difficult-to-understand and unwieldy sentences. There is definitely a reason for this, but those without experience performing 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 wellthought-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-related test runs take place. Here is where the specifications start to be examined again, this time with a very keen eye. It is now apparent 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 preparations 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 necessary 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 implementation 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 sectors. These experts spent several years debating with each other about the various details and requirements. The list of companies that collaborated on the specifications 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. Coming in the next issue of MEDS! Stollmann E+V Hamburg, Germany. +49 (040) 89088-0. [www.stollmann.de].

GO FURTHER WITH UL Full lifecycle testing, certification, regulatory, quality systems and regulatory-focused learning support for the Health Sciences industries. Our line of services includes:

ͻ /^K ϭϯϰϴϱ ͻ CMDCAS ͻ DĂƌŬŝŶŐ ͻ MDD ͻ IVDD ͻ EŽŶͲ ůŝŶŝĐĂů ƚĞƐƟ ŶŐ ͻ ůŝŶŝĐĂů ͬ ZK

ͻ ,ƵŵĂŶ &ĂĐƚŽƌƐ ŶŐŝŶĞĞƌŝŶŐ ;hƐĂďŝůŝƚLJͿ ͻ ^ŽŌ ǁĂƌĞ ͻ :ĂƉĂŶ W > ͻ /ED dZK ͻ /^K ϭϰϵϳϭ

LEARN WHERE YOU CAN GO WITH UL, VISIT US AT WWW.UL.COM/MEDS UL and the UL logo are trademarks of UL LLC. © 2013. BDI 30317

ͻ / ϲϬϲϬϭ ͻ ^ĐŚĞŵĞ ͻ / ϲϭϬϭϬ ͻ dƌĂŝŶŝŶŐ ͻ ĞǀŝĐĞ ZĞŐŝƐƚƌĂƟ ŽŶ ^ƵƉƉŽƌƚ ^ĞƌǀŝĐĞƐ

ͻ /ŶƚĞƌŽƉĞƌĂďŝůŝƚLJ ĂŶĚ ŽŶƟ ŶƵĂ ůůŝĂŶĐĞ ƚĞƐƟ ŶŐ ͻ ĞƐŝŐŶ ^ƵƉƉŽƌƚ ^ĞƌǀŝĐĞƐ ͻ ŽŵƉůŝĂŶĐĞtŝƌĞΠ͗ ZĞŐƵůĂƚŽƌLJͲĨŽĐƵƐĞĚ >ĞĂƌŶŝŶŐ ^LJƐƚĞŵ

PULSE

FDA Human Factor Requirements Change the Landscape of Medical Device Development 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.

by David Hirning MS and Virginia A Lang, PhD, HirnLan, Inc.

W

hether at the blackjack table or in the marketplace, is it not preferable to have the deck stacked in your favor? Wouldn’t you rather play blackjack knowing you have a significant advantage of winning? The same is true with developing new products. With development and production costs continuously escalating and profit margins shrinking, anything that can be done to minimize development costs and maximize market preference will improve product profitability.

When the FDA started requiring human factors/usability testing of medical devices, they were actually stacking the deck in favor of medical device manufacturers. Yes, that is right. Human factors/usability testing is actually

12

MEDS Magazine May 2013

a win/win for medical device manufacturers. 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 physiology, behavioral performance and cognitive 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 manufacturers to create a use-based risk analysis for their products. By creating this risk analysis, medical device manufacturers 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 testing. One important aspect of the risk analysis is the proposed mitigations for high-risk/high-frequency tasks. Instructions for use, training and product patient inserts are no longer considered appropriate 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 development cycle. The FDA calls these formative testing/methods. These tests are evaluative 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 problems early in the cycle will enable lower cost changes than if you waited until just before launch. What goes into a formative test?

Formative testing uses a prototype of the device and puts it into the hands of

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 personally 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 product, not for marketing. You are identifying these users so that you can put your product into their hands early in the product development cycle.

How many users do you need for the formative testing? The magic number 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 different 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/highest frequency tasks. In this case it would be the technician, the respiratory therapist and the caregiver, for a total of 24 test participants. 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 professionally 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 facilities used for the testing, creation of the

Envisioning

Planning

Developing

Expert Review / Risk Assessment

IFU

Stabilizing

Deployment

Summative Testing

Formative Testing Nu

mb

er o

f Po

ssi

ble

Des

of ost

ign

s

nge

Cha

C

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.

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 human 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 product that is safe, effective, usable and approved by the FDA in the shortest time possible. Finding out you have some serious 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/usability 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 judgment 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 ventilator, that means you would have five different 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/usability test. I am sorry to say that providing an estimated cost is very difficult. With that said, in our experience we have found that the minimum cost is about $50,000.

May 2013 MEDS Magazine

13

PULSE That is for one user group comprised of non-medical professionals.

Here are a few questions I am frequently asked: Question 1: If formative tests are not required, why should I spend the money?

Answer: Formative tests provide answers in the early stages of product development, when changes are relatively small compared to changes required after a summative test.

Question 2: Why should I conduct a formative test on my information for use?

Answer: In much the same way a formative 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 related 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 concepts and asks users to give their opinion.

Human factors/usability testing is evaluating user performance using the product in an environment that is similar to where the product would be used. These are one-onone 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 involve a human factors engineer. You should have a human factors engineer perform an expert review to fully understand 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 appropriate, is to complete the summative test.

Just remember, you may not pass the summative test without product design modifications.

14

MEDS Magazine May 2013

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 Engineering. But remember, Human Factors Engineering is the intersection of engineering, human physiology, behavioral and cognitive science. I would suggest a graduate degree in any of those fields with experience. 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 human 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 considered a Class 3 or Class 2 device, is a combination device, an infusion pump, a ventilator, 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 human factors/usability testing.

So imagine a blackjack table that allows 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 development 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 Information 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…blackjack again! But again, you knew that, you stacked the deck. You followed best practice during the product design/development process.

The recommendations and requirements 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? Embrace best practice, build safe, effective and usable products. Stack the deck. The FDA’s recommendations and requirements empower you to stack the deck in your favor.

Medical Device Human Factors by HirLan Carlsbad, CA. (619) 301-2073. [www.MedicalDeviceHumanFactors.com].

The Medical Electronic Device Solutions Magazine provides you with the convenience of Print editions, eBook versions, PDFs and the MEDS magazine website. The 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.

TEXT THE CODE MEDS TO 33233

OR SCAN THIS CODE AND SEND THE MESSAGE

You’ll receive a message about configuring your subscription and a confirmation.

www.medsmagazine.com

PULSE

Medical Device Manufacturers Address Compliance Mandates with Product Lifecycle Management 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.

by Eric Marks, Price Waterhouse Cooper

B

ased on industry statistics, it is obvious that intensified regulatory scrutiny has become a harsh reality for medical device manufacturers. Over the last several years, medical 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 developing a regulatory strategy, to preparing FDA submissions. So, just how are successful medical device manufacturers costeffectively achieving compliance while at the same time meeting their product delivery targets?

16

MEDS Magazine May 2013

Keeping the Pace: Technology is Key The Millennium Research Group, an authority on medical technology market intelligence, anticipates that device manufacturing executives will rely on technology solutions to overcome some of these regulatory burdens and save costs in hopes of recuperating lost profits from the Patient Protection and Affordable Care Act of 2010’s recent addition of excise tax on medical devices.

Due to the fast pace of new technology, emerging market opportunities and competition from start-ups, medical device executives find themselves in an environment 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 efficient 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 business 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 products. The mandates outlined in the FDA regulations related to medical device development protocol such as Part 11 of Title 21 of the Code of Federal Regulations (21

PULSE

CFR Part 11) and 21 CFR Part 820 Quality 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 compliant with the Part 11 regulations, manufacturers 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, labeling, storage, installation and servicing of finalized medical devices. Clearly these regulations require exceptional information management techniques and can offer 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 medical device manufacturers from adequately complying with FDA regulations.

As a central database, PLM manages the numerous bill of materials (BOMs), engineering changes, parts and associated documents created during the design process. Medical device manufacturers can easily maintain, access and report on required information such as a device master record (DMR), design history record (DHR) or design history file (DHF).

Additionally, in following CFR Part 11 guidelines for managing information electronically, PLM technology can support the required password protected signoffs, authorized electronic signatures and history tracking for complete electronic audit trails. Security features to control accessibility 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

Figure 1 Jetstream

Navitus from Pathway Medical is designed with an expandable cutting tip for use in debulking and treating vascular disease in the peripheral 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.

820 Quality System guidelines. The ability 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 eliminating the need to invest in separate systems.

Case in Point—The Pathway to PLM One such company, Pathway Medical 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 technology 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 (below the knee).

Ken Perino, Sr. Director of Quality Assurance & Regulatory Compliance at Pathway Medical Technologies, was the one to spearhead Pathway’s initiative to automate 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 streamline the entire engineering change process, implement better control with document vaulting, improve Bill of Material (BOM) management, and make product informaMay 2013 MEDS Magazine

17

PULSE

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.

tion (drawings, blueprints, revisions and supporting materials) easily yet securely accessible 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 skimping on essential PLM functionality. Too often the biggest problem with many PLM tools on the market is that they have become 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, engineering 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

18

Untitled-7 1

MEDS Magazine May 2013

4/3/13 10:42 AM

process, when you submit your engineering change for review, the system sends it out to everyone who is a signer or observer in parallel, and the engineering team can view engineering changes in real time.” This level of automation not only makes Pathway Medical’s process more efficient, but also provides a better documentation trail for auditors and compliance purposes.

Simplifying the Audit Process Medical device manufacturers are required to have formal processes in place to manage data for all facets of design and development such as: change control, supplier management, corrective and preventive actions (CAPAs), inspection and test procedures. In addition, evidence must be presented that formal processes are being adhered 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 certainly helps to ease the audit process. In the case of Pathway Medical, the company is required to meet International Organi-

PULSE zation for Standardization certification (ISO 9001:2008 international standard).

ISO auditors check to see how Pathway (or any company they are auditing) manages its product documentation, change orders/change management and engineering processes. Prior to automating with a PLM system, Pathway Medical would have had to show and explain its manual process, 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 centralize all product-related information and properly track data allows medical device manufacturers like Pathway to easily find required information for auditors, generate 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 Strategies What 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 ensure 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 companies are deploying the strategies that regulators suggest, and the information systems to support them. It aims to outline practices and systems that medical device companies should consider to ensure optimum throughput and quality.

Compliance Dynamics, a services company specializing in helping medical device companies with their business management systems, operational and regulatory 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 (regulated) 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 requirements 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 inherent need to streamline operations, are driving more and more medical device manufacturers to adopt technology solutions like PLM. The bottom line for medical 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 success. Rather, it is an essential key to success in an industry that has become overwhelmingly competitive and regulated.

Price Waterhouse Cooper [pricewaterhousecooper.com].

Cambashi Cambridge, UK. +44 (0) 1223 460439. [www.cambashi.com].

Compliance Dynamics Sunnyvale, CA. (408) 462-9222. [www.mycdyn.com].

Millenium Research Group Totonto, Ont. (416) 364-7776. [www.mrg.net].

Omnify Software Tewksbury, MA. (978) 988-3800. [www.omnifysoft.com].

Pathway Medical Technologies Kirkland, WA. (425) 636-4000. [www.pathwaymedical.com].

Untitled-7 1

May 2013 MEDS Magazine

19

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