36C25523Q0187_2.docx

SUBJECT*

Row Coolers | STL(VA-23-00045451) 657-23-2-8543-0038

GENERAL INFORMATION

Network Contracting Office (NCO) 15 3450 S 4th Street Trafficway

Leavenworth KS 66048

POINT OF CONTACT*

Mark Socha mark.socha@va.gov

ADDITIONAL INFORMATION

AGENCY’S URL

URL DESCRIPTION

EMAIL DESCRIPTION

Special Notice Special Notice

DESCRIPTION

Special Notice

Special Notice to update the NAICS on a previous sources sought issued on 2/14/2023. Contract Opportunities Subject: Row Coolers | STL(VA-23-00045451) Documentation of technical expertise must be presented in sufficient detail for the Government to determine that your company possesses the necessary functional area expertise and experience to compete for this acquisition. Responses to this notice shall include the following: (a) company name (b) address (c) point of contact (d) phone, fax, and email (e) DUNS number (f) Cage Code (g) Tax ID Number (h) Type of small business, e.g. Services Disabled Veteran Owned small Business, Veteran-owned small business, 8(a), HUBZone, Women Owned Small Business, Small disadvantaged business, or Small Business HUBZone business and (i) must provide a capability statement that addresses the organizations qualifications and ability to perform as a contractor for the work described below.

The VA Heartland Network 15, Contracting Office located at 3450 South 4th Street, Leavenworth, KS, 66048-5055 is seeking a potential qualified contractor to provide Row Coolers for the St Louis VAMV, John Cochran Division, 915 N. Grand Blvd., St Louis, MO 63106 as found in the statement of work.

NAICS Code: 333415 (Air Conditioning and Warm Air Heating Equipment and Commercial and Industrial Refrigeration Equipment Manufacturing) Important information: The Government is not obligated to nor will it pay for or reimburse any costs associated with responding to this sources sought synopsis request. This notice shall not be construed as a commitment by the Government to issue a solicitation or ultimately award a contract, nor does it restrict the Government to a particular acquisition approach. The Government will in no way be bound to this information if any solicitation is issued. Currently a total set-aside for Service Disabled Veteran Owned Small Business firms is anticipated based on the Veterans Administration requirement with Public Law 109-461, Section 8127 Veterans Benefit Act. However, if response by Service Disabled Veteran Owned Small Business firms proves inadequate, an alternate set-aside or full and open competition may be determined. The North American Classification System (NAICS) code for this acquisition is 333415 (Air Conditioning and Warm Air Heating Equipment and Commercial and Industrial Refrigeration Equipment Manufacturing). The small business size standard is 1250 employees.

Notice to potential offerors: All offerors who provide goods or services to the United States Federal Government must be registered in the System for Award Management (SAM located on the web at www.sam.gov). Additionally, all Service-Disabled Veteran Owned Businesses or Veteran Owned Businesses who respond to a solicitation on this project must be registered with the Department of Veterans Affairs Center for Veterans Enterprise VetBiz Registry located at http://vip.vetbiz.gov. All interested Offerors should submit information by e-mail: to Mark Socha at mark.socha @va.gov. All information submissions should be received no later than 11AM CST on April 15, 2023. After review of the responses to this announcement, the Government intends to proceed with the acquisition and a subsequent solicitation will be published.

Special Notice Sources Sought Notice

Page 1 of

Sources Sought Notice

Page 1 of Scope of Work – VA Saint Louis Health Care System

Objective

The VA Saint Louis Health Care System intends to procure row coolers and needed accessories for the server room used to manage biomedical software systems at the facility. This document highlights the technical specifications and services being requested by the facility for consideration towards purchase of the units. Vendors under this proposal shall provide all equipment, accessories, installation services.

Equipment Specifications Requirements

· 4 in-row cooling air distribution systems

· Fluid-cooled heat rejection

· 208-240 V power

· 1-Phase, 60 Hz power

· 300 mm width maximum

· Range of capacity up to 10 kW

· Washable filter

· 2-way/3-way floating point valve

· Hot gas bypass

· Remote temperature sensors

· Insulated cabinet (density ≥ 80 kg/m3)

· Network Management Card (NMC)

· Replaceable, direct-drive fan modules

· Easy to use and maintain

· 12 airflow management blanking panels (10 each)

