Healthcare data

How MDS² Data Can Inform Smarter Medical Device Workflows

5 min read

In 2004, Nema (the National Electrical Manufacturers Association), together with HIMSS (Health Information and Management Systems Society) and a number of other security experts and government agencies, produced a short document template for manufacturers to use in order to describe the vital security properties of their devices. They named this document the “Manufacturer Disclosure Statement for Medical Device Security” —  which is generally shortened to MDS2.

What Is In the MDS2 Form?

The MDS2 form is a response to the need for healthcare providers to have insight into the security and privacy profiles of the devices that they use. Without this visibility, they can’t set up effective security controls.

The MDS2 differs from a software or hardware Bill of Materials in the sense that it conveys product information in a much more descriptive and selective manner. So whereas a software bill of materials would simply list all the software components included in the device, an MDS2 form for the same device would describe the product in terms of its cybersecurity capabilities and/or compatibilities and the immediate implications thereof.

In a way, you can think of it like this: the bill of materials is like the list of ingredients on the back of your food package, while the MDS2 is more like the nutritional facts; only instead of nutrition, it’s about cybersecurity.

MDS2 captures and contextualizes medical device security information through a list of short questions covering a range of different categories. By design, most of the questions prompt simple and direct yes-or-no answers so that there’s little room for interpretation and confusion. The most recent version of MDS2, released in 2019, consists of 216 questions (compared to 41 in the 2004 version) that cover 23 different categories.

The questions address issues like:

  • The types of private data are stored on the device, and how they are transmitted
  • The device operating system, operating version, configuration, and network connection
  • Any built-in security safeguards and capabilities, like encryption, auto-logoff, malware detection, physical locks, etc.
  • Auditing capabilities
  • Access management, authentication features, authorization requirements

Because the MDS2 is a standardized form, it makes it much easier for healthcare organizations to compare the security capabilities and properties of devices between different manufacturers. Among other applications, this information can:

  • Point you to the top security concerns and considerations to keep an eye on
  • Index the device’s primary security characteristics
  • Capture interoperability and cybersecurity requirements/implications
  • Reflect the vendor’s long-term support and liability commitments.

The MDS2 form is entirely optional. It’s the buyer’s responsibility to request an MDS2, not the manufacturer’s to provide it. When requested, it’s not at all uncommon for manufacturers to deliver incomplete or inaccurate MDS2 forms. And forms are virtually never updated based on the device’s configuration profile. Worse still, sometimes manufacturers outright decline to supply MDS2s.

In the meantime, we just need to push for increased cyber consciousness and advocate for greater MDS2 adoption. In recent years, the needle has indeed begun moving in that direction. Many hospitals now insist on up-to-date MDS2 documentation as part of the procurement process. For the industry as a whole, this is very encouraging.

Thankfully, that generally dilatory posture is being replaced with a more conscientious approach spurred by the increasing attention paid by healthcare organizations to cybersecurity in general and MDS2 in particular. Today, some hospitals even insist on receiving up-to-date MDS2 documentation as part of the procurement process — accelerating adoption.

Hopefully, we’ll soon reach a time when buyer committees consider MDS2 forms an integral part of their purchase decision. When that happens, manufacturers who offer stronger security controls and more advanced authentication, access protection, and auditing capabilities will get more business — empowering an industry-wide hardening of security.

The Value of MDS2

Properly used, MDS2 holds value for a range of different departments and stakeholders. From IT teams to cybersecurity employees to compliance professionals and biomedical folk, MDS2 forms contain key information about the nature of data stored on a device, its supported communication types, authorized management access standards, audit controls, antivirus compatibility, interoperability, operating systems, and more.

Indeed, smart and streamlined integration of MDS2 information into normal management and operational workflows can be a key enabler for healthcare excellence. Here’s how that breaks down across departments.

MDS2 for IT Teams

For IT teams, MDS2 information can help optimize device deployments, avoid double work, improve resilience, and more intelligently plan for long-term support. For example, how will a device's software be updated? What default functionalities/configurations should be disabled/adjusted to best fit your intended applications and IT ecosystem? What type of data backup and recovery capabilities are built into the device? What could be added? These are all questions that forward-thinking IT managers will want to ask and they all have answers clearly written in the black and white of the MDS2 form.

A more descriptive view of a device’s digital capabilities and out-of-the-box footprint can also tell you what to keep an eye on when looking for deviations that may serve as precursors to operational or security issues. In this sense, for IT teams, MDS2 should be a key guide in the course of day-to-day work, showing you the best places to look for likely misconfigurations, deployment errors, and other IT pitfalls.

MDS2 for IS Teams

MDS2 is another brick in the wall of effective healthcare cybersecurity. It informs your understanding of cyber risk, the chances of a breach, and the impact that would have on your system along with its data. Details about the device’s built-in security features and relevant characteristics help you define your cyber controls and protocols.

For example, a device's MDS2 form will include information on anti-virus compatibility and management requirements/capabilities. Of course that may sound like basic stuff, but it's imperative to proper endpoint protection; and when you're fielding thousands of devices subject to different requirements and limitations, making sure each device has a suitable and up-to-date anti-virus installed can be a huge challenge. Making smart use of your MDS2 records renders that challenge vastly more manageable.

If you can upload and integrate those records into your native solution stack, it will make the information contained all the more accessible and keep things running even smoother.

