ANSI/NEMA HN 1-2019

American National Standard—

Manufacturer Disclosure Statement for
Medical Device Security

Published by

National Electrical Manufacturers Association

1300 North 17th Street, Suite 900
Rosslyn, Virginia 22209

www.nema.org

© 2019 National Electrical Manufacturers Association. All rights including translation into other
languages, reserved under the Universal Copyright Convention, the Berne Convention for the
Protection of Literary and Artistic Works, and the International and Pan American Copyright
Conventions.

NEMA grants permission to make copies of and use the form in Section 5. Any translations, in full
or in part, of the MDS2 document should retain the original section labels.
 NOTICE AND DISCLAIMER
The information in this publication was considered technically sound by the consensus of persons
engaged in the development and approval of the document at the time it was developed. Consensus
does not necessarily mean that there is unanimous agreement among every person participating in
the development of this document.
The National Electrical Manufacturers Association (NEMA) Standards and guideline publications, of
which the document contained herein is one, are developed through a voluntary consensus
Standards development process. This process brings together volunteers and/or seeks out the views
of persons who have an interest in the topic covered by this publication. While NEMA administers
the process and establishes rules to promote fairness in the development of consensus, it does not
write the document, and it does not independently test, evaluate, or verify the accuracy or
completeness of any information or the soundness of any judgments contained in its Standards and
guideline publications.
NEMA disclaims liability for any personal injury, property, or other damages of any nature
whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting
from the publication, use of, application, or reliance on this document. NEMA disclaims and makes
no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information
published herein, and disclaims and makes no warranty that the information in this document will
fulfill any of your particular purposes or needs. NEMA does not undertake to guarantee the
performance of any individual manufacturer or seller’s products or services by virtue of this Standard
or guide.
In publishing and making this document available, NEMA is not undertaking to render professional
or other services for or on behalf of any person or entity, nor is NEMA undertaking to perform any
duty owed by any person or entity to someone else. Anyone using this document should rely on his
or her own independent judgment or, as appropriate, seek the advice of a competent professional in
determining the exercise of reasonable care in any given circumstances. Information and other
Standards on the topic covered by this publication may be available from other sources, which the
user may wish to consult for additional views or information not covered by this publication.

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page i

CONTENTS

Section 1 GENERAL ....................................................................................................................... 1

1.1 SCOPE ............................................................................................................................ 1
1.1.1 The Role of Healthcare Delivery Organizations in the Security Management
Process ................................................................................................... 1
1.1.2 The Role of Medical Device Manufacturers in the Security Management
Process ................................................................................................... 1
1.2 REFERENCES ................................................................................................................ 1
1.3 DEFINITIONS .................................................................................................................. 2
Section 2 INSTRUCTIONS FOR OBTAINING, USING, AND COMPLETING MDS2 FORM ......... 6
2.1 OBTAINING THE MDS2 FORM (HEALTHCARE DELIVERY ORGANIZATIONS) ........ 6
2.2 USING THE MDS2 FORM (HEALTHCARE DELIVERY ORGANIZATIONS) ................ 6
2.2.1 DEVICE DESCRIPTION ........................................................................... 6
2.3 COMPLETING THE MDS2 FORM (MANUFACTURERS) ............................................. 6
2.3.1 GENERAL ............................................................................................... 6
2.3.2 DEVICE DESCRIPTION SECTION: ........................................................... 7
2.3.3 MANAGEMENT OF PERSONALLY IDENTIFIABLE INFORMATION (MPII): .. 8
2.3.4 AUTOMATIC LOGOFF (ALOF): ................................................................. 9
2.3.5 AUDIT CONTROLS (AUDT): ................................................................... 10
2.3.6 AUTHORIZATION (AUTH): ..................................................................... 12
2.3.7 CYBERSECURITY PRODUCT UPDATES (CSUP): ................................... 12
2.3.8 HEALTH DATA DE-IDENTIFICATION (DIDT): .......................................... 15
2.3.9 DATA BACKUP AND DISASTER RECOVERY (DTBK): ............................. 15
2.3.10 EMERGENCY ACCESS (EMRG): ............................................................ 16
2.3.11 HEALTH DATA INTEGRITY AND AUTHENTICITY (IGAU):........................ 16
2.3.12 MALWARE DETECTION/PROTECTION (MLDP): ..................................... 16
2.3.13 NODE AUTHENTICATION (NAUT): ......................................................... 17
2.3.14 CONNECTIVITY CAPABILITIES (CONN) ................................................. 17
2.3.15 PERSON AUTHENTICATION (PAUT): ..................................................... 18
2.3.16 PHYSICAL LOCKS (PLOK): .................................................................... 19
2.3.17 ROADMAP FOR THIRD-PARTY APPLICATIONS AND SOFTWARE
COMPONENTS IN DEVICE LIFE CYCLE (RDMP): ................................... 20
2.3.18 SOFTWARE BILL OF MATERIALS (SBOM) ............................................. 20
2.3.19 SYSTEM AND APPLICATION HARDENING (SAHD):................................ 21
2.3.20 SECURITY GUIDES (SGUD): ................................................................. 23
2.3.21 DATA STORAGE CONFIDENTIALITY (STCF): ......................................... 23
2.3.22 TRANSMISSION CONFIDENTIALITY (TXCF): ......................................... 24
2.3.23 TRANSMISSION INTEGRITY (TXIG): ...................................................... 24
2.3.24 REMOTE SERVICE (RMOT) ................................................................... 24
2.3.25 OTHER SECURITY CONSIDERATIONS (OTHR): .................................... 25
Section 3 COMPARISON WITH OTHER STANDARDS .............................................................. 26

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page ii

3.1 IEC TR 80001-2-2:2012 ................................................................................................ 26

3.2 ISO/IEC 27002:2013 ..................................................................................................... 27
3.3 NIST 800-53 r4 .............................................................................................................. 27
Section 4 DIFFERENCES BETWEEN MDS2 2013 AND 2019 .................................................... 28
4.1 Changes to Document Organization ............................................................................. 28
4.2 Changes to questions.................................................................................................... 28
4.3 Changes to the MDS2 form ........................................................................................... 29
4.4 Example Form ............................................................................................................... 29
Section 5 MDS2 FORM .................................................................................................................. 30

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page iii

Preamble
The Manufacturer Disclosure Statement for Medical Device Security (MDS2) is intended to support
security risk management within Healthcare Delivery Organizations by providing standardized
information on security, and privacy control features integrated within medical devices. The MDS2 is
best used as an input into an operational security plan. All security controls may not be appropriate
for all devices. Medical Device Manufacturers and Health Delivery Organizations need to evaluate
the appropriateness of each security control based on basic safety, essential performance, the
environment used, and the ability to control risk through compensating controls. The MDS2
discloses features and capabilities based on the design specification of the device. It does not
describe service processes, support commitments, or other business activities that are better
addressed via a business contract.

The MDS2 is provided by manufacturers in the spirit of transparency, recognizing that safe and
secure delivery of patient care is a responsibility shared between Medical Device Manufacturers and
Healthcare Delivery Organizations. Medical Device Manufacturers ensure the devices they place on
the market include industry-standard security controls to enable safe and secure operation.
Healthcare Delivery Organizations are responsible for operational security within their environment.

Foreword

This document consists of the Manufacturer Disclosure Statement for Medical Device Security
(MDS2) form and related instructions on how to complete the form. The intent of the MDS2 is to
supply healthcare delivery organizations with important information to assist them in assessing
cybersecurity risks associated with medical devices. This document focuses on only those elements
of the security risk assessment process associated with medical devices and can be used as input
into a security risk assessment that spans the entire organization. A standardized form: 1) allows
manufacturers to quickly respond to a potentially large volume of information requests from
healthcare delivery organizations regarding the security-related features of the medical devices they
manufacture; and 2) facilitates the healthcare delivery organization’s review of the large volume of
security-related information supplied by the manufacturers.
The manufacturer-completed MDS2 should:
a. Be useful to healthcare delivery organizations worldwide. The information presented
should be useful for any healthcare delivery organization that aspires to have an
effective information security risk management program.
b. Include device-specific information addressing the technical security-related attributes of
the individual device model and version.
c. Provide a simple, flexible way of collecting the technical, device-specific elements of the
common/typical information needed by healthcare delivery organizations (device
users/operators) to begin medical device information security (i.e., confidentiality,
integrity, availability) risk assessments.

Please be advised—The MDS2 form is not intended to nor should it be used as the sole basis for
medical device procurement. Writing procurement specifications requires a deeper and more
extensive knowledge of the security environment and the healthcare mission.
Using the information provided by the manufacturer in the MDS2 form together with information
collected about the care delivery environment (e.g., through tools such as ACCE, American College
of Clinical Engineering/ECRI’s Guide for Information Security for Biomedical Technology), the
healthcare delivery organization’s multidisciplinary risk assessment team can review assembled
information and make informed decisions on implementing a local security management plan.

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page iv

This form was originally adapted from portions of the ACCE/ECRI Biomedical Equipment Survey
Form, a key tool found in Information Security for Biomedical Technology: A HIPAA* Compliance
Guide (ACCE/ECRI, 2004). This form was published originally in 2004, MDS2 v. 1.0 (2004-11-01),
and then as a joint HIMSS/NEMA Standard in 2008, HIMSS/NEMA Standard HN 1-2008.

In 2010, International Electrotechnical Commission Standard IEC 80001-1, Application of risk

