Solicitation Attachment 3 - Cyber_MDERA.pdf

MDERA VER 7.0 PAGE 1 OF 15

Medical Device and Equipment Risk Assessment (MDERA)

Version 7.0

27 May 2026

The MDERA is utilized by the Centrally and Non-Centrally Managed MDE

Cybersecurity RMF Teams

To ascertain security compliance that is in agreement with United States Federal Government (USFG), Department of War (DoW), and Defense Health Agency (DHA) policies and directives, the vendor is required to complete the following Medical Device Equipment Readiness Assessment (MDERA) as part of the Request for Offer (RFO)/Risk Management Framework (RMF) Change Control Board (CCB) review process.

All Medical Systems/Devices are required to meet DoW cybersecurity and National Institute of Standards and Technology (NIST) standards, regardless of network connection type. The information provided below will be used as a pre-procurement selection tool used to support all stakeholders working to achieve a Risk Management Framework (RMF) Authorization. Failure to disclose all required information, or misrepresentation of the proposed system’s capabilities, will result in the system being ineligible for purchase, or result in a breach of contract and cancellation of contract if discovered after award.

The information provided below which includes data processing capabilities, current security posture, and level of compliance with the cybersecurity principles of Confidentiality, Integrity, and Availability will be used to identify the technical characteristics of the Medical System/Device and determine the level of effort and potential actions required prior to and during an RMF Assessment process, from a cybersecurity standpoint.

DEFENSE HEALTH AGENCY (DHA) Medical Devices and Equipment (MDE) PMO Cybersecurity 693 Neiman Street Ft. Detrick, Maryland 21702

MDERA VER 7.0 PAGE 2 OF 15

Revision History Date Section/Item Comments Author 27-May-26 Edited 1.11,2.0,2.7,3.3, added 3.12,3.14,4.0 Org update-to v7.0 MDE PMO Cyber

MDERA VER 7.0 PAGE 3 OF 15

READ BEFORE PROCEEDING:

THIS SECTION OF THE MEDICAL DEVICE AND EQUIPMENT RISK ASSESSMENT (MDERA) QUESTIONNAIRE IS TO BE COMPLETED BY THE COMMERCIAL VENDOR IN ITS ENTIRETY AS PART OF THE MEDICAL DEVICE & EQUIPMENT (MDE) REQUEST FOR INFORMATION (RFI) PROCESS. THEREFORE, ALL INFORMATION FIELDS MUST BE ADDRESSED. REFERENCES TO EXTERNAL

DOCUMENTS OR PRODUCT LITERATURE ARE NOT ACCEPTABLE.

ONCE COMPLETED, SUBMIT THE MDERA TO THE DESIGNATED POINT OF CONTACT (POC). IF THE POC IS UNKNOWN, SUBMIT THE COMPLETED MDERA TO THE CYBERLOG ORG BOX: DHA.DETRICK.MED-LOG.MBX.CYBERLOG@MAIL.MIL or ICS ORG BOX:

DHA.DETRICK.PEO-MED-SYS-J-6.MBX.DHA-ICS-CYBER-RMF@HEALTH.MIL.

COMPLETION OF THIS QUESTIONNAIRE IS APPLICABLE TO REGULATED MEDICAL SYSTEMS/DEVICES AS WELL AS NON-

REGULATED TECHNOLOGIES SUPPORTING THE MEDICAL MISSION.

IN CONJUNCTION WITH THE MDERA, PLEASE PROVIDE A HARDWARE BILL OF MATERIALS (HBOM) AND SOFTWARE BILL OF MATERIALS (SBOM) FOR ALL DEVICES INCLUDED WITHIN THIS MDERA. THIS INFORMATION IS ESSENTIAL FOR

COMPREHENSIVE RISK ASSESSMENT AND SUPPLY CHAIN TRANSPARENCY.

