site without changing your settings, you are agreeing to accept all cookies on the site.
December 2017 - Issue 4
Welcome to Battelle’s Medical Devices newsletter. We offer this newsletter as a service to our clients to keep you informed of the latest news from our researchers and the industry.
Battelle’s Medical Devices team can help you accelerate your medical product development timeline – from ideation to evaluation to commercialization. Our newsletter will help keep you up-to-date on cutting-edge medical devices work, including device security, drug delivery, usability testing and neurotechnology.
By Gaurav Sharma and Heather Strohl
Imagine you are paralyzed and are given the opportunity to regain control of a few key hand gestures. Which ones would you choose first? A tight fist? A handshake?
How about a credit card swipe?
That was the surprising answer Ian Burkhart gave when researchers from Battelle’s NeuroLife™ team asked him what he would like to work on next. Ian, who was paralyzed in a diving accident in 2011, is the first person to test the NeuroLife technology. Using a chip implanted in Ian’s brain, a sophisticated computer algorithm that interprets brain signals, and a specialized sleeve that sends those signals to Ian’s muscles, NeuroLife has given Ian the ability to consciously control his hand, wrist and fingers.
But mastering each gesture requires a lot of practice time for Ian and training for the computer algorithm that connects his brain to his muscles. After working on basic gestures such as opening and closing the hand, we asked Ian what he would like to work on next. Credit card swiping was the furthest thing from our minds – but for Ian, this simple gesture was an important step towards a future with greater independence.
Working on cutting-edge medical devices that address complex medical issues requires device developers to go beyond basic human factors research and human centric design principals. For the NeuroLife team, Ian has been much more than a subject or even a participant.
Ian says, “With my experience in a clinical trial, I have been able to evolve from a participant to an active partner in the research process of making a medical device.”
That has included suggesting new experiments and active problem solving with the research team.
This kind of partnership may not be necessary – or even desirable – for all types of medical devices. But for NeuroLife, it has been essential.
NeuroLife brings together several factors that make patient partnership especially important:
There are many similar medical device development projects that would benefit from this “patient as partner” approach, in particular other cutting-edge assistive and rehabilitative technologies. The more innovative the technology, and the more extensively and intimately it will be used by patients, the more important it is to have the patient voice guide research efforts.
This means more than conducting user focus groups and contextual research. It means making study participants active members of the research team. Instead of a set research program in which all activities are dictated from researchers to patients, these patient partners will be engaged in a two-way dialogue that informs the direction of future trials and further iterations of the device.
This is a more active process than many medical device developers are used to. But when we make patients our partners, they can take us in surprising new directions. The result will be a medical device that is much better suited to the needs of the people who will be using it every day.
By Kevin Stoffell
Federal buyers make up an enormous and attractive market for medical device manufacturers. The two largest federal buyers, the Department of Defense (DoD) and the Veterans Administration (VA), spend hundreds of millions of dollars on medical device procurement annually to support their systems of hospitals and medical centers and provide care for soldiers and veterans.
But tapping into this market can have unexpected pitfalls for medical device developers. Medical devices sold to federal buyers must meet security requirements defined by the Federal Risk Management Framework (RMF). The RMF overlaps with but is not identical to cybersecurity guidelines manufacturers must follow for FDA approval of medical devices. Getting FDA approval is not a guarantee that the device will meet RMF requirements. Manufacturers who want to make federal agencies part of their sales strategy need to understand the difference and know how to apply RMF requirements to their devices.
Most medical device manufacturers are well acquainted with the FDA’s premarket and post-market guidance for medical device manufacturers. These documents detail the FDA’s expectations for secure design, cybersecurity testing and risk management. They are very specific to the medical device industry and the documentation that manufacturers are expected to provide during the submission process. The FDA’s main priority is making sure that devices do not put patient safety or data privacy at risk.
The RMF is a different animal. The Federal RMF applies broadly to all categories of Information Technology (IT)-based devices sold to federal clients, from desktop computers to digital door locks. The RMF is focused on ensuring that devices used by federal agencies do not introduce security vulnerabilities that could affect (or infect) the overall IT environment.
While both address cybersecurity risks, their focus, emphasis and specific requirements are very different. It is entirely possible to meet FDA requirements while failing to comply with the federal RMF—and vice versa.
The RMF covers three basic aspects of data security:
In other words, it was developed to ensure that data cannot be shared or accessed without authorization, cannot be accidentally or maliciously changed, and is available to authorized personnel when and where they need it.
To meet these objectives, the RMF uses a six-step process:
The RMF is heavily based on cybersecurity standards and guidelines developed by the National Institute of Standards and Technology (NIST). The RMF references and assigns controls from the NIST SP800-53 control catalog to systems. These controls also map to the cross-industry NIST Framework for Improving Critical Infrastructure Cybersecurity (commonly known as the Cybersecurity Framework), which provides a consistent method for planning organizational cybersecurity goals and risk reporting. The NIST standards and guidelines define requirements for various aspects of device design and software architecture such as the use of cryptography, access control, threat monitoring and data storage and management.
Some requirements identified in the RMF also map to other, more detailed standards or guidelines. For example, cryptography is further governed by Federal Information Processing Standard (FIPS) 140-2. The standard details four levels of security, increasing with the sensitivity of the data to be protected, and provides guidelines on the use of cryptography at each level. It also requires that all cryptographic functions used to protect government data undergo validation testing under the NIST Cryptographic Module Validation Program (CMVP). This is one of the significant requirements managed by and assessed as part of the RMF that requires investment and preplanning to ensure success. Full compliance with FIPS 140-2 cryptographic requirements may require the investment tens of thousands to hundreds of thousands of dollars for each product version.
Under the Federal Information Security Management Act of 2002 (FISMA-2002) and its replacement, the Federal Information Security Modernization Act of 2014 (FISMA-2014), all federal agencies and departments – including DoD, civil agencies and the intelligence community – must follow the RMF when evaluating and purchasing software-based devices. President Trump’s May 2017 Presidential Executive Order on Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure further strengthens cybersecurity enforcement across the federal government. NIST has subsequently released updated guidance on RMF implementation to fit within this executive order.
Most federal acquisitions include a cybersecurity assessment of proposed systems or devices to ensure they will meet federal requirements and be successful in achieving an Authority to Operate (ATO) as an outcome of the RMF. In many cases, DoD or federal customers will limit system or device purchases until they are certain the device will pass the rigorous assessment process in the RMF and be granted an ATO. Without an ATO, a device cannot be operated by the DoD or VA in a networked environment and, in many cases, may be prohibited from all or most standalone device functionality.
When new devices are evaluated for purchase, specialized reviewers at the purchasing agency go through all aspects of device security covered by the RMF and determine whether or not the device meets the requirement. Unfortunately, the assessment process is often checklist based, without a nuanced view into whether or not applying the standard makes sense for the device in question. This is particularly problematic for embedded type devices that have a limited-functionality operating system and have difficulty applying security controls written for a general-purpose computing system (e.g., a laptop computer). Due to the unique form factors and interfaces of many medical devices, it can be a challenge to properly articulate security features of the device that may, in fact, provide adequate security but are not technically compliant with controls designed for general-purpose computing systems.
While all federal departments and agencies must use the RMF to evaluate potential technology purchases, each agency has a degree of leeway in how it applies the RMF for its own needs. For example, all agencies must meet a defined level of security for wireless networking, but may customize the exact methods and configurations of wireless networking they utilize. Additionally, the DoD follows a much stricter method of assigning cybersecurity controls to systems that results in significant differences between DoD and non-DoD federal agencies. Medical device manufacturers wishing to sell to DoD or other federal agencies will first need to understand the specific configuration guidelines required by the purchasing agency that may impact the technologies employed in their device.
Finally, manufacturers should be prepared for increased vendor support requirements when selling to federal agencies. For example, agencies may have very specific and aggressive requirements for patch or update intervals and may require validation for software distribution mechanisms. They may also require non-standard warranty and support timelines beyond what is typical for commercial sales
Navigating these requirements can be both expensive and difficult for device manufacturers that have never dealt with federal and DoD requirements. The publicly available documentation, while complete, is very large and difficult to navigate. The NIST SP800-53 that defines the federal controls is nearly 500 pages of text and does not specify many of the individual variables (e.g., length of time allowable before a screen must automatically lock), which are left to individual agencies to define. The DoD uses a 96-page manual just to implement the portions of the RMF unique to the DoD and also publishes more than 400 individual technical implementation guides for different technologies.
Applying the RMF requirements to a specific device is not a one-size-fits-all proposition. Medical device manufacturers will need to interpret the framework and requirements for their device characteristics and determine how different aspects of the RMF apply.
Implementing the security controls outlined in the RMF can be both tricky and expensive. Much of the framework was written around devices with full operating systems, such as desktop or laptop computers. There is limited guidance for manufacturers of devices that do not use a general-purpose Operating System (OS) such as Windows or Mac OS. Even devices that use a general-purpose OS or an embedded version of a general-purpose OS may have difficulties applying the security guides associated with that OS, since the guides assume a standard configuration and are not designed for devices that provide real-time patient care.
For this reason, many off-the-shelf medical products have operating systems that are not configured to support government security controls. Embedded systems using a limited-function operating system or custom OS generally cannot be made fully compliant with all RMF requirements through normal configuration. When embedded systems are configured to government specifications—especially when it comes to network configurations and communication protocols—there is often a loss of functionality or system behavior that is incompatible with patient care imperatives. Depending on how critical the functionality is for patient safety and device performance, the tradeoffs made for compliance may be unacceptable. Conversely, tradeoffs made for patient care and performance may be considered unacceptable by government cybersecurity approvers without significant explanation by the device manufacturer.
The easiest way for medical device manufacturers to ensure that their device will be RMF-compliant is to build this compliance into the device from the start. For existing devices, manufacturers will have to weigh the potential benefits of compliance (in the opening of new markets) against the costs and risks of changing their existing design or the potential loss of functionality in the device.
Medical device manufacturers who do not have extensive expertise in the RMF on staff will benefit from an expert review by a third party. Battelle offers review services to help medical device manufacturers evaluate their current architecture against RMF requirements, identify compliance gaps and develop a compliance strategy.
While the barriers to federal sales may seem daunting, the new market opportunities opened up by successful navigation of the RMF process can be well worth it. Manufactures shouldn’t count themselves out of DoD and VA sales without a closer look at how the RMF would apply to their device. The changes they would need to make to qualify for federal sales may be easier than they think.
By Erik Edwards
The U.S. government has a rich history of sponsoring innovative programs that bring about technological advances that benefit people everywhere. Prime examples include NASA’s space program, which led to products such as memory foam, advances in solar panels and personal heart rate monitors, and DARPA advances that enabled internet communications and GPS devices. Although the complexity of intellectual property rights and government contracting can be intimidating, there are substantial potential benefits for companies who partner with the government in research and development.
In the field of wound care, a new product to treat severely injured limbs on the battlefield has potential to assist diabetics suffering from foot ulcers. The Office of Naval Research sponsored a program to develop a medical device called the Acute Care Cover for Severely Injured Limbs, or ACCSIL, to preserve severely injured limb tissue. It is intended for use by corpsmen/medics/first responders at the point of injury with removal performed later by doctors and surgeons at definitive Medical Care Facilities.
ACCSIL is designed to preserve injured tissues in the best possible state for up to 72 hours after the time of injury. During ACCSIL development, there was a need to develop a way to deliver oxygen to tissue in a compact, lightweight form because when a tourniquet is applied to an injured limb, the tissue can become ischemic and further damaged. To address this need, an oxygen generating "pump" that does not require power or batteries and steadily provides three liters of oxygen to the wound site over three days was developed.
Although this pump can change the methods used to treat traumatic battlefield injuries and improve the overall quality of life for service men and women, it also has potential to aid in the treatment of other mainstream medical conditions, such as the ability to treat chronic pervasive wounds originating from diabetic ulcers. More than 30 million people in the United States have diabetes and between 10-15 percent will develop diabetic foot ulcers. The ability to provide steady, low levels of oxygen to these wounds without the need for electrical power or batteries could have long-term benefits for these patients.
The ACCSIL oxygen pump provides a good example of how technologies developed for the government can be leveraged for civilian and commercial markets, resulting in a positive impact to society. Working with the government to meet their pressing needs and unique applications can result in increased product development opportunities and financial returns for those companies willing to align their research activities with government objectives.
By Clark Fortney
Consumers are flocking to Internet of Things (IoT) technologies, from “smart” smoke detectors to connected speaker systems. However, when the connected devices are medical in nature, sometimes the benefits don’t justify the potential threats to patient safety or data. Medical device manufacturers that are considering adding or expanding connectivity options should think carefully about what they are trying to achieve and develop a strategy that balances the risks and rewards.
Connected medical devices are at the heart of some of today’s most exciting advances in healthcare. From mHealth apps that help patients manage chronic conditions at home to smart sensors that alert caretakers when attention is needed, connected devices are making healthcare more personal, more responsive and hopefully more effective. However, it does not necessarily follow that more connectivity always is better, or that every medical device should connect to other devices or networks.
In considering the benefits of connecting a medical device — to other devices, to a web portal or to a hospital network — manufacturers should make sure they have clearly established the potential benefits of connectivity. In particular, they should define who benefits and how.
Connectivity is clearly beneficial for patients and care providers in many cases. Wearable medical sensors can transmit real-time data and alert care providers if immediate attention is needed. Connected mHealth apps can help patients track blood sugar levels, drug doses, blood pressure, weight and other readings, so patients can better manage chronic conditions and communicate with doctors and care providers.
Some forms of connectivity directly benefit patients and companies. For example, a drug delivery device connected to a mobile app or web portal can be programmed to automatically order refills from the patient’s pharmacy at the right time. This reduces the risk that patients will run out of critical medication, while at the same time helping companies meet business goals. Other forms of data collection may not have any direct benefit for the patient, but provide valuable data for product development or enable marketing opportunities.
Increasingly, the move towards greater connectivity is being driven by perceived consumer demand and competitive pressure, rather than carefully considered medical benefits. Manufacturers may believe that adding a mobile app for a medical device used in the home will make it more appealing or usable for patients. In reality, many of these apps are loaded with rarely used extra features that add little medical value. This echoes similar issues seen in the world of consumer IoT: many people have found that their “smart” thermostats and light bulbs do not provide enough added value to justify their added cost and complexity. Before rushing to connect for connection’s sake, companies should carefully consider what they are trying to achieve and weigh the potential downside of connectivity.
Cybersecurity is a critical concern for every medical device that uses software. Connecting devices to the internet, hospital networks or other devices makes them vulnerable to cybersecurity threats, including deliberate attacks and undirected malware. Hackers may attempt to break into a medical device with the intent of causing harm to users, stealing patient information or pivoting into a hospital network to steal data or conduct a ransomware attack. Commodity malware is an even bigger threat for most medical devices. Even if the device is not specifically targeted, malware can disrupt device operation in ways that can put patients or data at risk.
When considering adding options for connectivity, medical device developers should carefully evaluate the potential threats and risks at the very beginning of the process, during device conceptualization.
Key questions to ask include:
Each medical device will have its own unique cybersecurity threat and risk profile, as well as its own benefits. Drug delivery devices and life support devices, such as ventilators, have a very high risk of patient harm if they malfunction or stop working entirely. For other devices, such as a connected blood pressure monitor, the direct risk of patient harm may be very small. Medical device developers must balance the potential worst-case scenarios — especially risks to patient safety — against the benefits gained by adding or increasing device connectivity.
Of course, in many cases, the potential benefits of connectivity are well worth it. Connected medical devices can provide added functionality that improves care and leads to better patient outcomes. In addition, they open up new opportunities for data aggregation and analysis that are invaluable for medical researchers and business developers.
While no connected device will ever be 100 percent secure, there are steps that developers can take to reduce cybersecurity risks. A good cybersecurity plan encompasses every stage of device development, from initial concept to post-market updates. At each stage, there are choices to be made that can either increase or decrease device security. These choices must be carefully balanced against usability, functionality and cost considerations.
Medical device developers who do not have extensive cybersecurity expertise on staff should consider bringing in outside experts to assist with requirement development, software architecture decisions, risk analysis, and vulnerability testing.
Some strategies that medical developers can use include:
The IoT is here to stay, for medical devices as well as consumer products, and we can expect to see greater levels of connectivity between medical devices and consumer products, such as smart phones and tablets. In most cases, the benefits for users — in terms of greater convenience, easier adherence, improved insights, and better health outcomes — will be well worth the risks. But consumers will not be able to make those calculations themselves. It is up to the medical device industry to make careful, strategic cybersecurity choices to minimize those risks.
Battelle NeuroLife™ restored Ian Burkhart’s ability to move his hand and fingers after he was paralyzed in a diving accident. At the 2017 MedTech Conference in September, Ian shared his experiences and perspective as the first patient to receive the groundbreaking neural bridging technology in a clinical study.
Ian was a plenary speaker at a breakfast session and shared his inspiring story. Ian has been an active participant in the clinical study, which was conducted through Battelle and The Ohio State University Wexner Medical Center. Since participating in the study, Ian has gone on to create the Ian Burkhart Foundation, which is dedicated to restoring lives and providing hope to individuals with spinal cord injuries.
Battelle had an active presence at MedTech 2017, where the Medical Device team shared their latest advances in device security, drug delivery, usability testing and human centric design, and neurotechnology.
Battelle’s Gaurav Sharma and Heather Strohl shared their thoughts about “Patients as Partners,” based in part on the experience of working with Ian on NeuroLife, in a recent blog.
Also, Battelle Senior Research Leader Herb Bresler and Ian were interviewed as part of a series on Remarkable Medical Science while at the conference.
Battery size and shape can put significant design constraints on medical devices. Battelle’s Conformal Battery breaks through those limitations with a thin, lightweight battery that can be conformed to a variety of different shapes. The Conformal Battery was named the 2017 Consumer Products Category Winner in the Tech Briefs Create the Future Design Competition.
The Conformal Battery would allow medical device manufacturers to design products based primarily on function and ease of use rather than battery shape. Heavy, bulky batteries can limit design options and make medical devices harder for patients to use, carry or store.
The Conformal Battery (U.S. patent 9520580) uses a mirrored stack design centered on a dual-sided anode. It eliminates the mass and volume associated with the outer battery packaging. Instead, the battery uses an advanced separator that has a very thin profile and can be shaped into many different geometries. The battery can be integrated into product housing without impacting overall rigidity and strength. It has also been designed for fire safety.
For more information, reach out to our medical devices team.
Traumatic Brain Injury (TBI) makes up a significant percentage of injuries sustained by military personnel in the field or in combat. The military needs better ways to assess soldiers for TBI under field conditions to ensure that they get the treatment they need.
In October, the Department of Defense (DoD) awarded Neural Analytics a $10 million contract through the U.S. Army Medical Research and Materiel Command to develop a portable point-of-injury device for assessing combat-related TBI. Battelle will be working with Neural Analytics to provide technical and advanced engineering expertise to ruggedize and miniaturize the system to military specifications.
The Lucid System will measure and monitor physiological parameters that can be used as indicators of a moderate to severe TBI. It will be a self-contained, portable unit suitable for use in prolonged field care scenarios and designed to require minimal training and maintenance.
Neural Analytics is a medical device company dedicated to the development of technologies that measure, diagnose and track brain health. Battelle brings broad expertise in medical device development for both military and commercial applications. Over the last decade, Battelle has been extensively involved in the development of cutting-edge neurotechnologies such as Battelle NeuroLife™.
Read more here.
From drug delivery devices to surgical equipment, William G. (Bill) Atterbury is the technical leader behind numerous medical devices on the market today. A Research Leader and design engineer on the medical devices team, he has devoted his career to finding practical, innovative solutions for challenging technical problems in the medical device field. Read More
Gaurav Sharma’s work has helped a paralyzed patient regain control of his hand and enabled delivery of drugs across the blood-brain barrier. As the Lead Investigator and Senior Research Scientist on the Battelle Medical Devices and Neuromodulation team, he is applying advanced engineering to overcome problems in the human body and brain. Read More