· Prevents air recirculation by occupying unused rack space

· Compatible with in-row cooling air distribution systems

· Black

· Rack-mounted

· 20” width x 2” height maximum

· No tools required for installation

· Toxic heavy metal & mercury free

· Take-back program available System functionality

· Row coolers and accessories are needed to regulate temperature in the server room at John Cochran. The coolers are needed to remediate issues found during electrical testing of the facility.

Software

· Vendor shall ensure all software operating on the device provided is supported by the original manufacturer at time of delivery.

· For example, vendor shall not provide VA Saint Louis a device utilizing the Windows XP or Windows 7 operating system as they are no longer Microsoft supported.

· Proprietary software systems are acceptable so long as vendor supports the version provided to VA Saint Louis and it is the newest version at time of delivery.

· Access to all software shall be provided to VA Saint Louis in situations where re-installation is necessary.

· Software shall be provided to VA Saint Louis with unlimited perpetual licensing for the supported life of the device.

· In cases where vendor insists on utilizing a licensing fee model this should be noted in the bid provided for VA Saint Louis consideration.

Network Security The vendor is required to fill out the five attached VA Security Forms if their equipment can be connected to the VA network. If these forms are not completed and submitted with the bid package the vendor can be disqualified from the bidding process.

Cerner Compatibility

· All vendors providing a bid to this requirement shall provide a Cerner compatibility statement from the OEM of the equipment that they are proposing to the VA Saint Louis Health Care System.

· This statement will include an OEM attestation that the product proposed is Cerner verified and provide a list of healthcare organizations that have deployed the project with the Cerner EHR.

· The statement will also include any relevant information as to what data can be transmitted to Cerner.

· This statement will be dated within 60 days of the quote being provided to ensure it is recent and accurate.

· The statement will provide an OEM point of contact who can be reached to further discuss any questions or concerns over Cerner compatibility.

· If the device/system being proposed does not connect to the network or medical record the vendor shall note this in their proposal.

· Vendor bids that do not include a Cerner compatibility statement directly from the OEM will be discarded from consideration.

Training

· Vendor shall provide on-site clinical/applications training for relevant VA Saint Louis staff members.

· Vendor shall provide introductory system/maintenance training to VA Saint Louis Biomedical Engineering staff during installation.

· Vendor shall include all costs for travel to provide this training in their proposal.

· Vendor shall coordinate all installation and training dates with VA Saint Louis specified Biomedical Engineering POC who will communicate internally with clinical staff.

Warranty and Service

· Service and Operator Manuals – The vendor shall provide the following documentation for the proposed system:

· Two (2) copies of operator's instruction manuals per unit purchased

· Two (2) copies of complete technical service manuals including detailed troubleshooting guides, necessary diagnostic software, service keys, schematic diagrams, parts lists, and any other resources available to the manufacturer’s service technicians.

· Two (2) copies of a system manager’s manual outlining back-up procedures, managing privilege group limits, routine tasks, etc.

· Warranty – The system, all accessories, and all software shall be covered under the manufacturer’s warranty and shall include all parts and labor for at least one year following acceptance by the VAMC.

· A manufacturer’s factory-trained Field Service Engineer shall perform installation and maintenance during the warranty period.

· The warranty period shall not begin until after the VA Saint Louis Biomedical Engineering POC has accepted the products delivery, installation, and functionality.

· The warranty shall include all manufacturer recommended Preventive Maintenance procedures for its duration.

· All available software updates and security patches will be made available to the VA Saint Louis during the warranty period.

· Vendor shall provide response to applications and technical calls within 8 hours.

· Vendor shall ship replacement parts within 48 hours of identifying necessity by VA Saint Louis Biomedical Engineering staff.

Other Features Value added features in the vendor’s proposal that will be considered include but are not limited to:

· Options for Trade-in of existing equipment shall be proposed in bid package

· Extended Warranty options shall be outlined in bid package

· Service and Biomedical training options shall be outlined in bid package

· Options for this training should include all registration, travel, and lodging costs when possible

Hours of Operation

· Normal hours of coverage are Monday through Friday, 7:00 AM to 3:30 PM Central Standard Time excluding national holidays.

· Vendor on-site visits will be coordinated with the VA Saint Louis Biomedical Engineering POC before being scheduled or conducted.