For another example, consider how, using MDS2, security teams investigating a vulnerability or incident can quickly narrow down the search radius for potential dissemination vectors.

MDS2 for BioMed Personnel

Biomedical teams can refer to MDS2 forms to find key information about each device’s predicted lifetime and ongoing central security support. This helps you keep on top of device end-of-life management, and avoid serious security issues that can arise when manufacturers stop sending security updates.

MDS2 should be the first port of call for biomedical professionals seeking guidance around the configuration and operation of clinical devices. In the MDS2, manufacturers provide very actionable information about standard port configurations, what type of bloatware to expect (important when you’re trying to identify and uninstall rogue software), network connectivity parameters, supported communication types, and more.

MDS2 for Compliance Officers

MDS2 forms give compliance stakeholders a sort of crib sheet outlining the most likely areas of a device deployment to raise potential regulatory concerns. In the MDS2 form, you can see what type of data a device is designed to handle and what type of privacy controls or compatibilities the device is subject to.

For example, if you know that a given device locally stores protected health information (PHI) that it receives and transfers via networks, and there’s encryption at the point of storage but not across transmissions, you’ll know where to focus your compliance efforts.

Of course, it’s important to point out that the device does not exist in a vacuum and its MDS2 information should not be stripped away from its operational context. To get the most value from the MDS2 form, you need to combine the information gained with the information you already possess about how your hospital operates and how it uses its technologies. So just because, for instance, your MDS2 tells you that a given device is built to be able to process and store PHI, doesn’t mean that is actually how it’s used.

In other words, for best results, the technical information contained in the MDS2 needs to be seen through the prism of your actual use cases.

Why Aren’t MDS2 Forms More Used?

With so many practical applications, you’d expect to find MDS2 at the heart of every healthcare organization's security plan, but that’s not yet the case. Not every manufacturer supplies an MDS2 form, and not every healthcare institution requests one.

When hospitals and medical centers do get the MDS2, it’s often another piece of paperwork to be filed and forgotten about. Too many medical centers carefully silo their MDS2 forms out of reach of the personnel who’d find them the most useful. In most hospitals, it's likely some IT, IS, biomedical, and compliance personnel don't even know that MDS2 form exists.

As Banner Health’s Compliance Program Director, Priyanka Upendra, remarked at a recent AAMI Roundtable Discussion, “[the real issue is] how HDOs consume [MDS2] information?... will it be another document that we go on collecting without knowing how to use?... I don't think more than half of HDOs even have the skillset or resources to use information in the MDS2 documents.”

Implementing MDS2

Implementing-MDS2To draw MDS2 out of the filing cabinet and into regular use, you need to first build it into your strategic planning and then into your processes and operational technologies.

By planning ahead and integrating MDS2 forms into your standard workflows, biomedical, IT, compliance, and IS teams can be more precise and surgical with each motion — removing guess-work and ultimately building smarter, safer, and faster processes.

Leaders from all these teams should meet to discuss how to make the best use of MDS2 forms. They should plan how to use the data, as well as when to use MDS2 information as a shared frame of reference for all stakeholders to gather around. Since the consensus of the hive mind alone will not get people used to working with MDS2 in the course of their daily tasks, it’s also important to build a MDS2 best practices curriculum and hold some training sessions. Write out and formalize your standard operating procedures and highlight where MDS2 plays in.

Once you have a well thought out and well-defined plan in place for how to regularly leverage your MDS2 forms, you’ll need to build it into your operational infrastructure. That means integrating MDS2 into your workflows and toolbox in such a way that your above-defined SOP can flow naturally and fluidly without encountering silo or out-of-process issues.

You’ll want to make sure that your MDS2 forms are fully digitized and integrated into your CMMS and HIT management databases so their contents can be easily indexed and searched. Pulling on this data integration, you may want to configure automated notifications or alerts based on your fleet, its MDS2 characteristics, device lifecycle milestones, and cross-referenced vendor advisories.

As much as possible, it’s important to avoid manual work and the introduction of redundant or overlapping tooling. The best way to make sure that the information is actually seen and used is to build it into the tools that your teams are already using.

As a founding MDISS member, for example, CyberMDX automatically pulls the consortium's accumulated MDS2 database into its solution interface. Relevant information is then itemized and populated to a hospital's asset inventory. The result is a more integrated, more detailed, more actionable, and more searchable endpoint directory — accessible from wherever you work.

Once you have a manageable system in place that allows you to search and retrieve specific pieces of security information based on the device or risk dimension of your choosing, you can conduct quantitative and qualitative risk analyses. The goal should be to identify any cybersecurity control gaps, bridge those gaps, and then work to design effective risk mitigation and management regimes.


Although MDS2 adoption is growing across the industry, a ton of value still being left on the table. For most hospitals, MDS2 is the epitome of low hanging fruit. It’s incredibly useful information that is being largely ignored. The underlying obstacles are inconvenience, unfamiliarity, and poor access management. With appropriate forethought and planning, these obstacles can be removed and added value can be unlocked.

Better use of MDS2 information can be a key enabler for healthcare excellence —  across IT, IS, BioMed, and compliance teams. Through smart system and process based integration, MDS2 can and must be better leveraged by hospitals and medical centers. Until we do, we’ll only be hurting ourselves.