management for IT-networks incorporating medical devices, was published. This Standard deals
with the application of risk management to IT-networks incorporating medical devices and provides
the roles, responsibilities, and activities necessary for risk management. In 2012, a Technical Report
(TR) supplement to IEC 80001 was published, IEC/TR 80001-2-2, Guidance for the communication
of medical device security needs, risks, and controls. In this supplement, 19 relevant security
capabilities of a medical device or IT component are defined. The 19 high-level security capabilities
are "...intended to be the starting point for a security-centric discussion between vendor and
purchaser or among a larger group of stakeholders involved in a Medical Device IT-Network
project."
Since this goal closely matches the primary objective of the MDS2 initiative, NEMA has undertaken
an expansion and re-categorization of the MDS2 information provided by manufacturers in order to
closely align with the 19 IEC/TR 80001-2-2 security categories. IEC/TR 80001-2-8 addresses each
of the security capabilities and identifies security controls for consideration by Healthcare Delivery
Organizations and manufacturers.
In 2017, NEMA initiated a revision of the 2013 MDS2 to further improve the document functionality
and incorporate advances in technology. It also aims to capture improvements in cybersecurity
knowledge and the increased emphasis on cybersecurity in procurement the elevation of health
delivery organization security risk management practices.
NEMA recommends that the information in the MDS2 form be used as part of each organization’s
security compliance and risk assessment efforts. In the preparation of this Standards publication,
input of users and other interested parties has been sought and evaluated.
Inquiries, comments, and proposed or recommended revisions should be submitted to the
concerned NEMA product subdivision by contacting the:
Technical Director, Operations
National Electrical Manufacturers Association
1300 North 17th Street, Suite 900
Rosslyn, Virginia 22209

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page 1

Section 1 General
1.1 Scope
Information provided on the MDS2 form is intended to assist professionals responsible for
executing security risk assessments in their management of medical device security capabilities.
The information on the MDS2 form may be inappropriate for other purposes.
1.1.1 The Role of Healthcare Delivery Organizations in the Security Management Process
The healthcare delivery organization has the ultimate responsibility for providing effective security
management.
In order to effectively manage medical information security and comply with relevant regulations,
healthcare delivery organizations must employ administrative, physical, and technical safeguards—
many of which are extrinsic to the actual device.
For example, healthcare delivery organizations might include some of the following activities when
developing their security management programs:
a. Determine the types of data stored/transmitted by the manufacturer’s device.
b. Obtain a list of all security-related features incorporated on the manufacturer’s device and
document which features are desired and how they are to be configured.
c. Identify and document all devices and applications which will communicate with the
manufacturer’s device, including specific identification tags.
d. Document resilience and recovery plans that include the manufacturer’s device.
1.1.2 The Role of Medical Device Manufacturers in the Security Management Process
The greatest impact manufacturers can have on medical device security is to incorporate technical
safeguards (i.e., security features) in their devices to facilitate healthcare delivery organizations’
efforts in maintaining effective security programs and meeting any relevant regulatory requirements
and/or Standards. The medical device manufacturing industry is increasingly aware of the
importance of having effective security functionality in their devices. Manufacturers are generally
including such security-related requirements in the production of new devices based on healthcare
delivery organization needs and requirements.
Device manufacturers can assist healthcare delivery organizations in their security management
programs by offering information describing:
a. The type of data stored/transmitted by the manufacturer’s device;
b. How data is stored/transmitted by the manufacturer’s device;
c. Any security-related features incorporated in the manufacturer’s device.

1.2 References
The following reference documents are included herein as suggested further reading, supportive
material, and related publications:
Application of risk management for IT-networks incorporating medical devices—Part 1: Roles,
responsibilities and activities, IEC 80001-1:2010
Application of risk management for IT-networks incorporating medical devices—Part 2-1: Step by
Step Risk Management of Medical IT-Networks; Practical Applications and Examples, IEC 80001-
2-1:2012
Application of risk management for IT-networks incorporating medical devices—Part 2-2: Guidance
for the communication of medical device security needs, risks and controls, IEC/TR 80001-2-
2:2012

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page 2

Application of risk management for IT-networks incorporating medical devices—Part 2-8:

Application guidance—Guidance on standards for establishing the security capabilities identified in
IEC 80001-2-2, IEC/TR 80001-2-8:2016
Health Insurance Portability and Accountability Act of 1996 (HIPAA), Pub. L. 104-191 (USA)
Health Insurance Reform: Security Standards; Final Rule, 45 CFR pts.160, 162, 164 (USA, 2003).
General Data Protection Regulation (GDPR) (EU) 2016/679
Amended Act on the Protection of Personal Information (December 2016, ver.2, Japan).
Personal Information Protection and Electronic Documents Act (PIPEDA), Statutes of Canada,
2000.
Deciding When to Submit a 510(k) for a Change to an Existing Device, US FDA, 2017The 510(k)
Program: Evaluating Substantial Equivalence in Premarket Notifications [510(k)], US FDA, 2014
ISO-19770-2 Information technology—Software asset management—Part 2: Software identification
tag
NISTIR 8060, Guidelines for the Creation of Interoperable Software Identification (SWID) Tags
NIST Special Publication 800-121, Guide to Bluetooth Security
ISO/IEC 80001-2-8:2016, Application of risk management for IT-networks incorporating medical
devices
NIST SP 800-53 Rev 4
ISO 27002:2013
ISO/TR 11633-1:2009 Health informatics—Information security management for remote
maintenance of medical devices and medical information systems—Part 1: Requirements and risk
analysis
ISO/TR 11633-2:2009 Health informatics—Information security management for remote
maintenance of medical devices and medical information systems—Part 2: Implementation of an
information security management system (ISMS)

1.3 Definitions
These definitions are for use within this document only. Legal definitions may vary depending on
local jurisdiction. Where terms are identical to or adapted from source material, those sources are
identified.
1.3.1. Administrative Safeguards: Administrative actions, policies, and procedures to manage
the selection, development, implementation, and maintenance of security measures to protect
personally identifiable information and to manage the conduct of an organization’s workforce in
relation to the protection of that information. (source: adapted from HIPAA Security Rule)
1.3.2. Anti-malware Software: A type of software program designed to prevent, detect, or
remove malicious software (malware) on IT systems, as well as on individual computing devices.
(source: techtarget.com)
1.3.3. Application Whitelisting: An application whitelist is a list of applications and application
components (libraries, configuration files, etc.) that are authorized to be present or active on a host
according to a well-defined baseline (source: NIST SP 800-167)
1.3.4. Audit: To conduct an independent review and examination of system records and activities
in order to test the adequacy and effectiveness of data security and data integrity procedures, to
ensure compliance with established policy and operational procedures, and to recommend any
necessary changes. (source: IEC 62351-2, ed. 1.0)

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page 3