· Vendor representatives will check in with the VA Saint Louis Biomedical Engineering POC when they arrive on-site and check out upon completion of work each day.

· All services shall be performed during normal hours unless otherwise scheduled with the VA Saint Louis Biomedical Engineering POC.

· Vendor staff shall always be professional and shall take all necessary precautions to maintain a safe environment for the occupants. This includes, as necessary, coordinating access and closures for sensitive areas of the Medical Center.

· Vendor shall be responsible for cleaning all work areas after completion of tasks. This includes removal of packaging and a clean sweep/mop of the area as required by work type.

· Vendor staff shall minimize noise as much as possible while working in all buildings.

· Vendor is responsible for providing all PPE necessary for their work.

Note: Hardware/software update/upgrade installations, where applicable, may be scheduled and performed outside normal hours of coverage at no additional charge to the Government (unless it would be detrimental to equipment up-time; to be determined by the VA Saint Louis Biomedical Engineering POC).

Federal Holidays observed by VA Saint Louis are:

Independence Day

Delivery

· Vendor shall deliver purchased equipment within 45 business days of receiving completed Contracting package from the VISN 15 Contracting Officer. If delivery delays occur vendor shall notify the Contracting Officer and the VA Saint Louis Biomedical Engineering POC.

· Delivery will be to one of the two VA Saint Louis Health Care System main campuses. Vendor shall coordinate exact delivery location with the Contracting Officer and VA Saint Louis Biomedical Engineering POC at the time of the purchase.

· Vendor will ensure that equipment is sent to the Attention of Biomedical Engineering and will include the VA Saint Louis PO Number on the shipping label.

· Delivery of oversized, palletized orders or orders that contain a large number of components will be coordinated with VA Saint Louis Biomedical Engineering POC who will communicate internally with Warehouse Staff.

VA Saint Louis Health Care System Delivery Locations

John Cochran 915 North Grand Blvd Saint Louis, MO 63106 ATTN: Biomedical Engineering PO Number for Order Jefferson Barracks 1 Jefferson Barracks Drive St. Louis, MO 63125 ATTN: Biomedical Engineering PO Number for Order image1.emf

VA 6550 A

VA DIRECTIVE 6550 Appendix A – To be completed for all procurements of network-connected medical devices and non-network-connected medical devices that store sensitive information. For client/server systems, a separate 6550 Appendix A is required for each the client and the medical server.

1.1 Equipment Category (VA-MDNS)

1.2 Manufacturer

1.3 Model

1.4 Application Name and Software Version #

1.5 Requesting Service

1.6 VISN

1.7 Facility Name

1.8 Facility Number

1.9 Manufacturer Point of Contact

Phone Number E-mail address

1.10 Biomedical Engineering Point of Contact

Phone Number E-mail address

1.11 Responsible Service if Biomedical Engineering is NOT the Primary System Manager for system maintenance, support and lifecycle management

1.12 Medical Device Type ☐ Discrete device ☐ Software

☐ Client ☐ Application server

1.13 Equipment Description (i.e. equipment function and systems it communicates with)

1.14 MDIA VLAN Number for installation (if known)

1.15 Installation Location (Room, Building, Division)

1.16 Is there an existing Enterprise Risk Analysis (ERA) for this device/system? ☐ Yes ☐ No

If yes, what is the ERA number?

**Note that the ERA must be for the same make, model, and application software version to apply to the requested system. A new ERA is required for major software or operating system updates (e.g. version 2.0 to 3.0) but is not required for minor updates (e.g. version 2.0 to version 2.1).

If an ERA exists for the requested system, completion of the 6550 Appendix A is not required beyond this point. Please sign to certify that an existing ERA is available for the requested system and forward the document to either the Area Manager or

ISSO for signature, as appropriate.

2.1 Device Operating System (OS)

Can the OS be automatically patched? ☐ Yes ☐ No **Note that systems that do not support automated patching via the VHA MD Update Server or via vendor channels impose a significantly higher risk to the VA network.

If patching is not automated, what is the patching process and/or limitations?

Procurement of systems with unsupported operating systems is prohibited. Unsupported operating systems are OSs that are not supported by the manufacturer and have reached the end of the OS lifecycle as published by the OS manufacturer (i.e. no further security patches will be released for the OS by the manufacturer after the OS end-of-life nor will be available by other methods such as extended warranty purchases from the OS manufacture).

