Aligning application development priorities with regulatory guidelines and using the best available technology and models to reduce risk around development are important factors.
ARTICLE FOCUS:
• Aligning application development priorities with regulatory guidelines
• Reducing risk during development
• Implementing a framework
The healthcare industry is moving from a system that delivers remedial care to one that focuses more on delivering preventive and pervasive care. Traditionally, a patient visited a caregiver only upon spotting health abnormalities. Today, patients want their caregivers to deliver quality care by remote monitoring—regularly—and patients want prompt warnings and alerts on wellness negligence. They also demand remote patient monitoring solutions powered by mobile devices (such as smartphones, tablets, etc.) and with applications (such as apps that connect to their physical health records, applications that diagnose a disease remotely, or those that promote wellness, etc.).
Such solutions break geographical, knowledge, infrastructure, and socioeconomic barriers making healthcare accessible, affordable, and available. However, the constant concern over stemming from mobility-powered healthcare solutions with respect to patient safety, information reliability, and security raise many questions for healthcare and mobility original equipment manufacturers (OEMs). The regulatory ambiguity around some aspects of mobility-powered healthcare solutions adds to their woes. So how does a medical device OEM decode the regulatory compliance maze?
The regulatory challenge can be met by clearly aligning the application development priorities with the regulatory guidelines. Moreover, using the best available technology and models to reduce risk around development can also aid in addressing all regulatory requirements. These two objectives help to ensure the quality, reliability, and patient safety of the application throughout development of the application.
Resolving the regulatory hiccups
Medical device OEMs hold the principal responsibility for solution security, reliability, and safety of mobile medical applications. For the US markets, the recent FDA draft guidance, “Mobile Medical Applications,”1 is the regulatory bible for all medical-related mobile applications. As per the guidance, which was issued in July 2011, any mobile application that is used as an extension of one or more medical devices for the purpose of controlling patient-specific data, transforms the mobile platform into a device using similar functionalities, or allows the user to input patient-specific information and use processing algorithms, is treated as a medical device and must comply with the regulatory requirements as per 21 CFR 807, which includes submitting a premarket notification under 510(k). This guidance expands the definition of a medical device OEMs to include healthcare service providers who have their own mobile medical device applications for remote patient monitoring and communications providers who develop applications that make the mobile device a medical device. These providers, who are not normally regulated by FDA, form a nascent medical device OEM layer. As such, most don’t have a regulatory roadmap or plan.
Align application development priorities with regulatory guidelines. Irrespective of the nature of the OEM—traditional or nascent—the first step toward regulatory compliance for mobile applications is aligning application development priorities with regulatory guidelines. This can be achieved by clearly defining usage scenarios that fit within the intended use of the mobile application.
It is essential that OEMs are specific about what usage falls within the scope of the mobile application as well as what would be considered outside the scope. Take, for instance, an application providing the ECG strip data of a patient on a doctor’s mobile. The doctor shouldn’t use the information to make critical decisions—such as whether to do surgery—as such a decision requires careful examination of every pixel and the image represented on the mobile may be an inadequate representation. Such usage could pose a high risk. However, if the data from the application are used by the doctor to determine whether a patient seen an hour earlier is faring well and that the vital parameters are within a proper range, such usage would be defined as a low- to medium-risk scenario.
If the application is an add-on accessory to an existing medical device, the OEM needs to clearly specify that “critical decision making” based on the data from the mobile medical application must be avoided in certain circumstances. For the ECG application, it would need to specifically state that when the data are “image and/or graphical intensive” the application should not be used as a guide for critical decisions because the compression techniques used to deliver the information might result in image distortions.
Approaches to reducing risk during development. An established medical device OEM can adopt multiple approaches to reduce the risk during development. One option is to adopt an incremental or trim-down approach. For example, an OEM currently regulated for a Class II device can roll out a mobility healthcare application similar to the existing FDA-approved or cleared device in which the functionalities of the medical device are preserved in the mobile version. In such a case, the OEM would seek incremental FDA approval or clearance for the application. However, if an OEM plans to develop and market the mobile application as an add-on accessory, the trim-down approach enables the application to shift from Class II to Class I by adjusting the intended use to address specific market opportunities. Another option is to adopt an outside US (OUS) strategy.
Nascent developers may opt for an OUS approach, which can often provide an easier regulatory pathway. With an OUS strategy, an OEM can first get approval for its application in non-US medical device markets, which offer less-stringent, faster, and less-expensive regulatory processes. This would also help the nascent OEMs to upgrade the design and make changes to the specifications based on the user feedback and then resubmit it to the agencies for approval rather quickly. The Indian and European markets are good markets to look at. The underserved rural healthcare market in India is still challenged by healthcare affordability and availability and thus is a strong market for mobile medical applications, especially with the recent penetration of mobile across rural India. Further, the regulatory authority in India is open to mobile medical apps.
In Europe, too, the existence of clear guidance (including practical guidance) on the issue of health app regulation, openness of the regulatory authorities toward providing approvals, and the close affinity with regulatory process of other European nations due to harmonization by the EU Medical Devices Directive makes it a viable market for launching mobile medical applications. The first registration of an app (Mersey Burns) 2 in the UK (with the MHRA classifying it as a Class I medical device) is a testament to the openness of Europe toward mobile medical applications. However, to achieve the most out of this approach, one needs to adopt a global regulatory compliant product development approach.Any medical OEM, including those with mobile medical applications, looking at entering multiple non-US markets needs a strong global launch strategy. A global strategy must include foolproof evaluation and analysis of the hazards and regulation compliance in each market, which includes in-depth knowledge of the premarket approval or premarket notification process. In addition to regulatory compliance, OEMs must be prepared to address requirements for software quality assurance, reliability assessment and testing, manufacturing readiness, QMS support, supplier engineering, global device registration, etc, that differ from region to region must be part of the development plan. A successful global launch of a mobile device or application calls for adapting existing business processes to handle compliance requirements for such applications as well as proper tools and techniques to automate delivery of compliance (see graphic). Device validation protocols and their execution and hazard analysis processes, for instance, can be automated for intended use.
A homologation framework can guide a mobile medical application’s introduction through multiple geographies, by taking care of the legal, environmental, quality systems, distribution cycle, and end of life cycle. Such a framework manages engineering changes that may be needed to meet various local regulatory requirements. It also acts as a vehicle to handle customer complaints and regulatory reporting, to provide field service bulletin and field modifications instructions, (FMI) and to manage the end-of-life stages of the application. It is comprised of elements of a robust assurance case framework including safety assessment, failure modes effects and criticality analysis (FMECA), fault-tree analysis (FTA), static code analysis, system verification, and risks to health, among other analyses.
A framework helps manufacturers focus on implementing a risk-management process beginning with the design function and moving all the way through to the end-of-life phase for a global application. The risk analysis, risk estimation, and risk-evaluation process are carefully studied and reviewed during the implementation of the framework. Tools such as FMECA and FTA are used extensively to dig deep into the root cause of failures and identify appropriate mitigation plans. Field complaints and other sources of product failures are explored during failure analysis. The pace at which mobile devices are growing in processing power and bandwidth to enable applications that support decision-making or that contribute to diagnosis and treatment, as well as the constant update of platforms, make such risk analysis perhaps even more important than it is for traditional devices.
Further, a homologation framework helps reduce time in verification and validation activities because test protocols can be run for multiple geographies simultaneously. It allows quicker identification and resolution of bugs and process gaps, resulting in significant cost savings. Such a framework is critical in the mobile medical applications landscape where low entry cost and quick time to market are drivers for the demand of mobile medical applications. The data would be uploaded to an electronic health record system or hospital information system through the Internet for storage and recall purposes. Hence, the entire chain needs to be reviewed by the regulatory agencies during the approval process.
In some cases, medical device OEMs that have limited experience with mobile applications may want to consider partnering with a provider that can help them meet regulatory schedules and budgets.
Regulation ahead
Looking ahead, the regulations addressing mobile medical applications are only expected to become more stringent, with risk management expected to be at the core of meeting the rigorous approval criteria. The emphasis on risk management might result in a change in the way certification bodies assess applications for certification. Any changes will certainly involve more time and cost as interpretation, and an understanding of the risk-versus-benefit analysis would become more complex.
References
1 “Mobile Medical Applications,” draft guidance (FDA, July 2011), http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm263280.htm.
2 “A UK first: Mersey Burns app is registered with the MHRA as a Class I medical device,” d4blog, January 2012, http://blog.d4.org.uk/2012/01/a-uk-first-mersey-burns-app-is-registered-with-the-mhra-as-a-class-i-medical-device.html