1.3.5. Audit Log: A chronological record of system activities that includes records of system
accesses and operations performed in a given period. (source: Indian Health Manual;
https://www.ihs.gov/ihm/)
1.3.6. Authorization: A right or a permission that is granted to a system entity to access a
system resource. (source: IEC 62351-2, ed. 1.0)
1.3.7. Authentication: Verifying the identity of a user, process, or device, often as a prerequisite
to allowing access to resources in an information system (source: IEC 62351-2, ed. 1.0)
1.3.8. Biometric Data: Identifies a human via measurement of a physical feature or repeatable
action of the individual (e.g., hand geometry, retinal scan, iris scan, fingerprint patterns, facial
characteristics, DNA sequence characteristics, voiceprints, handwritten signature). (source: MDS2-
2013)
1.3.9. Compensating Control: A cybersecurity compensating control is a safeguard or
countermeasure deployed, in lieu of, or in the absence of controls designed in by a device
manufacturer. These controls are external to the device design, configurable in the field, employed
by a user, and provide supplementary or comparable cyber protection for a medical device.
(source: FDA Postmarket Guidance 2016)
1.3.10. Credentials: Input or inputs provided to authenticate a user, such as a username and a
password. (source: custom definition)
1.3.11. Data and Systems Security: Operational state of a medical IT-network in which
information assets (data and systems) are reasonably protected from degradation of confidentiality,
integrity, and availability (source: IEC 80001-1:2010, definition 2.5.)
1.3.12. De-identification: General term for any process of removing the association between a
set of identifying data and the data subject. (source: ISO/TS 25237:2017)
1.3.13. Device: A product/system, including hardware, firmware, and/or (only) software, etc. In this
MDS2 document, “device” refers to the medical device (the manufacturer’s product), which is being
addressed by the manufacturer in the MDS2 form, unless otherwise clear from the context. See
also medical device. (source: custom definition)
1.3.14. Dynamic Application Security Testing (DAST): A platform option that enables testing of
application security for detecting potential software vulnerabilities. (source: custom definition)
1.3.15. Electronic Media: Electronic storage media, including memory devices in computers (hard
drives) and any removable/transportable digital memory media, such as magnetic tapes or disks,
optical disks, or digital memory cards; and transmission media, used to exchange information
already in electronic storage media, including, for example, the Internet (wide open), extranet
(using Internet technology to link a business with information accessible only to collaborating
parties), leased lines, dial-up lines, and private networks, and the physical movement of
removable/transportable electronic storage media. Certain transmissions, including of paper via
facsimile and of voice via telephone, are not considered to be transmissions via electronic media
because the information being exchanged did not exist in electronic form before the transmission.
(source: adapted from HIPAA)
1.3.16. Electronic Protected Health Information (ePHI): Protected health information (PHI)
provided in electronic form. (source: custom definition)
1.3.17. Emergency Access: Process or mechanism by which a device user can quickly and
easily access the intended functionality in urgent or emergency situations, bypassing the device’s
established access controls; the ability of the device user to access the intended functionality in
case of an emergency situation that requires immediate access to the medical device. (source:
AAMI TIR57:2016)
1.3.18. Harm: Physical injury or damage to the health of people, or damage to property or the
environment, or reduction in effectiveness, or breach of data and system security. (source: IEC

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page 4

80001-1:2010, definition 2.8) Note: This definition is more expansive than some regulatory
definitions.
1.3.19. Intended Use: Use for which a product, process, or service is intended according to the
specifications, instructions, and information provided by the manufacturer. (source: ISO 14971:
2007, Application of risk management to medical devices, definition 2.5)
1.3.20. Malware: A malicious software program that is inserted into a system, usually covertly,
with the intent of compromising the confidentiality, integrity, or availability of the victim’s data,
applications, or operating system or of otherwise annoying or disrupting the victim. (source: NIST
SP 800-83, Guide to Malware Incident Prevention and Handling)
1.3.21. Medical Device: Any instrument, apparatus, implement, machine, appliance, implant, in
vitro reagent or calibrator, software, material or other similar or related article:
a. intended by the manufacturer to be used, alone or in combination, for human beings
for one or more of the specific purpose(s) of:
1. diagnosis, prevention, monitoring, treatment or alleviation of disease,
2. diagnosis, monitoring, treatment, alleviation of or compensation for an injury,
3. investigation, replacement, modification, or support of the anatomy or of a
physiological process,
4. supporting or sustaining life,
5. control of conception,
6. disinfection of medical devices,
7. providing information for medical or diagnostic purposes by means of in vitro
examination of specimens derived from the human body;
b. which does not achieve its primary intended action in or on the human body by
pharmacological, immunological or metabolic means, but which may be assisted in its
intended function by such means.
(source: Global Harmonization Task Force, Definition of the terms medical device and
In Vitro Diagnostic (IVD) device)
1.3.22. Operator: The person(s) using a medical device for its intended purpose. (source: custom
definition)
1.3.23. Patch Tag: The identifier for a specific patch. (source: NIST IR 8060: Guidelines for the
Creation of Interoperable Software ID (SWID) Tags)
1.3.24. Personal Identification Number (PIN): A number or code assigned to an individual and
used to provide verification of identity. (source: custom definition)
1.3.25. Protected Health Information (PHI): Individually identifiable health information (IIHI) that
is transmitted by electronic media; maintained in electronic media; or transmitted, or maintained, in
any other form or medium. (source: extracted from 45CFR Section 160) Note: This is a subset of
PII.
1.3.26. Protected Personal Information (PPI): Information regarding a person that is to be
protected from public disclosure. This may include health, financial, and other types of information.
It applies to all persons, not just patients. Within the MDS2, this is called personally identifiable
information, the term from IEC TR 80001-2-2:2012. (source: custom definition)
1.3.27. Physical Safeguards: The physical measures, policies, and procedures to protect an
organization’s electronic information systems and related buildings and equipment from natural and
environmental hazards and unauthorized intrusion. (source: MDS2-2013)
1.3.28. Personally Identifiable Information (PII): Any information about an individual maintained
by an agency, including (1) any information that can be used to distinguish or trace an individual‘s
identity… and (2) any other information that is linked or linkable to an individual, such as medical,

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page 5

educational, financial, and employment information (source: from NIST 800-122). Note: Local laws
may provide local legal definitions of PII and may change without warning.
1.3.29. Process: A set of interrelated or interacting activities which transforms inputs into outputs.
(source: ISO 9001)
1.3.30. Remote Service: A support service (e.g., testing, diagnostics, software upgrades) while
not physically or directly connected to the device (e.g., remote access via modem, network,
Internet). (source: HIMSS Dictionary of Healthcare Terms)
1.3.31. Removable Media: Electronic media that can be removed from a system without the use
of tools. (source: MDS2-2013)
1.3.32. Risk: The combination of the probability of occurrence of harm and the severity of that
harm (source: ISO 14971)
1.3.33. Risk Assessment: Conducting an accurate and thorough analysis of the potential risks
and vulnerabilities to the integrity, availability, and confidentiality of personally identifiable
information or system functions. (source: adapted from HIPAA)
1.3.34. Risk Management: The ongoing process of risk assessment. Taking steps to reduce risk
to an acceptable level and maintaining that level of risk. Security measures that are sufficient to
reduce risks and vulnerabilities to a reasonable and appropriate level. (source: custom definition)
1.3.35. Safety: Freedom from unacceptable risk (source: ISO 14971)
1.3.36. Security Control: Management, operational, and technical controls (i.e., safeguards or
countermeasures) prescribed for an information system to protect the confidentiality, integrity, and
availability of the system and its information. (source: NIST)
1.3.37. Security Capability: The broad category of technical, administrative, or organizational
controls to manage risks of confidentiality, integrity, and availability and accountability of data and
systems.( source: MDS2-2013)
1.3.38. Security Information and Event Management (SIEM): Technology that supports threat
detection and security incident response through the real-time collection and historical analysis of
security events from a wide variety of events and contextual data sources. (source: custom
definition)
1.3.39. Software as a Medical Device: software intended to be used for one or more medical
purposes that perform these purposes without being part of a hardware medical device (source:
IMDRF Software as a Medical Device (SAMD): Key Definitions)
1.3.40. medical device
1.3.41. Software ID Tag: A set of data elements that identify and describe a software product.
(source: NIST IR 8060: Guidelines for the Creation of Interoperable Software ID (SWID) Tags)
1.3.42. Technical Safeguards: The technology, policies, and procedures to protect data,
including personally identifiable information and control access to it. (source: custom definition)
1.3.43. Token: A physical authentication device that the user carries (e.g., smartcard, SecurIDtm,
etc.). Often combined with a PIN to provide a two-factor authentication method that is generally
thought of as superior to simple password authentication. (source: custom definition)
1.3.44. User: See operator.
1.3.45. Virus: See malware.
1.3.46. Vulnerability: Weakness in a device, information system, system security procedures,
internal controls, or implementation that could be exploited or triggered by a threat source. (source:
adapted from NIST SP 800-53)

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page 6

Section 2 Instructions for Obtaining, Using, And Completing MDS2 Form

2.1 Obtaining the MDS2 Form (Healthcare Delivery Organizations)

Completed MDS2s may be available from the device manufacturer (e.g., manufacturer website).
This form may be updated to reflect changes to the device specifications. Users should ensure that
the MDS2 corresponds to the correct model and revision level of the device. Questions pertaining
to manufacturer processes and policies reflect the latest manufacturer information as of the
document release date.
Note: If a manufacturer does not have a completed MDS2 form for the appropriate device(s),
enter manufacturer and model information in the appropriate boxes on the top of a blank
MDS2 form, and submit the form(s) and these instructions to the manufacturer’s compliance
office for completion.

2.2 Using the MDS2 Form (Healthcare Delivery Organizations)

2.2.1 Device Description

The MDS2 describes the security and privacy protection features associated with a single medical
device as indicated in the MDS2 device description (DOC-2) and model (DOC-3).
The first two sections of the MDS2 form are used to identify the device (device description) and
describe the type of data stored/transmitted by the device and how the data is stored/transmitted,
etc. (management of personally identifiable information).
Please be advised—an indication of a device’s ability to perform any listed function (i.e., a “Yes”
answer) is not an implicit or explicit endorsement or authorization by the manufacturer to configure
the device or cause the device to perform those listed functions.
It is important to distinguish between capability and permission. Unless otherwise indicated, the
questions contained on the MDS2 form generally refer to device capability. Permission is typically a
contractual matter separate from the MDS2 form. Making changes to a medical device without
explicit manufacturer authorization may have significant contractual, safety, and liability issues.

2.3 Completing the MDS2 Form (Manufacturers)

Section 2.3 of the MDS2 (completing the MDS2 form) contains information on the specific security
capabilities of the device. The information is organized into categories aligned with IEC 80001-2-2,
Guidance for the communication of medical device security needs, risks, and controls.
The MDS2 form contains space for explanatory notes if the manufacturer needs to explain specific
details of the manufacturer’s answers to questions.
Note: Manufacturers may elect to attach supplementary material if additional space for
recommended practices or explanatory notes is necessary.

2.3.1 General
The manufacturer shall provide the information requested in the MDS2 form to the requesting
organization, including all requested descriptive information on the type of data stored/transmitted
by the device, how the data is stored/transmitted, and other security-related features incorporated
in the device, as appropriate.

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page 7

This information should be based on specific device design, software development, and production
characteristics. This information will be used for cybersecurity purposes and should be written with
that purpose in mind.
To simplify the evaluation and automation of this form, the manufacturer shall answer all questions
either “Yes,” “No,” or “N/A” (not applicable). When additional information is appropriate, add “See
Note X.” and identify the relevant note that further clarifies the answer.
This form comprises many sections. Some of these sections might not apply to a particular device.
All of the sections should be filled, with "NO" or "N/A" answers where appropriate.
If additional information is needed for proper interpretation of an answer, manufacturers are
encouraged to provide information in explanatory notes.
When the answer could vary depending upon options and accessories installed, explain this in the
accompanying notes for the individual question answered.
Extensive answers can also be referenced to other published documents, e.g., by hyperlinks or
document identification and location references within the document. Please include a brief
summary when detailed documents are referenced. This should describe how to obtain the
documents referenced.
When answers to multiple questions refer to notes, each reference should indicate the specific
location in the notes where that question is answered.
Devices that are software-only, such as "apps" and plugins, should still fill in the relevant sections
and indicate "N/A" for those sections that only apply to physical devices.
Note: the numbers in the subsequent subsections correlate to the question numbers in the
MDS2 form.

2.3.2 Device Description Section:

DOC-1 Manufacturer Name: This is a free-text field.
DOC-2 Device Description: This is a free-text field. The manufacturer should use standard
terminology that customers would reasonably understand to differentiate key modalities or
device functionality. The manufacturer may use the device name associated with the FDA
designated product code, the ECRI Institute device code, or other generic device
nomenclature. The manufacturer should not use internal product description names based on
marketing material, tradenames, or copyrighted names.
DOC-3 Device Model: This is a free-text field. The manufacturer should use the model of the
device under which it is placed on the market. This may include the model listed on the
customer-facing panel, the model as listed on the device identification tag, or the catalog ID as
applicable.
DOC-4 Document ID: The document ID is the manufacturer’s unique tag used internally to
track device documentation.
DOC-5 Manufacturer Contact Information: A role or department generic email and central
phone number may be provided.
DOC-6 Intended use of a device in network-connected environment: This allows the
manufacturer to describe the intended function and use of the device and, if relevant, how the
device is expected to be used if connected to a customer’s network environment.
DOC-7 Document Release Date: Date (YYYY-MM-DD) of document release for customer use.
DOC-8 Coordinated Vulnerability Disclosure: Does the manufacturer have a vulnerability
disclosure program for this device? If yes, provide details or reference in notes.
DOC-9 ISAO: Is the manufacturer part of an Information Sharing and Analysis Organization?

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page 8

DOC-10 Diagram: Is a network or data flow diagram available that indicates connections to
other system components or expected external resources? If yes, provide details or reference
in notes.
DOC-11 SaMD: Is the device Software as a Medical Device (i.e., software-only, no hardware)?
If no, answer “N/A” to questions in this section.
DOC-11.1 Does the SaMD contain an operating system? (See CSUP-2 for more
information on device operating system.)
DOC-11.2 Does the SaMD rely on an owner/operator provided operating system? If yes,
provide details or reference in notes.
DOC-11.3 Is the SaMD hosted by the manufacturer? If yes, provide details or reference in
notes.
DOC-11.4 Is the SaMD hosted by the customer? If yes, provide details or reference in
notes.
The security capabilities sections of the MDS2 form contains questions regarding the specific
security-related features of the device. The questions are organized into the security capabilities
categories of IEC 80001-2-2, guidance for the communication of medical device security needs,
risks, and controls where possible. Additional categories are also included.
2.3.3 Management of Personally Identifiable Information (MPII):
How personally identifiable information is handled on or by the device.
MPII-1 Can this device display, transmit, store, or modify personally identifiable
information (e.g., electronic Protected Health Information (ePHI))? If yes, provide
details or reference in notes.
Guidance: Indicate in the notes PII elements that can be maintained by the device
(e.g., patient name, patient ID, social security number, biometric data), or provide
reference to product documentation for complete list.
MPII-2 Does the device maintain personally identifiable information?
MPII-2.1 Does the device maintain personally identifiable information temporarily in volatile
memory (i.e., until cleared by power-off or reset)?
MPII-2.2 Does the device store personally identifiable information persistently on internal
media?
MPII-2.3 Is personally identifiable information preserved in the device’s non-volatile memory
until explicitly erased?
MPII-2.4 Does the device store personally identifiable information in a database? If yes,
provide details or reference in notes.
MPII-2.5 Does the device allow configuration to automatically delete local personally
identifiable information after it is stored to a long-term solution?
MPII-2.6 Does the device import/export personally identifiable information with other
systems (e.g., a wearable monitoring device might export personally identifiable
information to a server)?
MPII-2.7 Does the device maintain personally identifiable information when powered off, or
during power service interruptions?
MPII-2.8 Does the device allow the internal media to be removed by a service technician
(e.g., for separate destruction or customer retention)?

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page 9

MPII-2.9 Does the device allow personally identifiable information records to be stored in a
separate location from the device’s operating system (i.e., secondary internal
drive, alternate drive partition, or remote storage location)?
MPII-3 Does the device have mechanisms used for the transmitting, importing/exporting of
personally identifiable information?
Guidance: Indicate in the notes if the mechanism listed is optional.
MPII-3.1 Does the device display personally identifiable information (e.g., video
display, etc.)?
MPII-3.2 Does the device generate hardcopy reports or images containing personally
identifiable information?
MPII-3.3 Does the device retrieve personally identifiable information from or record
personally identifiable information to removable media (e.g., removable-HDD, USB
memory, DVD-R/RW, CD-R/RW, tape, CF/SD card, memory stick, etc.)?
MPII-3.4 Does the device transmit/receive or import/export personally identifiable
information via dedicated cable connection (e.g., RS-232, RS-423, USB, FireWire,
etc.)?
MPII-3.5 Does the device transmit/receive personally identifiable information via a wired
network connection (e.g., RJ45, fiber optic, etc.)?
MPII-3.6 Does the device transmit/receive personally identifiable information via a wireless
network connection (e.g., WiFi, Bluetooth, NFC, infrared, cellular, etc.)?
MPII-3.7 Does the device transmit/receive personally identifiable information over an
external network (e.g., Internet)?
MPII-3.8 Does the device import personally identifiable information via scanning a
document?
MPII-3.9 Does the device transmit/receive personally identifiable information via a
proprietary protocol?
MPII-3.10 Does the device use any other mechanism to transmit, import, or export personally
identifiable information? If yes, provide details or reference in notes.

2.3.4 Automatic Logoff (ALOF):

The device’s ability to prevent access and misuse by unauthorized users if the device is left idle for
a period of time.

ALOF-1 Can the device be configured to force reauthorization of logged-in user(s) after a
predetermined length of inactivity (e.g., auto-logoff, session lock, password-
protected screen saver)?
Guidance: Does the device, by default, or by configuration, always: 1) Enforce
reauthorization after a specified period of inactivity; 2) Activate a password-
protected screen saver after a preselected period of inactivity that effectively
prevents user access even without logging the user off? The notes section may be
used to indicate if/how an auto-logoff or screen lock function can be disabled (e.g.,
per session or globally with appropriate user security warnings/notification?)