2.2 Is the network connection wireless? ☐ Yes ☐ No

If yes, what is the FIPS 140-2 certification number?

Procurement of systems using 802.11 wireless networking that are not FIPS 140-2 compliant is prohibited.

2.3 Does the device include a database? ☐ Yes ☐ No

If yes, what is the database version?

2.4 Can the device run McAfee antivirus? ☐ Yes ☐ No

**Note that systems that do not support VA-approved antivirus scanning or an antivirus scanning solution managed by the vendor impose a significantly-higher risk to the VA network.

If antivirus is not supported, what are the AV processes and/or the limitations?

2.5 For Windows-based devices, can the VHA SMAK toolkit be installed? ☐ Yes ☐ No ☐ Non-Windows-based system

If no, has the vendor agreed to provide a complete software and application inventory for all system components as per FISMA requirements?

☐ Yes ☐ No

**Note that systems that do not support SMAK installation or for which the vendor does not agree to provide a complete software inventory impose a significantly higher risk to the VA network.

2.6 Does the system support the use of two-factor authentication (please review the VA’s requirements for two-factor authentication here)? ☐ Yes ☐ No

2.7 Is the device required to be joined to the VA domain? ☐ Yes ☐ No

2.8 Does the device allow for encryption of the data drive or OS drives? ☐ Yes ☐ No

2.9 Is sensitive data stored at rest on the device? ☐ Yes ☐ No

If yes, how many records can be stored on the device? ☐ <500 ☐ >500 If yes, does the device support on demand purging of data from the local hard drive? ☐ Yes ☐ No

2.10 Will sensitive data be stored outside of the VA network (e.g. cloud-based service provider – excludes Electronic Medical Record connection)? ☐ Yes ☐ No

2.11 Is connectivity external to the VA required for system operation? ☐ Yes ☐ No

2.12 Is connectivity external to the VA required for system support? ☐ No ☐ Yes - VA S2S VPN

☐ Yes – Other ☐ Yes - VA Citrix Describe remote access method and ports required if access is not via VA site-to-site VPN or VA Citrix.

2.13 How many IP addresses are required?

2.14 What kind of IPs does the system use? ☐ Static IP ☐ DHCP

**Systems should be deployed with static IPs unless DHCP is required.

2.15 If server-based, select one of the following: ☐ Vendor-provided physical server

☐ Vendor-provided virtual host ☐ Biomedical Engineering-provided physical server ☐ Biomedical Engineering-provided virtual host ☐ OIT-provided virtual host ☐ Other – describe

2.16 If server-based, list server specifications (cores, RAM, power, storage) and rack space.

2.17 Validate Cerner CareAware connection.

Submittal/Approval

Biomedical Engineering Date

Area Manager* Date

*Area manager signature only required for client/server medical systems. Please sign within 10 business days of receipt.

Information Systems Security Officer** Date

** Please sign within 5 business days of receipt and return the document to Biomedical Engineering and the Area Manager. If an ERA is required, please submit this form with the ERA package to the Specialized Device Security Division (SDSD) to initiate the ERA process.

https://vaww.oed.portal.va.gov/sites/vrm/IAM/playbooks/Pages/PIV%20Compliance/PIV%20Compliance.aspx

Manufacturer:

Model:

Application Name and Software Version:

Requesting Service:

VISN:

Facility Name:

Facility Number:

Manufacturer Point of Contact:

Phone Number:

Email address:

Biomedical Engineering Point of Contact:

Phone Number_2:

Email address_2:

Responsible Service if Biomedical Engineering is NOT the Primary System Manager for system maintenance support and lifecycle management:

Discrete device: Off

Client: Off

Software: Off

Application server: Off

Discrete device Software Client Application serverEquipment Description ie equipment function and systems it communicates with:

Discrete device Software Client Application serverMDIA VLAN Number for installation if known:

Discrete device Software Client Application serverInstallation Location Room Building Division:

undefined: Off

Yes NoIf yes what is the ERA number:

undefined_2: Off undefined_3: Off

If patching is not automated what is the patching process andor limitations:

undefined_4: Off

Yes NoIf yes what is the FIPS 1402 certification number:

undefined_5: Off

Yes NoIf yes what is the database version:

