A Smart Approach

It’s a System; no longer just a device, and the system has implications for one’s entire value proposition and revenue model.

Step One. Stakeholders from across the business must to work together to understand the costs and benefits of the various approaches appropriate to your unique situation and define the requirements for the system. Remember that the support costs may not stop after the devices are shipped, and in return, there may be offsetting remuneration for the ongoing services provided. As input to the system requirements, this is also a good time to gather end-user inputs and to start the human factors analysis to make sure your investment is targeting a real need in an appropriate manner.

Step Two.  Architect the full solution that will meet all of the system constraints and will comply with the many, and sometimes, competing regulatory guidance. Design-in the appropriate device use and health monitoring functions with the infrastructure needed to monitor and act on the data. There are many third-party SAS solutions available for data collection in the cloud to be considered. Remember to evaluate the ongoing costs, the control, access, and ownership of the data stored there. We prefer to use the resources available in AWS (Amazon web services) to implement highly secure and cost effective cloud solutions. We have a toolkit solution on the shelf that we use for our clients.

Here is where the details of the connection approach need to be defined—for example, exactly how will your device interface to, or make data available to, EHRs, and in which institutions. Consult with doctors as to the appropriate format for any data provided. Talk to the hospital IT managers for methods of connection to their EHR and possibly their accounting systems. Risk analysis is a critical part of the architecture design, and many options and tradeoffs need to be considered to optimize patient safety, cybersecurity, availability, and cost constraints.

Step Three.  Implement the system components following compliant and proven robust development processes. Design and implement maintainable code, comply with coding standards, and comment well to aid in maintenance.

Step Four. Verify and validate the subsystems (e.g., the device, supporting apps and any web applications). It is likely you will want to rerun the V&V many times as updates are required, so use automated tools for code analysis, automated tests frameworks, and procedures for verification and validation.

Step Five. Integrate the system; verify and validate the system. Cyber penetration and fuzz testing should be considered in addition to the standard medical suite of tests to the system requirements. For apps, the SDK simulators are not good enough—they’re too clean (i.e., they do not have Verizon’s code or other third-party apps running). Test against all likely target platforms using, for example, the AWS device farm. Keep in mind that you cannot test every smartphone or tablet configuration, so you still need to monitor your app’s performance in the field.

Post Launch. Post-launch activities include the activities that were defined in steps one and two, and the tools developed as part of the system to implement these activities. If you are moving or storing PHI, then make sure you have appropriate HIPAA controls in place and business associate agreements (BAAs) with any service providers enlisted to work with PHI on your behalf. Be sure to review the FDA’s “Postmarket Management of Cybersecurity in Medical Devices” draft guidance, which, among other things, encourages your involvement in the NH-ISAC (National Health Information Sharing & Analysis Center) to monitor for newly discovered cybersecurity threats and vulnerabilities.