ALOF-2 Is the length of inactivity time before auto-logoff/screen lock user or administrator
configurable? If yes, indicate time, fixed, or configurable range in notes.

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page 10

Guidance: Can the user or administrator configure the amount of time that must
elapse before auto-logoff or screen lock occurs? The notes section should be
used to indicate whether a device with adjustable auto-logoff/screen lock can be
configured: 1) To a user-determined time; 2) by specific role (e.g., administrator,
user).

2.3.5 Audit Controls (AUDT):

The ability to reliably audit activity on the device.

Note: for many of the questions in this subsection, there may be a document that describes the
audit capabilities in much greater detail. In that case, an answer of YES, together with a note
referencing the more detailed description document, is appropriate.
AUDT-1 Can the medical device create additional audit logs or reports beyond standard
operating system logs?
Guidance: If the answer is no, then answers to AUDT-1.1 through AUDT-3.1
should be “N/A.”
AUDT-1.1 Does the audit log record a USER ID?
Guidance: If yes, indicate in the notes if the data subject (e.g., patient) is identified
for each personally identifiable information event in the log. Additionally, indicate
in the notes if the audit trail can differentiate between the creation/display/export,
etc. of personally identifiable information vs. other data.
AUDT-1.2 Does other personally identifiable information exist in the audit trail?
Guidance: If yes, indicate in the notes if the data subject (e.g., patient) is identified
for each personally identifiable information event in the log. Additionally, indicate
in the notes if the audit trail can differentiate between the creation/display/export,
etc. of personally identifiable information vs. other data.

AUDT-2 Are events recorded in an audit log? If yes, indicate which of the following events
are recorded in the audit log:
AUDT-2.1 Successful login/logout attempts?
AUDT-2.2 Unsuccessful login/logout attempts?
AUDT-2.3 Modification of user privileges?
AUDT-2.4 Creation/modification/deletion of users?
AUDT-2.5 Presentation of clinical or PII data (e.g., display, print)?
AUDT-2.6 Creation/modification/deletion of data?
Guidance: If yes, indicate in the notes which forms of data manipulation (creation
and/or modification and/or deletion) are tracked.
AUDT-2.7 Import/export of data from removable media (e.g., USB drive, external hard drive,
DVD)?
Guidance: If yes, indicate in the notes what level of detail is captured (e.g., only
patient ID, a list of document IDs).

AUDT-2.8 Receipt/transmission of data or commands over a network or point-to-point

connection?

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page 11

Guidance: If yes, indicate in the notes what level of detail is captured (e.g., only
patient ID, a list of document IDs).
AUDT-2.8.1 Remote or on-site support?
Guidance: If yes, indicate in the notes, what types of service activity are tracked.
AUDT-2.8.2 Application Programming Interface (API) and similar activity?
Guidance: If yes, indicate in the notes the proprietary and standard network APIs,
such as FHIR from HL7, which the device supports and audits for logging. Indicate
if further information can be found in the product documentation.
AUDT-2.9 Emergency access?
Guidance: If yes, indicate in the notes, the device’s ability to log instances of
emergency access. The manufacturer may also indicate:
a. If/how the device prompts an emergency user for a
(temporary/"emergency") username and/or hospital/clinic ID # that is then
recorded in the audit log.
b. If/how the device identifies or "flags" data acquired during an "emergency"
session (e.g., data obtained without an authorized user logged in).