undefined_6: Off undefined_7: Off

If antivirus is not supported what are the AV processes andor the limitations:

No_4: Off

Yes_4: Off

NonWindowsbased system: Off undefined_8: Off undefined_9: Off undefined_10: Off undefined_11: Off undefined_12: Off undefined_13: Off undefined_14: Off undefined_15: Off undefined_16: Off undefined_17: Off undefined_18: Off undefined_19: Off undefined_20: Off undefined_21: Off undefined_22: Off undefined_23: Off undefined_24: Off undefined_25: Off

No_5: Off

Yes Other: Off

Yes VA S2S VPN: Off

Yes VA Citrix: Off

No Yes VA S2S VPN Yes Other Yes VA CitrixDescribe remote access method and ports required if access is not via VA sitetosite VPN or VA Citrix:

No Yes VA S2S VPN Yes Other Yes VA CitrixHow many IP addresses are required:

undefined_26: Off undefined_27: Off

Vendorprovided physical server: Off

Vendorprovided virtual host: Off

Biomedical Engineeringprovided: Off

Biomedical Engineeringprovided_2: Off

OITprovided virtual host: Off

Other describe: Off

Vendorprovided physical server Vendorprovided virtual host Biomedical Engineeringprovided physical server Biomedical Engineeringprovided virtual host OITprovided virtual host Other describeIf serverbased list server specifications cores RAM power storage and rack space:

Vendorprovided physical server Vendorprovided virtual host Biomedical Engineeringprovided physical server Biomedical Engineeringprovided virtual host OITprovided virtual host Other describeValidate Cerner CareAware connection:

Date:

Date_2:

Date_3:

Equipment Category (VA-MDNS):

Text6:

image2.emf

MDS2

HIMSS/NEMA Standard HN 1-2013

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

© Copyright 2013 by the National Electrical Manufacturers Association and the Healthcare Information and Management Systems Society. 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.

© Copyright 2013 by the National Electrical Manufacturers Association and the Healthcare Information and Management Systems Society.

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.

NEITHER THE HEALTHCARE INFORMATION AND MANAGEMENT SYSTEMS

SOCIETY (HIMSS) NOR NEMA HAVE POWER, NOR DO THEY UNDERTAKE

TO POLICE OR ENFORCE COMPLIANCE WITH THE CONTENTS OF THIS

DOCUMENT. NEITHER HIMSS NOR NEMA CERTIFY, TEST, OR INSPECT

PRODUCTS, DESIGNS, OR INSTALLATIONS FOR SAFETY OR HEALTH

PURPOSES. ANY CERTIFICATION OR OTHER STATEMENT OF

COMPLIANCE WITH ANY HEALTH OR SAFETY RELATED INFORMATION IN

THIS DOCUMENT SHALL NOT BE ATTRIBUTABLE TO HIMSS OR NEMA AND

IS SOLELY THE RESPONSIBILITY OF THE CERTIFIER OR MAKER OF THE

STATEMENT.

HN 1-2013

Page i

CONTENTS

FOREWORD ........................................................................................................... ii

CHANGES FROM PREVIOUS (2008) MDS2 REVISION ............................................... iv

Section 1 GENERAL

1.1 SCOPE

1.1.1 The Role of Healthcare Providers in the Security Management Process

1.1.2 The Role of Medical Device Manufacturers in the Security Management Process ...1

1.2 REFERENCES

1.3 DEFINITIONS

1.4 ACRONYMS

Section 2 INSTRUCTIONS FOR OBTAINING, USING, AND COMPLETING MDS2 FORM

2.1 OBTAINING THE MDS2 FORM (PROVIDERS)

2.2 USING THE MDS2 FORM (PROVIDERS)

2.2.1 Device Description

2.2.2 Explanatory notes

2.2.3 Security Capabilities

2.3 COMPLETING THE MDS2 FORM (MANUFACTURERS)

2.3.1 General

2.3.2 MDS2 Form Completion Guidance

Section 3 MDS2 FORM

Annex COMPARISON OF PREVIOUS (2008) AND CURRENT (2013) MDS2 (Informative)

Page ii

FOREWORD

