This content is only available to Premium subscribers. See our Subscribe page for information on subscriptions.
As more “software as a medical device” (SaMD) applications are developed and marketed, there has been an increased focus on what activities and documentation are required for compliance with US medical device regulations and applicable ISO standards. Along with the rise of SaMD has come the emergence of supporting organizational, management, and production activities that are in many cases new to the medical device and HealthIT world and may lead to compliance challenges. Further complicating matters is emerging, inconsistent, and confusing regulations in the various global markets.
One of the key characteristics of SaMD is the significant amount of “non-application” software involved in the operation of the device to meet its intended use. We generally group all of the non-application SaMD software into “platform” software. We recognize that platform may mean a smaller sub-set than all the non-application, but our suggestion is the create two grouping: Application and Platform
… where platform includes operating systems, services, libraries, databases, etc.
By separating the platform cleanly, there can be other efficiencies and better focus. For example, one should be able to consider updates and patches to the platform asynchronously to application software updates. One caution here is to consider how to keep the application in a validated state.
Another popular approach with SaMD is the use of a microservice architecture. Certainly there a software engineering advantages and disadvantages to consider, but we see the value in possibly using this type of architecture to achieve segregation suitable for risk control per IEC 62304 (and IEC/TR 80002-1).