mailto:DHA.DETRICK.MED-LOG.MBX.CYBERLOG@MAIL.MIL mailto:DHA.DETRICK.PEO-MED-SYS-J-6.MBX.DHA-ICS-CYBER-RMF@HEALTH.MIL

MDERA VER 7.0 PAGE 4 OF 15

PRIMARY VENDOR POINT OF CONTACT (POC) INFORMATION ( Vendor Account Manager )

Name:

Job Title:

Company:

Business Address:

E-Mail Address:

Phone Number:

Web page Address:

Account Manager POC Signature and Date:

(Signature indicates acceptance that all provided information is accurate, and that no information has been omitted.)

If Digital Signature is not possible, print and sign this page only. Attach scanned copy to the document.

DATE:

VENDOR TECHNICAL POINT OF CONTACT ( POC) INFORMATION ( Technical POC Responsible for conducting RMF Activities )

Name:

Job Title:

Company:

Business Address:

E-Mail Address:

Phone Number:

Web page Address:

Technical POC Signature and Date:

(Signature indicates acceptance that all provided information is accurate, and that no information has been omitted.)

If Digital Signature is not possible, print and sign this page only. Attach scanned copy to the document.

DATE:

MDERA VER 7.0 PAGE 5 OF 15

Section 1: System Identification

MEDICAL DEVICE AND EQUIPMENT IDENTIFICATION – Technical and Regulatory

1.0 Medical Device/Equipment Title/Version:

Provide the naming convention for the medical device/equipment and primary application version.

1.1 Medical Device Description:

Provide a brief technical description of the medical device’s/equipment intended use/capability. If applicable, the FDA 510K Summary Description should be used for accuracy.

1.2 Medical Device/Equipment Model:

List all devices/equipment and versions covered under this review (eg. family of systems)

1.3 Medical Device/Equipment Alternate Name:

Indicate whether the medical device/equipment is marketed by any other model, brand names, trademark, or product suite/family. (eg. Resellers)

1.4 Medical Device/Equipment Category: Recommend use of

ECRI Institute’s Universal Medical Device Nomenclature System (UMDNS).

1.5 Primary Software Application Release/EOL Date: Provide

the software release and expected End of Life (EOL) dates of the Primary Software Application. Also, indicate whether Extended Support for the Primary Software Application is provided by the manufacturer. See DHA Cybersecurity Acquisition Language

Release Date: EOL Date:

1.6 Food and Drug Administration (FDA 510K)/other

Regulatory Certification, or Premarket Authorization identifier, if applicable: Provide the number associated with the medical device/equipment, if applicable.

1.7 Medical Device/Equipment Contract

Include in submission a copy of any existing purchase orders (PO), or contracts associated with a DoW/DHA purchase.

If not yet sold to the DoW, indicate N/A.

EXISTING CONTRACT/PO ATTACHED IN SEPARATE DOCUMENT:

1.8 Department of Defense (DoW)/Defense Health Agency

(DHA) Authorization: State whether the proposed medical device/equipment has been, or is currently undergoing the DoW/DHA Risk Management Framework (RMF) Authorization process, and the corresponding eMASS record identifier. State the originating office conducting the RMF efforts, as well as the Authorization Termination Date (ATD).

ATD:

1.9 Baseline physical testing location: Is a test lab is available at the manufacturer’s facility for RMF Assessment.

If such a system is available, provide complete street address as well as Test Lab POC.

Yes No

1.10 Intended Mode of Operation:

Select the intended mode of operation of the medical device/equipment.

Standalone MDE operates in complete physical and logical isolation. Data communication interfaces and associated networking protocols, including legacy serial RS-232 are disabled, and not able to be enabled by hospital staff.

Peer to Peer – Operates in logical isolation but requires the use of networking protocols or RS-232 serial data communications for host-to-host connectivity.

MDERA VER 7.0 PAGE 6 OF 15

MEDICAL DEVICE AND EQUIPMENT IDENTIFICATION – Technical and Regulator y