This document consists of the Manufacturer Disclosure Statement for Medical Device Security (MDS2) form and related instructions how to complete the form. The intent of the MDS2 form is to supply healthcare providers with important information to assist them in assessing the vulnerability and risks associated with protecting private data transmitted or maintained by medical devices and systems. Because security risk assessment spans an entire organization, this document focuses on only those elements of the security risk assessment process associated with medical devices that maintain or transmit private data. A standardized form 1) allows manufacturers to quickly respond to a potentially large volume of information requests from providers regarding the security- related features of the medical devices they manufacture; and 2) facilitates the providers’ review of the large volume of security -related information supplied by the manufacturers.

The manufacturer-completed MDS2 should:

(1) Be useful to healthcare provider organizations worldwide. The information presented should be useful for any healthcare delivery organization that aspires to have an effective information security risk management program.

(2) Include device-specific information addressing the technical security-related attributes of the individual device model.

(3) Provide a simple, flexible way of collecting the technical, device-specific elements of the common/typical information needed by provider organizations (device users/operators) to begin medical device information security (i.e., confidentiality, integrity, availability) risk assessments.

HIMSS and NEMA grant permission to make copies and use this form.

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 security (including the individual facility’s/provider’s situation) 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 provider’s multidisciplinary risk assessment team can review assembled information and make informed decisions on implementing a local security management plan.

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.

*Health Insurance Portability and Accountability Act.

In 2010, International Electrotechnical Commission standard IEC 80001-1, Application of risk management for IT-networks incorporating medical devices, was published. The 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

Page iii 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, HIMSS and NEMA have 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.

HIMSS and NEMA recommend 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:

Senior Technical Director, Operations National Electrical Manufacturers Association 1300 North 17th Street, Suite 900 Rosslyn, Virginia 22209

Page iv

CHANGES FROM PREVIOUS (2008) MDS2 REVISION

1) Alignment of MDS2 with International Electrotechnical Commission (IEC) standard 80001-1 supplement, IEC/TR 80001-2-2, Guidance for the communication of medical device security needs, risks and controls.

a) The order and numbering of the (2008) MDS2 questions has been changed and questions are now placed in either the MANAGEMENT OF PRIVATE DATA section or under the appropriate heading in one of the 19 categories in the SECURITY CAPABILITIES section of the MDS2 form.

b) The amount of MDS2 data requested of device manufacturers has been increased to more adequately address the 19 security capabilities of IEC/TR 80001-2-2.

c) MDS2 term definitions have been added or updated to be consistent with definitions used in IEC 80001 when applicable.

All of the MDS2 security-related questions of previous MDS2 revisions remain in this latest revision with no (or only minor) changes. A cross reference of the 2008 MDS2 questions vs.

2013 MDS2 questions is provided in the Annex.

2) De-localization

Several region-specific references and standards have been removed or replaced with more generic/less region-specific references. The term “Protected Health Information” (PHI), defined in USA HIPAA legislation has been replaced in this MDS2 revision by the term “private data,” as defined in IEC 80001.

Section 1

GENERAL

1.1 SCOPE

Information provided on the MDS2 form is intended to assist professionals responsible for security risk assessment processes in their management of medical device security issues. The information on the MDS2 form is not intended, and may be inappropriate, for other purposes.

1.1.1 The Role of Healthcare Providers in the Security Management Process

The provider organization has the ultimate responsibility for providing effective security management. Device manufacturers can assist providers in their security management programs by offering information describing:

• the type of data maintained/transmitted by the manufacturer’s device;

• how data is maintained/transmitted by the manufacturer’s device;

• any security-related features incorporated in the manufacturer’s device.

In order to effectively manage medical information security and comply with relevant regulations, healthcare providers must employ administrative, physical, and technical safeguards—most of which are extrinsic to the actual 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 providers’ 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 provider needs and requirements.

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...-- 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...-- Part 2-2: Guidance for the communication of medical device security needs, risks and controls, IEC/TR 80001-2-2:2012

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).

EC Data Protection Directive, 95/46/EC (EU 95/46), 1995.

Act on the Protection of Personal Information (Act No. 57 of 2003, Japan).

Personal Information Protection and Electronic Documents Act (PIPEDA), Statutes of Canada, 2000.

Guide for Information Security for Biomedical Technology: A HIPAA Compliance Guide, May 2004, American College of Clinical Engineering (ACCE)/ECRI.

1.3 DEFINITIONS