AUDT-2.10 Other events (e.g., software updates)? If yes, provide details or reference in notes.
AUDT-2.11 Is the audit capability documented in more detail? If yes, provide details or
reference in notes.
AUDT-3 Can the owner/operator define or select which events are recorded in the audit
log? If yes, provide details or reference in notes.
AUDT-4 Is a list of data attributes that are captured in the audit log for an event available? If
yes, provide details or reference in notes.
Guidance: Indicate in the notes data attributes captured in the audit log or provide
reference to product documentation for a complete list.
AUDT-4.1 Does the audit log record date/time?
AUDT-4.1.1. Can date and time be synchronized by Network Time Protocol (NTP) or equivalent
time source?
Guidance: Indicate in the notes how the device time is set if not using NTP.
AUDT-5 Can audit log content be exported?
AUDT-5.1 Via physical media?
AUDT-5.2 Via IHE Audit Trail and Node Authentication (ATNA) profile to SIEM?
AUDT-5.3 Via other communications (e.g., external service device, mobile applications)? If
yes, provide details or reference in notes.
AUDT-5.4 Are audit logs encrypted in transit or on storage media? If yes, provide details or
reference in notes.
AUDT-6 Can audit logs be monitored/reviewed by the owner/operator? If no, provide details
or reference to audit process in notes.
AUDT-7 Are audit logs protected from modification? If yes, provide details or reference in
notes.

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page 12

AUDT-7.1 Are audit logs protected from access? If yes, provide details or reference in
notes.
AUDT-8 Can audit logs be analyzed by the device? If so, provide reference in notes.

2.3.6 Authorization (AUTH):

The ability of the device to determine the authorization of users.

AUTH-1 Does the device prevent access to unauthorized users through user login
requirements or other mechanism?
Guidance: If yes, indicate in the notes what physical or technical safeguards the
device uses to prevent unauthorized access (password, biometrics, keycard, etc.).
AUTH-1.1 Can the device be configured to use federated credentials management of users
for authorization (e.g., LDAP, OAuth)? If yes, provide details or reference in notes.
AUTH-1.2 Can the customer push group policies to the device (e.g., Active Directory)? If yes,
provide details or reference in notes.
AUTH-1.3 Are any special groups, organizational units, or group policies required? If yes,
provide details or reference in notes.
AUTH-2 Can users be assigned different privilege levels based on 'role' (e.g., user,
administrator, and/or service, etc.)?
AUTH-3 Can the device owner/operator grant themselves unrestricted administrative
privileges (e.g., access operating system or application via local root or
administrator account)?
Guidance: If yes, indicate in the notes if the device supports more than one
privileged account (e.g., administrator, root) and any restrictions on users
regarding the use of administrator accounts.
AUTH-4 Does the device authorize or control all API access requests? If no, provide details
or reference in notes.
AUTH-5 Does the device run in a restricted access mode, or ‘kiosk mode,’ by default? If
yes, provide details or reference in notes.

2.3.7 Cybersecurity Product Updates (CSUP):

The ability of on-site service staff, remote service staff, or authorized customer staff to
install/update the device's security patches. Note that medical device manufacturers are required to
follow applicable device regulations that regulate a quality system, such as 21 CFR Part 820 in the
U.S., that often require validation of software design changes, including computer software
changes to address cybersecurity vulnerabilities.

Guidance: CSUP-1, CSUP-2, CSUP-3, CSUP-4, CSUP-5, and CSUP-6

Indicate in the notes any manufacturer restrictions on applying security patches. Notes can
reference product documentation where a description of these restrictions can be found.
CSUP-1 Does the device contain any software or firmware which may require security
updates during its operational life, either from the device manufacturer or from a
third-party manufacturer of the software/firmware? If no, answer “N/A” to questions
in this section.

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page 13

CSUP-2 Does the device contain an Operating System? If yes, complete 2.1-2.4.

CSUP-2.1 Does the device documentation provide instructions for owner/operator installation
of patches or software updates?

CSUP-2.2 Does the device require vendor or vendor-authorized service to install patches or
software updates?

CSUP-2.3 Does the device have the capability to receive remote installation of patches or
software updates?

CSUP-2.4 Does the medical device manufacturer allow security updates from any third-party
manufacturers (e.g., Microsoft) to be installed without approval from the
manufacturer?

CSUP-3 Does the device contain Drivers and Firmware? If yes, complete 3.1-3.4.

CSUP-3.1 Does the device documentation provide instructions for owner/operator installation
of patches or software updates?

CSUP-3.2 Does the device require vendor or vendor-authorized service to install patches or
software updates?

CSUP-3.3 Does the device have the capability to receive remote installation of patches or
software updates?

CSUP-3.4 Does the medical device manufacturer allow security updates from any third-party
manufacturers (e.g., Microsoft) to be installed without approval from the
manufacturer?

CSUP-4 Does the device contain Anti-Malware Software? If yes, complete 4.1-4.4.

CSUP-4.1 Does the device documentation provide instructions for owner/operator installation
of patches or software updates?

CSUP-4.2 Does the device require vendor or vendor-authorized service to install patches or
software updates?

CSUP-4.3 Does the device have the capability to receive remote installation of patches or
software updates?

CSUP-4.4 Does the medical device manufacturer allow security updates from any third-party
manufacturers (e.g., Microsoft) to be installed without approval from the
manufacturer?

CSUP-5 Does the device contain Non-Operating System commercial off-the-shelf

components? If yes, complete 5.1-5.4.

CSUP-5.1 Does the device documentation provide instructions for owner/operator installation
of patches or software updates?

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page 14

CSUP-5.2 Does the device require vendor or vendor-authorized service to install patches or
software updates?

CSUP-5.3 Does the device have the capability to receive remote installation of patches or
software updates?

CSUP-5.4 Does the medical device manufacturer allow security updates from any third-party
manufacturers (e.g., Microsoft) to be installed without approval from the
manufacturer?

CSUP-6 Does the device contain other software components (e.g., asset management
software, license management)? If yes, provide details or reference in notes, and
complete 6.1-6.4.

CSUP-6.1 Does the device documentation provide instructions for owner/operator installation
of patches or software updates?

CSUP-6.2 Does the device require vendor or vendor-authorized service to install patches or
software updates?

CSUP-6.3 Does the device have the capability to receive remote installation of patches or
software updates?

CSUP-6.4 Does the medical device manufacturer allow security updates from any third-party
manufacturers (e.g., Microsoft) to be installed without approval from the
manufacturer?

CSUP-7 Does the manufacturer notify the customer when updates are approved for
installation? If so, provide details or reference it in notes.
CSUP-8 Does the device perform automatic installation of software updates?
CSUP-9 Does the manufacturer have an approved list of third-party software that can be
installed on the device? If so, describe or reference in notes the manufacturer-
approved third-party software list and/or the manufacturing process for managing
requests to approve additional third-party software.

CSUP-10 Can the owner/operator install manufacturer-approved third-party software on the

device themselves?

CSUP-10.1 Does the system have a mechanism in place to prevent installation of unapproved
software?
CSUP-11 Does the manufacturer have a process in place to assess device vulnerabilities
and updates?
CSUP-11.1 Does the manufacturer provide customers with review and approval status of
updates?
CSUP-11.2 Is there an update review cycle for the device? If so, provide details or reference in
notes.

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page 15

2.3.8 Health Data De-Identification (DIDT):

The ability of the device to directly remove information that allows identification of a person.

DIDT-1 Does the device provide an integral capability to de-identify personally identifiable
information? If yes, provide details or reference it in notes.
Guidance: Indicate in the notes if the de-identification process references/adheres
to any specific de-identification Standard/guideline, such as HIPAA Section
164.514(b). Also, indicate if the de-identification procedure is configurable.

DIDT-1.1 Does the device support de-identification profiles that comply with the DICOM
Standard for de-identification? If so, provide details or reference in notes.
Guidance: DICOM Standards generally apply to medical imaging technology.

2.3.9 Data Backup And Disaster Recovery (DTBK):

The ability to recover after damage or destruction of device data, hardware, software, or site
configuration information.

DTBK-1 Does the device maintain long term primary storage of personally identifiable
information / patient information (e.g. PACS)?
DTBK-2 Does the device have a “factory reset” function to restore the original device
settings as provided by the manufacturer?
DTBK-3 Does the device have an integral data backup capability to removable media? If
yes, provide details or reference it in notes.
Guidance: If yes, indicate in the notes any limitations or restrictions on data
backup/disaster recovery. This refers to an integrated feature or option that
supports information backup to removable media (e.g., optical disk, magnetic disk,
tape, etc.)
DTBK-4 Does the device have an integral data backup capability to remote storage? If yes,
provide details or reference it in notes.
Guidance: This refers to an integrated feature or option that supports information
backup to remote storage. Indicate in the notes any limitations or restrictions on
data backup/disaster recovery. If appropriate, describe how private information is
protected (e.g., by encryption or omission).
DTBK-5 Does the device have a backup capability for system configuration information,
patch restoration, and software restoration? If yes, provide details or reference in
notes.
Guidance: This refers to an integrated feature or option that supports information
backup to either local or remote storage Indicate in the notes any limitations or
restrictions on data backup/disaster recovery. If appropriate, describe how private
information is protected (e.g., by encryption or omission).
DTBK-6 Does the device provide the capability to check the integrity and authenticity of a
backup?

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page 16