Client/Server – Operates as a distributed application that partitions task or workloads between the service requester (client) and the service provider (server) using networking protocols.

Web-based – Client-side application – Operates as a distributed application that requires the use of a client-side browser and locally installed applets to access the Primary Application. Applets must be digitally signed by the server.

Web-based –Zero Footprint client-side application. Operates as a distributed application that does NOT require the downloading and installation of server-side software to access the Primary Application.

This may also be referred to as Server-side rendered application.

Host-based – Operates as a passive subsystem which requires connection a host computer to produce information. It may require the use of networking protocols.

Cloud-based – Operates within a cloud-service environment

Government Cloud Service Provider (eg. DISA, SPAWAR)

Commercial, or Vendor provided Cloud Service Provider (eg. Amazon Web Service)

1.11 Cloud Offerings

(All cloud communications components MUST be clearly defined in Section 2: Technical Information)

No Cloud Components Not Yet Evaluated

FEDRAMP Approved (APPROVAL #: ##########) DHA J6 ESA-BAD Approved (APPROVAL: # ###########)

Cloud Offerings:

1.12 Intended Method of Implementation:

Select the intended method of implementation of the proposed medical device/equipment.

System comprises Hardware + Software + Firmware (traditional configuration)

System is Software Only in a Physical Environment (requires hardware provided by the GOV)

System is Software Only in a Virtual Environment (requires virtual environment)

Virtual Environment (all required hardware) is provided by the Department of Defense/Defense Health Agency

Department of Defense/Defense Health Agency must provide all Operating System/Database/Application Virtual Servers.

Virtual Environment (all required hardware) is provided by the Vendor

Vendor provides, and is responsible for the configuration all Operating System/Database/Application on Virtual Servers

1.13 Interfaces

Describe how the device connects to the Local Area Network (LAN), or the intended mode for communications.

CONNECTION TYPE:

Serial over RS-232 RJ-45 Networked Serial to RJ-45 Connection 802.11 Wireless USB Other (Specify Connection Type Below)

1.14 Connected Systems

Describe the types of systems this will connect to, or communicate with. (i.e. PACS, Networked patient monitors, Stand Alone, EHR, etc.)

Indicate whether the MDE can support full/partial integration into a Microsoft Active Directory (AD) Domain.

Provide detailed information on all services utilized, including maintenance, device patching and updates, troubleshooting, data storage, servicing, and training. List all data transferred to and from the cloud, as well as data stored within the cloud. Indicate whether any data is downloadable by patients or shared with third parties.

MDERA VER 7.0 PAGE 7 OF 15

Section 2: Technical Information

2.0 SYSTEM HARDWARE/FIRMWARE

List all components required for the operation and clinical functionality of the device, to include all servers, workstations, routers, switches, etc. Any 3rd Party components MUST be indicated, and included in the tables, OR have their own MDERA filled out.

SYSTEM CONFIGURATION MUST BE DESCRIBED IN ITS ENTIRETY. FAILURE TO DISCLOSE ALL INFORMATION MAY CAUSE A

BREACH OF CONTRACT.

Component Purpose Country of Origin Comments

2.1 OPERATING SYSTEMS

For each Component Listed in Section 2.0, List the Operating System (OS): Make sure to identify all instances regardless of platform (i.e. server, client, peer, standalone, and portable peripheral end point device), End of Life (EOL) date and intended operational environment (i.e., physical, virtual)

EACH COMPONENT FROM SECTION 2.0 MUST BE LISTED. FAILURE TO DISCLOSE ALL INFORMATION MAY CAUSE A BREACH OF

CONTRACT.

Component Operating System Country of Origin

Service Pack Level End of Life Date Extended

Support Virtualized

Provided By

Provided By

MDERA VER 7.0 PAGE 8 OF 15

2.1.1 PROPRIETARY OPERATING SYSTEMS

For each Component Listed in Section 2.1 that indicated a Proprietary Operating System, the vendor MUST list the Underlying Technology used to develop the Proprietary OS:

Component Operating System Underlying Technology Underlying Technology Version/SP

Underlying Technology EOL Date

2.2 INSTALLED APPLICATIONS

For each Component Listed in Section 2.0, List the Applications required for the System to operate/meet clinical requirements.

Make sure to identify all instances regardless of platform (i.e. server, client, peer, standalone, and portable peripheral end point device), End of Life (EOL) date and why the software is required.

EACH COMPONENT FROM SECTION 2.0 MUST BE LISTED. FAILURE TO DISCLOSE ALL INFORMATION MAY CAUSE A BREACH OF

CONTRACT.

Component Application Version End of Life Date

Country of Origin APL Required Purpose

2.3: MIGRATION PATH

For any Application, or Operating System (including underlying technology EOL) listed above, with less than 24 months of support/extended support, describe the migration plan, or upgrade path to maintain compliance.

MDERA VER 7.0 PAGE 9 OF 15

2.4 Individually Identifiable User Accounts:

For each Component Listed in Section 2.0, describe the account types that are required for the system to operate. Are individual accounts for clinicians required for the application.

EACH COMPONENT FROM SECTION 2.0 MUST BE LISTED. FAILURE TO DISCLOSE ALL INFORMATION MAY CAUSE A BREACH OF

CONTRACT.

Describe how accounts are created (site setup accounts, vs vendor default) List all account types in the table below:

Component Account Type Admin Account? Application, OS, or DB?

Authentication Method (PKI, UN/PWD, etc.)

Purpose

SYSTEM ARCHITECTURE DRAWING:

2.5 Medical Device Architecture Diagram: Provide a block diagram depicting all subsystems and components of the proposed medical system/device as configured in your proposal. Include connection specifications such as: Ethernet Connection, Wireless Connection or Bluetooth Connection. You may include an embedded Microsoft Visio diagram with your submission. All 3rd party components MUST be clearly identified in the architecture drawing.

MDERA VER 7.0 PAGE 10 OF 15

2.6 END POINT PROTECTION - ANTI-VIRUS / HOST BASED SECURITY SYSTEM (HBSS) / HOST-BASED INTRUSION PREVENTION

SYSTEM (HIPS)

a. Provide a summary describing if 3rd party/Government Furnished applications can be installed on the proposed medical device/equipment. (i.e.

Antivirus, HBSS, monitoring agents (SPLUNK, TANIUM, etc.)

b. If validation is required prior to installation, describe the validation process.

c. If the system does not support these applications, does the system utilize a native White Listing program (or other technology) to effectively mitigate the vulnerabilities associated with not supporting End Point Protection?

a.

b.

c.

Anti-virus/Anti-malware recommended best practices (if available) *List items which must be excluded from scanning below.

YES NO

Antivirus/Antimalware Heuristics scanning supported?

Does the system provide notification of malware detection in the device user interface or through other mechanism (describe below)?

Does the system automatically update malicious code protection mechanisms? (If no, describe below how malicious code protection mechanisms are updated)

2.7 – VULNERABILITY SCANNING POLICY

Indicate limitations for the ability to run vulnerability scans (i.e. Nessus/ACAS/STIG scans) against the device.

Vendor is able to provide scans from the vendor lab?

MDE capable of being scanned using Tenable Nessus (ACAS)?

Can the medical device be scanned while it is actively processing or providing patient care?

Please provide details on the potential impact or consequences if the device were to be scanned during active operations/real time. (i.e. restrictions on running scans to scanning, etc.).

If the MDE cannot be scanned in active operations real time, provide detailed information on risk involved. (i.e. Risk to patient, test results etc.)

Are admin account passwords made available to the local IT departments to facilitate Fully Credentialed Scans?

YES NO

UNCLASSIFIED//FOR OFFICIAL USE ONLY WHEN COMPLETED

2.8 - VULNERABILITY MANAGEMENT/PATCHING POLICY

Provide a summary describing the plan for providing validated software updates and patches throughout the life cycle of the medical device/equipment. Include timeframes to approve patches, if critical OS patches can be installed without vendor permission. The summary should describe how the security patch is validated and then installed (e.g. remote installation by the vendor or distribution by the vendor for biomedical personnel at the healthcare organization to install.) The vendor should also specify the frequency of product updates.

2.9 REMOTE ACCESS

The software that provides the remote access capability must be included in the Application Inventory. Examples of remote desktop software applications are Microsoft Remote Desktop (MSRDP) and Secure Shell (SSH) Yes No

Can the medical device be serviced remotely (i.e., through the use of a secure point to point encrypted network connection)

Can the device be configured to require the local use to accept or initiate remote access?

Does the device provide an explicit indication of use to users physically present at collaborative computing devices?

Does the device require unrestricted access to the Internet in order to provide remote access?

2. 10 WIRELESS CAPABILITIES

( IEEE 802.11)

State whether the medical system/device employs any form of wireless communication, either standards-based and/or proprietary to facilitate the transmission/reception of data between system components and/or other systems? Yes No

Does the system employ wireless communication?

Wireless Mode of Operation ad hoc? (eg. Device connects internally to another wireless system component)

Wireless Mode of Operation infrastructure? (eg. Device connects to a LAN Environment)

Wireless Mode of Operation inherently disabled? (eg. Network adapter disabled in BIOS)

Wireless Authentication Method (eg. PKI, User-name/Password, Token)

Wireless Encryption Method (eg. AES-256

CCMP)

IEEE 802.15 BLUETOOTH

( Wireless Personal Area Network – WPAN )

Use FIPS 140-2 validated cryptographic modules for data in transit, including digital voice communications.

Bluetooth Discovery Mode Turned Off by default.

MDERA VER 7.0 PAGE 11 OF 15

MDERA VER 7.0 PAGE 12 OF 15

WIRELESS – Other (Describe any other wireless capabilities, i.e. Ultrawide band, Zigbee, etc.)

Wireless Technology Range (ft.)

(indoor/outdoor) Throughput (Mbps) Purpose

2.11 MASS STORAGE

Provide a summary describing if the use of USB Flash Drives/External Hard Drives is required for the operation of the system. Are drives required for use by the operator, or administrative in nature? Please detail what information is stored on the drives, how information on the drives is protected, and alternatives to using the drives. Indicate whether this information can be protected from unauthorized disclosure using Data at Rest (DAR) Full disk encryption.

2.11.1 USB Flash Drive

Upgrades/patches perform by? Vendor Customer N/A Yes No

Upgrades /patches provided via USB by Vendor.

If the USB is provided by the Vendor, the USB flash drive is scanned and is free of malware prior to delivery.

If the USB is provided by Vendor, the USBs only contains the specific patch/upgrade data required for the device.

2.12 Other Components

This section requires information on the accessibility and provision of firewalls, converters, switches, and routers, as these critical devices must be assessed to ensure proper security controls and risk mitigation. If a firewall is involved, please indicate if the government will be granted access to the data behind it.

Should access not be provided, please use the comment section below to explain the reasoning.

Component Purpose Country of Origin Comments Provided By

MDERA VER 7.0 PAGE 13 OF 15

Section 3: Data Processing Capabilities SYSTEM IDENTIFICATION – Data Processing, Electronic Protected Health Information / RMF Authorization

3.0 Data Processing Capabilities:

Does the proposed medical device/equipment perform any of the following data processing functions? (check all that apply)

Receive Process Store Transmit Display

3.1 Electronic Protected Health Information/Personally

Identifiable Information (ePHI/PII):

(as defined by HIPAA Security Rule, 45 CFR Part 164) Indicate whether the proposed medical device acquires, processes, stores, displays/routes ePHI.

Yes No

3.2 Non ePHI/PII information

Define any data processed that is not ePHI/PII information.

3.3 Electronic Protected Health Information/Personally

Identifiable Information (ePHI/PII) Elements: (as defined by HIPAA Security Rule, 45 CFR Part 164) Identify each and all applicable ePHI elements.

Address

Dates of Birth, Admission, Discharge, Death, and all ages over 89 [and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older]

DoW ID / Social Security Number

Telephone numbers

Fax number

E-Mail address

Medical Record Number

Health Plan beneficiary number

Account number

Certificate/License number

Any vehicle or other device serial number

Device identifier or serial numbers

Web Uniform Resource Locator (URL)

IP address

Finger or voice prints

Photographic/Radiographic images

Test Results

Physiologic data with identifying characteristics

Biometric data

Personal Financial Data

Any other unique identifying number, characteristic, or code.

3.4 DoW Information Persistence/Electronic Protected Health

Information/Personally Identifiable Information (ePHI/PII) storage method:

Describe the persistence of the DoW Information processed/stored/transmitted on or by the system.

Permanently Temporarily

3.4.1 Specify how long/much data is stored, and what the method is used to remove data from the device. i.e. FIFO, Upon Reboot, etc..

3.5 Data Input Method

Describe the data input method. Distinguish between manual versus "prescribed" (automated/programmed) data input methods.

3.6 Data Workflow

Indicate what data elements enter the MDE, and what data elements leave the MDE. Indicate how data is processed and, or changed by the MDE.

SYSTEM IDENTIFICATION – Data Processing, Electronic Protected Health Information / RMF Authorization

3.7 Data At Rest Encryption Capabilities

Describe any capability to encrypt data at rest. Include Encryption method and key strength (i.e. Bitlocker, AES-256)

3.8 Data in Transit Encryption Capabilities

Describe any capability to encrypt DoW Information/ePHI/PII while in transit. Include Encryption method and key strength (i.e. AES-256)

3.9 USB Flash Drive Mass Storage (if available)

USB flash drives for mass storage is provided by Vendor Customer N/A

3.10 USB Flash Drive Exporting (if available)

USB flash drives for data export is provided by Vendor Customer N/A

3.11 System Recommended Controls

SYSTEM IDENTIFICATION – Artificial Intelligence (AI) and Machine Learning (ML)

3.12 Does the device incorporate any artificial intelligence (AI) or machine learning (ML) components? If so, what is the intended function of the AI/ML components?

3.13 How was the AI/ML model trained and validated?

3.14 Artificial Intelligence (AI) and Machine Learning (ML)

MDERA VER 7.0

MDERA VER 7.0 PAGE 15 OF 15

DoW mandates for Comply to Connect and Zero Trust Framework, Medical devices and equipment that employ switching, routing, or security appliances (firewalls, ADC, etc.) will need to be managed and/or monitored* by the DHA in their deployed configuration. Networking equipment/solution that is used to segment, or protect data is also subject to this requirement. Those devices that cannot meet the above intent, vendors will need to provide documentation outlining the inability to comply.

4.0 Is the system FIPS compliant or uses FIPS approved

algorithms in employing encryption or other security protocols.

4.2 Could the network traffic and components

located behind network security components be available for monitoring, and event log aggregation.

4.3 * Could DHA manage vendor provided firewalls/ switches/routers/ etc., DHA would need WRITE access to configuration of the appliance/ solution.

4.1 Was the system banned under FAR or DFAR Clauses of

certain telecommunications equipment and technologies, including embedded components in such appliances or devices.

Restrictions concerning banned manufactures or products from certain countries would also apply to proprietary devices or their components.

4.4 * Could DHA actively monitor vendor provided equipment; DHA must have READ access to configurations. Additionally, all network traffic, both internal to the authorization boundary, and external to the device would need to be available for monitoring. (ex. SysLogs aggregated and provided to DHA Splunk servers, SPAN ports to capture all network traffic, etc.)