administrative safeguards: Administrative actions, policies, and procedures to manage the selection, development, implementation, and maintenance of security measures to protect private data and to manage the conduct of an organization’s workforce in relation to the protection of that information.

anti-malware: See anti-virus software.

anti-virus software: A program that monitors a computer or network to identify all major types of malware and prevent or contain malware incidents. See also virus scanner.

audit trail: Data collected and potentially used to facilitate a security audit.

biometric data: Identifies a human via a 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, voice prints, handwritten signature).

device: A product/system, including hardware, firmware and/or (only) software, etc. Unless otherwise clear from the context, in this MDS2 document, “device” refers to the medical device (the manufacturer’s product) which is being addressed by the manufacturer in the MDS 2 form.

See also medical device.

electronic media: (1) 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. (2) 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.

electronic protected health information (ePHI): (As defined in U.S. HIPAA legislation, 45 CFR 160.103) individually identifiable health information (IIHI) that is (1) transmitted by or (2) maintained in electronic media.

emergency access: The process or mechanism by which a device user can quickly and easily access private data in urgent (emergency) situations, bypassing the device’s established access controls.

individually identifiable health information (IIHI): Information that is a subset of health information, including demographic information collected from an individual, and: (1) Is created or received by a health care provider, health plan, employer, or health care clearinghouse; and (2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual; and (i) That identifies the individual; or (ii) With respect to which there is a reasonable basis to believe the information can be used to identify the individual.

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).

malware: Malicious software. A 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) 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:

– diagnosis, prevention, monitoring, treatment or alleviation of disease,

– diagnosis, monitoring, treatment, alleviation of or compensation for an injury,

– investigation, replacement, modification, or support of the anatomy or of a physiological process,

– supporting or sustaining life,

– control of conception,

– disinfection of medical devices,

– 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.

operator: Person handling equipment. The person(s) using a medical device for its intended purpose.

personal identification number (PIN): A number or code assigned to an individual and used to provide verification of identity.

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.

private data: Any information relating to an identified or identifiable person.

process: A set of inter-related or interacting activities which transforms inputs into outputs.

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).

removable media: Electronic media that can be removed from a system without the use of tools.

risk assessment: Conducting an accurate and thorough analysis of the potential risks and vulnerabilities to the integrity, availability, and confidentiality of private data.

risk management: (1) The ongoing process of assessing risk, taking steps to reduce risk to an acceptable level, and maintaining that level of risk. (2) Security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.

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.

technical safeguards: The technology, policies, and procedures to protect data, including private data and control access to it.

token: A physical authentication device that the user carries (e.g., smartcard, SecureIDtm, etc.).

Often combined with a PIN to provide a two-factor authentication method that is generally thought of as superior to simple password authentication.

user: See operator.

virus: See malware.

virus scanner: A computer program (anti-virus software) that detects a virus computer program, or other kind of malware (e.g., worms and Trojan horses), warns of its presence, and attempts to prevent it from affecting the protected computer. Malware often results in undesired side effects generally unanticipated by the user.

vulnerability: A flaw or weakness in device procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the device’s security policy.

1.4 ACRONYMS

CD Compact Disk

CF Compact Flash

COTS Commercial Off-The-Shelf

DVD Digital Versatile Disk

IP Internet Protocol

LAN Local Area Network

OS Operating System

ROM Read Only Memory

SD Secure Digital

USB Universal Serial Bus

VPN Virtual Private Network

WAN Wide Area Network

WiFi Wireless Fidelity

Section 2

INSTRUCTIONS FOR OBTAINING, USING, AND COMPLETING MDS2 FORM

2.1 OBTAINING THE MDS2 FORM (PROVIDERS)

Completed MDS2 forms for many devices may be available directly from the device manufacturer (e.g., manufacturer website).

NOTE—If a manufacturer does not have a completed MDS form for the appropriate device(s), enter manufacturer and model information in the appropriate boxes on the top of a blank MDS form, and submit the form(s) and these instructions to the manufacturer’s compliance office for completion.

2.2 USING THE MDS2 FORM (PROVIDERS)

2.2.1 Device Description

The first two sections of the MDS2 form are used to identify the device (DEVICE DESCRIPTION) and describe the type of data maintained/transmitted by the device and how the data is maintained/transmitted, etc. (MANAGEMENT OF PRIVATE DATA).

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.2.2 Explanatory Notes

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.2.3 Security Capabilities