2.3.10 Emergency Access (EMRG):

The ability of the device user to access personally identifiable information in case of a medical
emergency situation that requires immediate access to stored personally identifiable information.

EMRG-1 Does the device incorporate an emergency access (i.e., “break-glass”) feature? If
yes, provide details or reference it in notes.
Guidance: See “Definitions” section for a description of the term emergency
access.

2.3.11 Health Data Integrity and Authenticity (IGAU):

How the device verifies integrity, verifies authenticity, and assures the availability of stored health
data on the device. If the device does not store health data, answer “N/A” to questions in this
section.

IGAU-1 Does the device provide data integrity checking mechanisms of stored health data
(e.g., hash or digital signature)? If so, provide details or reference it in notes.
IGAU-2 Does the device provide error/failure protection and recovery mechanisms for
stored health data (e.g., RAID-5)? If yes, provide details or reference it in notes.

2.3.12 Malware Detection/Protection (MLDP):

The ability of the device to effectively prevent, detect, and remove malicious software (malware).

MLDP-1 Is the device capable of hosting executable software?

MLDP-2 Does the device support the use of anti-malware software (or another anti-malware
mechanism)? Provide details or reference it in notes.
Guidance: The manufacturer may indicate any restrictions on malware support
(purchase/installation/configuration) directly in the note or reference product
documentation where a description of these restrictions can be found.
MLDP-2.1 Does the device include anti-malware software by default?
MLDP-2.2 Does the device have anti-malware software available as an option?
MLDP-2.3 Does the device documentation allow the owner/operator to install or update anti-
malware software? If yes, provide details or reference in notes.
MLDP-2.4 Can the device owner/operator independently (re-)configure anti-malware
settings?
MLDP-2.5 Does notification of malware detection occur in the device user interface?
Guidance: If no, indicate in the notes how the user is notified when malware is
detected.
MLDP-2.6 Can only manufacturer-authorized persons repair systems when malware has
been detected? If yes, provide details or reference in notes.
MLDP-2.7 Are malware notifications written to a log?
MLDP-2.8 Are there any restrictions on anti-malware (e.g., purchase, installation,
configuration, scheduling)?

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page 17

MLDP-3 If the answer to MLDP-2 is NO, and anti-malware cannot be installed on the
device, are other compensating controls in place or available? If yes, provide
details or reference in notes.
Guidance: If the answer to MLDP-2 is YES, answer MLDP-3 as N/A.
MLDP-4 Does the device employ application whitelisting that restricts the software and
services that are permitted to be run on the device? If yes, provide details or
reference in notes.
MLDP-5 Does the device employ a host-based intrusion detection/prevention system? If
yes, provide details or reference in notes.
MLDP-5.1 Can the host-based intrusion detection/prevention system be configured by the
customer?
MLDP-5.2 Can a host-based intrusion detection/prevention system be installed by the
customer?

2.3.13 Node Authentication (NAUT):

The ability of the device to authenticate communication partners/nodes.

NAUT-1 Does the device provide/support any means of node authentication that assures
both the sender and the recipient of data are known to each other and are
authorized to receive transferred information (e.g., Web APIs, SMTP, SNMP)? If
yes, provide details or reference in notes.
NAUT-2 Are network access control mechanisms supported (E.g., does the device have an
internal firewall or use a network connection white list)? If yes, provide details or
reference in notes.
NAUT-2.1 Is the firewall ruleset documented and available for review? If yes, provide details
or reference in notes.
NAUT-3 Does the device use certificate-based network connection authentication? If yes,
provide details or reference in notes.
Guidance: If applicable, explain in the notes how certificates are managed.
2.3.14 Connectivity Capabilities (CONN)
All network and removable media connections must be considered in determining appropriate
security controls. This section lists connectivity capabilities that may be present on the device.

CONN-1 Does the device have hardware connectivity capabilities? If yes, provide details or
a reference that identifies the hardware connectivity capabilities of the device. If
no, indicate “none” in notes and answer “N/A” to questions in this section.
Guidance: Indicate in the notes a listing of hardware and basic operating system
capabilities that are installed, or optionally installed, on the device to connect to a
network. Also, indicate if the feature is a purchase option or can be disabled.
CONN-1.1 Does the device support wireless connections?
CONN-1.1.1 Does the device support Wi-Fi? If yes, please list or provide a reference to the
Wi-Fi authentication protocols supported (e.g., WPA2 EAP-TLS) in the notes.
CONN-1.1.2 Does the device support Bluetooth? If yes, please list or provide a reference to the
Bluetooth security modes supported and indicate if they can be forced in the notes.

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page 18

CONN-1.1.3 Does the device support other wireless network connectivity (e.g., LTE, Zigbee,
proprietary)? If yes, provide details or reference it in notes.
CONN-1.1.4 Does the device support other wireless connections (e.g., custom RF controls,
wireless detectors)? If yes, provide details or reference it in notes.
CONN-1.2 Does the device support physical connections?
CONN-1.2.1 Does the device have available RJ45 Ethernet ports?
CONN-1.2.2 Does the device have available USB ports? If yes, provide details or reference that
indicates use and how they are secured in notes.
CONN-1.2.3 Does the device require, use, or support removable memory devices? If yes,
provide details or reference it in notes.
CONN-1.2.4 Does the device support other physical connectivity? If yes, provide details or
reference in notes.
CONN-2 Does the manufacturer provide a list of network ports and protocols that are used
or may be used on the device? If yes, provide details or reference in notes.
Guidance: Indicate if the protocols are required for a network-connected device.
Be sure to include transport protocols (e.g., IPv4, IPv6), application protocols (e.g.,
DICOM, IEEE 11073, HL7), other service protocols (e.g., DHCP, SMB, RDP), and
any custom protocols. Identify the version when relevant.
CONN-3 Can the device communicate with other systems within the customer environment?
If yes, provide details or reference in notes.
CONN-4 Can the device communicate with other systems external to the customer
environment (e.g., a service host)? If yes, provide details or reference in notes.
CONN-5 Does the device make or receive API calls? If yes, provide details or reference in
notes.
CONN-6 Does the device require an internet connection for its intended use? If yes, provide
details or reference in notes.
CONN-7 Does the device support Transport Layer Security (TLS)? If yes, provide details or
reference about supported and prohibited versions of TLS in the notes.
CONN-7.1 Is TLS configurable? If yes, provide details or reference in notes.
CONN-8 Does the device provide operator control functionality from a separate device (e.g.,
telemedicine)? If yes, provide details or reference in notes.
2.3.15 Person Authentication (PAUT):
The ability to configure the device to authenticate users.

PAUT-1 Does the device support and enforce unique IDs and passwords for all users and
roles (including service accounts)?
PAUT-1.1 Does the device enforce authentication of unique IDs and passwords for all users
and roles (including service accounts)? If no, provide details or reference in notes.
PAUT-2 Is the device configurable to authenticate users through an external authentication
service (e.g., MS Active Directory, NDS, LDAP, OAuth, etc.)? If yes, provide
details or reference in notes.
Guidance: Indicate in the notes which mechanisms can be used.

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page 19

PAUT-3 Is the device configurable to lockout a user after a certain number of unsuccessful
login attempts? If yes, provide details or reference in notes.
Guidance: Indicate in the notes any details for user lockout features.
PAUT-4 Are all default accounts (e.g., technician service accounts, administrator accounts)
listed in the documentation? If no, provide details or reference in notes.
PAUT-5 Can all passwords be changed? If no, provide details or reference in notes.
PAUT-6 Is the device configurable to enforce the creation of user account passwords that
meet established (organization-specific) complexity rules? If so, provide details or
reference in notes.
Guidance: Answer “Yes” if password complexity is configurable. Answer “No” if
password complexity is not configurable, regardless of complexity requirements.
Indicate in the notes any complexity rules and limits.
PAUT-7 Does the device support account passwords that expire periodically? If yes,
provide details or reference in notes.
Guidance: Indicate in the notes the expiration frequency or administration controls
available.
PAUT-8 Does the device support multi-factor authentication? If yes, provide details or
reference in notes.
PAUT-9 Does the device support single sign-on (SSO)? If yes, provide details or reference
in notes
PAUT-10 Can user accounts be disabled/locked on the device?
PAUT-11 Does the device support biometric controls?
PAUT-12 Does the device support physical tokens (e.g., badge access)?
PAUT-13 Does the device support group authentication (e.g., hospital teams)?
PAUT-14 Does the application or device store or manage authentication credentials? If so,
provide details or reference in notes
PAUT-14.1 Are credentials stored using a secure method? If so, provide details or reference in
notes.

2.3.16 Physical Locks (PLOK):

Physical locks can prevent unauthorized users with physical access to the device from
compromising the integrity and confidentiality of personally identifiable information stored
on the device or on removable media.

PLOK-1 Is the device software only? If yes, answer “N/A” to the remaining questions in this
section.
PLOK-2 Are all device components maintaining personally identifiable information (other
than removable media) physically secure (i.e., cannot remove without tools)?
Guidance: This question refers to the typical installation and configuration of the
manufacturer's device. Consider internal data storage drives and any other storage
media that maintain personally identifiable information. Answer “Yes" if any such
media can be physically accessed and removed without tools. In this context, a
physical key required for access is considered a tool.

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page 20

