When Clinical Functionality Crosses into Medical Device Territory

In the continuous stream of end user requests, project work, and technical updates, it is not always obvious when a change to clinical system functionality may introduce regulatory medical device considerations. Most changes fit comfortably within the work health IT teams already do. However, functionality that interprets patient data, predicts clinical outcomes, or recommends and action may require a broader discussion than a typical system change.

Whether a software function may be considered a medical device is not determined by the technology alone. It depends on what the function is intended to do, the output it produces, and how that output is expected to be used in patient care. A change that simply presents clinical information is very different from one that interprets patient data, predicts an outcome, or recommends a clinical action. Artificial intelligence may be part of that functionality, but its presence alone does not automatically make software a medical device.

Analysts, informaticists, and project managers are not expected to make regulatory classifications themselves. They do, however, need to recognize when a request may need input from clinical leadership, the vendor, or the appropriate regulatory and legal resources within their organization.

One function may need to be considered separately

For many health IT professionals, it used to be easier to see when medical device regulation might apply because the software was often tied to a specific clinical system or physical device, such as an imaging system or laboratory analyzer.

That distinction is less obvious now that more advanced clinical logic can be built into systems used across many areas of patient care. Clinical applications may include hundreds of functions that support documentation, ordering, clinical review, decision-making, and the various workflows involved in providing patient care. A regulatory question may not apply to the application as a whole, but instead to one particular function and what that function is intended to do.

For example, an electronic health record (EHR) can continue to serve the same broad role across the organization while adding functionality that predicts the risk of deterioration or recommends a treatment change. Those capabilities may need to be considered differently from the many other functions within the EHR because of what they do with patient information and how the output will be used in care. That does not automatically make the function a medical device, but it may be enough to take a closer look at whether regulatory review is needed.

The details can change the conversation

A lot of health IT work starts with language that sounds familiar. A dashboard, decision support feature, or documentation function may not immediately stand out as something that needs regulatory or legal input. It is often the details about what the function actually does and how the clinicians are expected to use it that make the need for regulatory or legal input more apparent.

For example:

🖥️ A dashboard analyzes patient data and identified patients whom may be at higher risk of deterioration.

💊 A clinical decision support function uses patient information to recommend a medication dose or treatment change.

💭 A vendor feature provides a clinical recommendation that clinicians are expected to rely on, but does not provide enough information for them to independently understand how the recommendation was reached.

None of these examples automatically means the function meets the definition of a medical device. They do, however, give the team a reason to confirm whether the appropriate regulatory or legal resources are already involved. If they are not, or the team is not sure whether the function has been reviewed from that perspective, it may be time to widen the conversation.

A broader discussion needs enough context

Once the question is raised, the people responsible for considering the regulatory position need enough context to understand why they are being asked to review. Depending on the organization, that may mean providing a short written summary, completing a formal intake, or simply bringing the right people into the discussion early.

The details will vary, but the conversation is much more useful when the team can clearly describe things such at:

• What the function is expected to do
• What patient information it uses
• What result, recommendation, or other output it produces
• How clinicians are expected to use that output
• Where the function fits within the clinical workflow
• How the vendor describes its intended use and regulatory status
• Whether the organization plans to configure or use it in a way that differs from the vendor's description

The goal is not to perform the regulatory assessment before involving the people responsible for it. It is to make sure they have enough information to understand the function, the proposed use, and why the question is being raised. A statement that something "uses AI" or "may be a medical device" does not prove enough context on its own.

As clinical systems continue to take on more sophisticated functions, these considerations may come up in areas of work where health IT teams have not traditionally needed to think about medical device regulation. Recognizing when a particular function may need another level of review helps ensure the right expertise is involved without asking analysts, informaticists, or project managers to make decisions that sit outside their role.

For health IT professionals, this is another reason to look beyond the technical change itself and consider how the functionality will actually be used in patient care.