The final section of the MDS2 (SECURITY CAPABILITIES) contains information on the specific security-related 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.

2.3 COMPLETING THE MDS2 FORM (MANUFACTURERS)

2.3.1 General

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

2.3.2 MDS2 Form Completion Guidance

DEVICE DESCRIPTION section:

Device Category: This is a free-text field. The manufacturer should use standard terminology that customers would reasonably understand to differentiate key modalities or device functionality.

Device Model: This is a free-text field. The manufacturer should fill in the name of the device under which it is placed on the market.

Document ID: The document ID is the manufacturer’s unique tag used internally to track device documentation.

Manufacturer Contact Information: This information identifies how the person or department accountable for the final version of the form can be contacted.

Intended use of 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.

MANAGEMENT OF PRIVATE DATA section:

The manufacturer shall answer all questions either “Yes,” “No,” “N/A” (not applicable), or “See Note.”

If additional information is needed for proper interpretation of an answer, manufacturers are encouraged to provide information in explanatory notes.

The following clarifications and suggested guidance are provided to assist the manufacturer in answering the questions:

NOTE—the numbers in this subsection, below, correlate to the question numbers in the MDS form.

A Can this device display, transmit or maintain private data (including electronic Protected Health Information [ePHI])?

B Types of private data elements that can be maintained by the device:

B.1 Demographic (e.g., name, address, location, unique identification number)?

B.2 Medical record (e.g., medical record #, account #, test or treatment date, device identification number)?

B.3 Diagnostic/therapeutic (e.g., photo/radiograph, test results, or physiologic data with identifying characteristics)?

B.4 Open, unstructured text entered by device user/operator?

B.5 Biometric data?

B.6 Personal financial information (e.g., credit card numbers, health insurance information, etc.)?

C Maintaining private data - Can the device:

C.1 Maintain private data temporarily in volatile memory (i.e., until cleared by power-off or reset)?

C.2 Store private data persistently on local media?

C.3 Import/export private data with other systems?

C.4 Maintain private data during power service interruptions?

D Mechanisms used for the transmitting, importing/exporting of private data – Can the device:

D.1 Display private data (e.g., video display, etc.)?

D.2 Generate hardcopy reports or images containing private data?

D.3 Retrieve private data from or record private data to removable media (e.g., disk, DVD, CD-ROM, tape, CF/SD card, memory stick, etc.)?

D.4 Transmit/receive or import/export private data via dedicated cable connection (e.g., IEEE 1073, serial port, USB, FireWire, etc.)?

D.5 Transmit/receive private data via a wired network connection (e.g., LAN, WAN, VPN, intranet, Internet, etc.)?

D.6 Transmit/receive private data via an integrated wireless network connection (e.g., WiFi, Bluetooth, infrared, etc.)?

D.7 Import private data via scanning?

D.8 Other?

SECURITY CAPABILITIES Section:

The Security Capabilities section 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.

The manufacturer shall answer all questions either “Yes,” “No,” “N/A” (not applicable), or “See Note” unless the applicable question requires otherwise.

If additional information is needed for proper interpretation of these answers, manufacturers are encouraged to provide information in explanatory notes.

The following clarifications and suggested guidance are provided to assist the manufacturer in answering the questions:

NOTE—the numbers in this subsection, below, correlate to the question numbers in the MDS form.

1 AUTOMATIC LOGOFF (ALOF): The device's ability to prevent access and misuse by unauthorized users if device is left idle for a period of time.

1-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:

• enforce reauthorization after a specified period of inactivity;

• 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?)

1-1.1 Is the length of inactivity time before auto-logoff/screen lock user or administrator configurable? (Indicate time [fixed or configurable range] in notes.)

GUIDANCE: Can the user or administrator configure the amount of time that must lapse 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:

• to a user determined time;

• by specific role (e.g., administrator, user).

1-1.2 Can auto-logoff/screen lock be manually invoked (e.g., via a shortcut key) by the user?

GUIDANCE: Can the user/operator manually invoke the auto-logoff/screen lock via a shortcut key combination (e.g., CTRL-ALT-DELETE)?

2 AUDIT CONTROLS (AUDT): The ability to reliably audit activity on the device.

2-…