PLOK-3 Are all device components maintaining personally identifiable information (other
than removable media) that are physically secured behind an individually keyed
locking device?
PLOK-4 Does the device have an option for the customer to attach a physical lock to
restrict access to removable media?
2.3.17 Roadmap for Third-Party Applications and Software Components in Device Life
Cycle (RDMP):
Manufacturer’s plans for security support of third-party applications and software components,
including custom components, within the device’s life cycle, such as how third-party End of Life will
be managed. See software bill of materials (SBOM), section 2.3.18, for questions regarding third-
party applications and software components that are used by the device or incorporated into the
device.

RDMP-1 Was a secure software development process, such as ISO/IEC 27034 or IEC
62304, followed during product development? If yes, provide details or reference in
notes.
Guidance: Describe or provide reference to any secure software development
Standards the device was developed in accordance with, or briefly describe the
secure software development process used.
RDMP-2 Does the manufacturer evaluate third-party applications and software components
included in the device for secure development practices?
RDMP-3 Does the manufacturer maintain a web page or other source of information on
software support dates and updates? If yes, provide details or reference in notes.
RDMP-4 Does the manufacturer have a plan for managing third-party component end-of-
life? If yes, provide details or reference in notes.

2.3.18 Software Bill of Materials (SBOM)

A software bill of materials (SBoM) lists all the software components that are incorporated into the
device being described for the purpose of operational security planning by the healthcare delivery
organization. This section supports controls in the RDMP section.

The MDS2 does not specify a Standard or methodology for describing software components. The
MDS2 asks that the device manufacturer describe what method or Standard they use for this
product. There are other Standards that cover describing components. Examples include, but are
not limited to, ISO 19770-2 and NISTIR 8060.

The SBoM may be subject, in full or in part, to non-disclosure agreements if it contains proprietary
information per manufacturer policies and practices.

SBOM-1 Is the SBoM for this product available? If yes, provide details or reference in notes.
Guidance: Indicate in the notes how the SBoM is made available and if there are any
restrictions (e.g., non-disclosure agreements). For example, the SBoM could be
incorporated directly into the MDS2 form as a table. Or, an external hyperlink could
direct the healthcare delivery organization to an online version. These examples
are not comprehensive or all-inclusive.

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page 21

SBOM-2 Does the SBoM follow a Standard or common method in describing software
components? If yes, provide details or reference in notes.

SBOM-2.1 Are the software components identified?

SBOM-2.2 Are the developers/manufacturers of the software components identified?

SBOM-2.3. Are the major version numbers of the software components identified?

SBOM-2.4 Are any additional descriptive elements identified? If yes, provide details or
reference in notes.

Guidance: Additional detail about descriptive elements (e.g., patch tags, software
ID tags) are available in the following Standards and documents: ISO/IEC 19770-
2:2015, Software Package Data Exchange (SPDX) 2.1

SBOM-3 Does the device include a command or process method available to generate a list
of software components installed on the device? If yes, provide details or reference
in notes.

SBOM-4 Is there an update process for the SBoM? If yes, provide details or reference in
notes.

2.3.19 System and Application Hardening (SAHD):

The device's inherent resistance to cyber-attacks and malware.

SAHD-1 Is the device hardened in accordance with any industry Standards? If yes, provide
details or reference in notes.
SAHD-2 Has the device received any cybersecurity certifications? If yes, provide details or
reference in notes.
SAHD-3 Does the device employ any mechanisms for software integrity checking?
Guidance: Indicate in the notes section the mechanism(s) used to protect changes
to the application programs, system configuration, and/or device data.
SAHD-3.1 Does the device employ any mechanism (e.g., release-specific hash key,
checksums, digital signature, etc.) to ensure the installed software is manufacturer-
authorized?
SAHD-3.2 Does the device employ any mechanism (e.g., release-specific hash key,
checksums, digital signature, etc.) to ensure the software updates are the
manufacturer-authorized updates?
SAHD-4 Can the owner/operator perform software integrity checks (i.e., verify that the
system has not been modified or tampered with)? If yes, provide details or
reference in notes.
Guidance: Indicate in the notes the typical output.
SAHD-5 Is the system configurable to allow the implementation of file-level, patient-level, or
other types of access controls? If yes, provide details or reference in notes.
Guidance: Indicate in the notes the file-level access controls (e.g., user access
versus administrator access, remote versus local access, etc.)
SAHD-5.1 Does the device provide role-based access controls?

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page 22

SAHD-6 Are any system or user accounts restricted or disabled by the manufacturer at
system delivery? If yes, provide details or reference in notes.
SAHD-6.1 Are any system or user accounts configurable by the end-user after initial
configuration?
SAHD-6.2 Does this include restricting certain system or user accounts, such as service
technicians, to least privileged access?
SAHD-7 Are all shared resources (e.g., file shares) that are not required for the intended
use of the device disabled? If yes, provide details or reference in notes.
Guidance: Indicate in the notes if any shared resources are disabled by the
manufacturer at system delivery or are configurable by the end-user after initial
configuration.
SAHD-8 Are all communication ports and protocols that are not required for the intended
use of the device disabled? If yes, provide details or reference in notes.
Guidance: Indicate in the notes if any ports or protocols are disabled by the
manufacturer at system delivery or are configurable by the end-user after initial
configuration.
SAHD-9 Are all services (e.g., telnet, file transfer protocol [FTP], internet information server
[IIS], etc.), which are not required for the intended use of the device
deleted/disabled? If yes, provide details or reference in notes.
Guidance: Indicate in the notes if the unneeded services are deleted/disabled by
the manufacturer (at or prior to the installation of the device) or are
expected/allowed to be disabled by the end-user.
SAHD-10 Are all applications (COTS applications as well as OS-included applications, e.g.,
MS Internet Explorer, etc.) that are not required for the intended use of the device
deleted/disabled? If yes, provide details or reference in notes.
Guidance: Indicate in the notes if the unneeded applications are deleted/disabled
by the manufacturer (at or prior to the installation of the device) or are
expected/allowed to be disabled by the end-user.
SAHD-11 Can the device prohibit boot from uncontrolled or removable media (i.e., a source
other than an internal drive or memory component)? If yes, provide details or
reference in notes.
Guidance: Indicate in the notes what external media is accepted by the device.
SAHD-12 Can unauthorized software or hardware be installed on the device without the use
of physical tools? If yes, provide details or reference in notes.
Guidance: Indicate in the notes any restrictions regarding the installation of
hardware or software by the device user/owner.
SAHD-13 Does the product documentation include information on operational network
security scanning by users? If yes, provide details or reference in notes.
SAHD-14 Can the device be hardened beyond the default provided state?
SAHD-14.1 Are instructions available from the vendor for increased hardening? If yes, provide
details or reference in notes.
SAHD-15 Can the system prevent access to BIOS or other bootloaders during boot?
SAHD-16 Have additional hardening methods not included in 2.3.19 been used to harden the
device? If yes, provide details or reference in notes.

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page 23

2.3.20 Security Guides (SGUD):

Availability of security guidance for operator and administrator of the device and manufacturer
sales and service.

SGUD-1 Does the device include security documentation for the owner/operator? If yes,
provide details or reference in notes.
Guidance: Answer “yes” if the manufacturer provides a dedicated security
document or security documentation within the user manual, service manual, or
other documentation available to users. Indicate in the notes reference to this
documentation.
SGUD-2 Does the device have the capability, and provide instructions, for the permanent
deletion of data from the device or media? If yes, provide details or reference in
notes.
Guidance: Answer “yes” if the manufacturer provides such instructions within any
documentation available to users. Describe the specification in notes (e.g., HMG
InfoSec Standard 5, BSI, NIST 800-88).
SGUD-3 Are all access accounts documented?
SGUD-3.1 Can the owner/operator manage password control for all accounts?
Guidance: Is every remote access account or facility identified, and its access
controls documented (e.g., Remote Desktop Protocol (RDP) and remote service
access protocols such as Intelligent Platform Management Interface (IPMI))? Can
the user enable, disable, and control passwords for these access methods?
SGUD-4 Does the product include documentation on recommended compensating controls
for the device?

2.3.21 Data Storage Confidentiality (STCF):

The ability of the device to ensure unauthorized access does not compromise the integrity and
confidentiality of personally identifiable information and other protected personal information (PPI)
stored on device or removable media.

STCF-1 Can the device encrypt data at rest? If yes, provide details or reference in notes.
Guidance: Describe or provide a reference to available encryption algorithms in the
notes. This question refers to local data. See section 2.3.22 question TXCF-2 for
encryption of data prior to network transmission or media export.
STCF-1.1 Is all data encrypted or otherwise protected? If yes, describe or provide a
reference in notes.
Guidance: If encryption is selective, does it cover all operational data (settings,
procedures, configuration, etc.) or only certain types of data (e.g., only patient
records).
STCF-1.2 Is the data encryption capability configured by default?
STCF-1.3 Are instructions available to the customer to configure encryption?
STCF-2 Can the encryption keys be changed or configured? If yes, describe or provide a
reference in notes.

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page 24

STCF-3 Is the data stored in a database located on the device? If yes, describe or provide
a reference in notes.
STCF-4 Is the data stored in a database external to the device? If yes, describe or provide
a reference in notes.

2.3.22 Transmission Confidentiality (TXCF):

The ability of the device to ensure the confidentiality of transmitted personally identifiable
information.

TXCF-1 Can personally identifiable information be transmitted only via a point-to-point

dedicated cable?
Guidance: A point-to-point dedicated cable is a cabling system that is not
accessible to the general public (e.g., it is in physically controlled space such as
examining rooms or communication closets or building plenum).
TXCF-2 Is personally identifiable information encrypted prior to transmission via a network
or removable media? If yes, describe or provide a reference in notes.
Guidance: Indicate any applicable Standards in notes.
TXCF-2.1 If data is not encrypted by default, can the customer configure encryption options?
TXCF-3 Is personally identifiable information transmission restricted to a fixed list of
network destinations?
Guidance: A fixed list is an explicit mechanism that limits the connections and
nature of connections on a per-device basis.
TXCF-4 Are connections limited to authenticated systems? If yes, describe or provide a
reference in notes.
Guidance: Information provided should describe how limitation is accomplished, if
further access control is supported, and what methods are supported.
TXCF-5 Are secure transmission methods supported/implemented (DICOM, HL7, IEEE
11073)? If yes, describe or provide a reference in notes.

2.3.23 Transmission Integrity (TXIG):

The ability of the device to ensure the integrity of transmitted data.

TXIG-1 Does the device support any mechanism (e.g., digital signatures) intended to
ensure data is not modified during transmission? If yes, describe or provide a
reference in notes.
TXIG-2 Does the device include multiple sub-components connected by external cables? If
yes, describe or provide a reference in notes.
Guidance: Provide a reference to a system diagram in notes, if possible. See
DOC-10.
2.3.24 Remote Service (RMOT)
Remote service refers to all types of device maintenance activities performed by a service person
via network or other remote connection.

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page 25

RMOT-1 Does the device permit remote service connections for device analysis or repair? If
yes, describe or provide a reference in notes.
RMOT-1.1 Does the device allow the owner/operator to initiative remote service sessions for
device analysis or repair?
RMOT-1.2 Is there an indicator for an enabled and active remote session?
RMOT-1.3 Can patient data be accessed or viewed from the device during the remote
session?
RMOT-2 Does the device permit or use remote service connections for predictive
maintenance data? If yes, describe or provide a reference in notes.
RMOT-3 Does the device have any other remotely accessible functionality (e.g., software
updates, remote training)? If yes, describe or provide a reference in notes.

2.3.25 Other Security Considerations (OTHR):

This section should be populated by the manufacturer with security risk considerations or controls
(including compensating controls) that have not been categorized elsewhere in this document.

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page 26

Section 3 Comparison with Other Standards

The questions in MDS2 have been mapped with corresponding sections of IEC TR 80001-2-
2:2012, ISO 27000, and NIST 800-53. This mapping is provided for information only and is not
required to be referenced by the manufacturer. A more general but very useful crosswalk can be
found in "HIPAA Security Rule Crosswalk to NIST Cybersecurity Framework," from the DHHS
Office for Civil Rights (https://www.hhs.gov/sites/default/files/nist-csf-to-hipaa-security-rule-
crosswalk-02-22-2016-final.pdf).

3.1 IEC TR 80001-2-2:2012

The IEC TR 80001-2-2:2012 technical report identifies a list of security capabilities that are
important as part of the risk management of a healthcare facility network. This list is in Section 5
Security Capabilities and is closely aligned with the question categories in MDS2MDS2.

IEC TR 80001-2- IEC TR 80001-2- MDS2 Category Comments

2:2012Section 2:2012 Name
5.1 ALOF ALOF
5.2 AUDT AUDT
5.3 AUTH AUTH
5.4 CNFS -- User configuration
questions were
moved to SAHD,
SGUD, CSUP,
PAUT
5.5 CSUP CSUP
5.6 DIDT DIDT
5.7 DTBK DTBK
5.8 EMRG EMRG
5.9 IGAU IGAU
5.10 MLDP MLDP
5.11 NAUT NAUT
5.12 PAUT PAUT
5.13 PLOK PLOK
5.14 SAHD SAHD
5.15 SGUD SGUD
5.17 STCF STCF
5.18 TXCF TXCF
5.19 TXIF TXIG
-- -- RMOT Remote Service
and Administration
questions were
added.
-- -- SBOM Software Bill of
Materials questions
were added.

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page 27

IEC TR 80001-2- IEC TR 80001-2- MDS2 Category Comments

2:2012Section 2:2012 Name
-- -- CONN Connectivity
Capabilities were
added
-- -- RDMP Software Roadmap
questions were
added
-- -- MPII Management of
Personally
Identifiable
Information
questions were
added

3.2 ISO/IEC 27002:2013

A mapping between the MDS2 questions and the ISO/IEC 27002:2013 Standard is provided as an
aid for device manufacturers and device users in their security analysis.

If a device manufacturer has already used ISO/IEC 27002:2013 Standard as a basis for device
design and implementation, the relevant sections of ISO/IEC 27002:2013 Standard are allocated to
MDS2 questions about that subject.

If a device user is using ISO/IEC 27002:2013family of Standards as a basis for managing their
network, the relevant sections of ISO/IEC 27002:2013 Standard are allocated to MDS2 questions
about that subject.

3.3 NIST 800-53 r4

a. A mapping between the MDS2 questions and the NIST 800-53 r4 Standard is provided as
an aid for device manufacturers and device users in their security analysis.

If a device manufacturer has already used NIST 800-53 r4 as a basis for device design and
implementation, the relevant sections of NIST 800-53 r4 are allocated to MDS2 questions about
that subject.

If a device user is using NIST 800-53 r4 as a basis for managing their network, the relevant
sections of NIST 800-53 r4 are allocated to MDS2 questions about that subject.

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page 28

Section 4 Differences Between MDS2 2013 and 2019

The 2019 version of the MDS2 replaces the 2013 version moving forward.

4.1 Changes to Document Organization

The document organization changed slightly.

a. The numbering of the questions has been changed. It now corresponds with the numbering
of the IEC TR 80001-2-2:2012 Standard, with some minor differences.

4.2 Changes to Questions

In addition to clarifications and editorial revisions to questions, the following more substantive
changes were made to question sections:

MPII Terminology examples were updated, and questions were extended to address new types
of devices like wearables.

ALOF New automatic logoff technologies, like proximity devices, were added.

AUDT Questions added to address 1) API access and data access details, 2) time
synchronization, and 3) import/export of audit files. Remote service was moved to RMOT.

CNFS This section was stricken and questions regarding customer configuration controls included
in other categories, including ALOF, AUTH, CVSUP, MLDP, NAUT, PAUT, SAHD, and
SGUD.

AUTH The description of authentication types was updated.

CSUP This section was substantially revised. Details regarding update permissions and
capabilities are included.

DIDT A question about compliance with available de-identification Standard profiles was added.

DTBK More questions were added to address categories of data beyond patient information. For
example, system configuration information backups are included.

EMRG No significant change

IGAU No significant change

MLDP Questions were added for 1) who can perform what functions, 2) how logs and notification
are addressed, 3) how network probes are addressed, and 4) whether whitelisting is
supported.

NAUT A question was added about access control capabilities.

PAUT A question was added regarding multi-factor authentication capabilities.

PLOK Questions were added for more types of locks and physical controls.

© 2019 National Electrical Manufacturers Association

 ANSI/NEMA HN 1-2019
Page 29

RDMP Questions about third party library and component usage.

SAHD Questions were added about system verification, site configurability, and details of the
update process.

SGUD A question was added about access control.

STCF A questions were revised to include more category details.

TXCF A question was added about device authentication.

RMOT A new section was added to ask about remote service and administration capabilities.

SBOM A new section was added to ask about the software bill of materials.

CONN A new section was added to ask about connectivity capabilities.

RDMP A new section was added to ask about the software roadmap.

OTHR Added new section as a placeholder for any additional manufacturer information for the
device.

4.3 Changes to the MDS2 Form

The form is now spreadsheet oriented with no effort to preserve the look of a paper-based form. It
is assumed that both creators and users will have access to and prefer the use of spreadsheet
programs.

The spreadsheet is structured so that a CSV format can be used to create, store, and process the
form. This is to enable the use of databases, statistical analysis tools, business analysis tools, etc.
for generating, evaluating, and storing MDS2 forms. The use of such tools is not necessary. An
MDS2 form can still be created and used with a spreadsheet program. This enables potential
further automation of MDS2 processing.

a. The CSV is structured as follows:

b. All instructions leave column 1 empty.
c. All questions have an identifying tag in column 1.
d. Answers are primarily in columns C and D, although in some cases, columns C through G
are used.
e. A crosswalk is provided for each question to the relevant section in IEC TR 80001-2-
2:2012, NIST 800-53, and ISO 27000 family Standards. These are in columns H, I, and J.

4.4 Example Form

An example form is provided for a plausible, although not fully realistic, medical device. This is to
aid those who find it easier to modify an example.

© 2019 National Electrical Manufacturers Association

ANSI/NEMA HN 1-2019
Page 30

Section 5 MDS2 Form

To access and download the current HN 1 MDS2 Worksheet, open the following in your web
browser:

https://www.nema.org/docs/default-source/standards-document-library/mds2-worksheet-
xlsx.xlsx?sfvrsn=fd59e14a_1

NEMA grants permission to make copies of and use the form in this section. Any translations in
full or in part of the MDS2 document should retain the original section labels.
§

© 2019 National Electrical Manufacturers Association