No MDS2 for the Used Ultrasound? Verify Security Before It Connects

Why does hospital IT ask for an MDS2?

Consider a used scanner that arrives with a service report and a matching serial-number invoice. The buyer can confirm the probes and installed options, but the seller’s security PDF names another software release. The immediate question is whether the receiving hospital has enough reliable information to assess this particular console. This is an illustrative procurement scenario, not a measured pattern of incidents or rejected purchases.

MDS2 means Manufacturer Disclosure Statement for Medical Device Security. The original equipment manufacturer (OEM) supplies structured answers about such matters as updates, access controls, stored patient information and interfaces. Steven Hughes’s professional HTM guidance recommends requesting it during procurement and for existing inventory that lacks one, then reviewing it with IT and risk management. HTM means healthcare technology management. ²

This guide deals with that document decision for one used system. The used ultrasound machine buying guide covers the wider purchase and acceptance process. A passed image-quality or electrical-safety test cannot answer which security disclosure applies, just as a security form cannot establish clinical performance.

What an MDS2 establishes—and what it leaves open

ANSI’s catalog describes HN 1-2019 as the MDS2 form plus completion instructions and identifies HN 1-2013 as its predecessor. FDA lists complete recognition under number 13-123, list 059, with a December 19, 2022 entry date. That date is the recognition entry, not an implementation deadline for hospitals. ^{7 1}

The recognition entry describes the information as an aid to professionals conducting security risk assessments. It also cautions that conformance may not satisfy all cybersecurity requirements under Section 524B or FDA guidance. Recognition therefore cannot be read as a finding that a particular used scanner is secure or as a connection permit. Determine applicable legal, procurement and facility requirements separately; this guide does not establish a universal legal rule. ¹

Hughes reports that the 2019 form has about 240 questions across 23 security capabilities. That is his published summary; the paid standard was not read for this article. More useful than counting “Yes” answers is reading the accompanying notes, identifying unknowns and requesting clarification. A “No” can disclose an architectural limit that local reviewers must assess; a “Yes” can still depend on configuration. ²

A software bill of materials (SBOM) inventories software components; an MDS2 describes security capabilities. The PX form’s SBOM section says a component inventory is available, but the MDS2 does not contain that inventory. Request the underlying document when the risk review needs component-level evidence. Consultancy Blue Goat Cyber also explains this distinction, but its overview does not establish the contents of a particular OEM’s inventory. ^{3 6}

How do you match a used console to the form?

Keep three dates and versions separate: the standard edition, the completed disclosure’s release date, and the system’s installed software state. A newly downloaded PDF may be old, and an older chassis may have received a legitimate software upgrade. Neither manufacturing year nor the newest search result establishes applicability. Hughes recommends matching model, operating system (OS), firmware and software, noting possible SKU and version differences. ²

Ask the seller or responsible engineer for the following through normal documented information screens or service records. Do not enter restricted service mode, obtain privileged credentials or change settings merely to fill an evidence gap. Mark unavailable information as unknown and ask the OEM or qualified service provider to identify the approved way to obtain it.

• OEM, exact model designation, console serial and available hardware revision from the rating plate and asset record.
• Application software release and build; OS and firmware versions where the manufacturer makes them available.
• Installed options and interfaces relevant to the planned workflow, such as wireless connectivity, directory authentication or remote services.
• Recent board, storage or software work, including part numbers, revisions, restore-media provenance and before/after version records.
• The disclosure’s document ID, revision, release date, original manufacturer URL or support response, and stated product/version coverage.

Keep timestamped screenshots and source documents with the asset record. A screen confirms the version displayed at that moment; it does not independently establish software integrity or prove that every setting matches the disclosure. If a document covers a release range, obtain confirmation that the delivered configuration is within that range. Do not reject it solely because it lacks a separate PDF for every minor build.

For example, if a seller supplies a disclosure for release A while the installed system reports release B, record “applicability unresolved.” Ask whether the answers apply unchanged, whether a release-specific form exists, or which rows changed. Do not relabel the PDF yourself. A manufacturer clarification can resolve the scope question, but the facility still decides whether the resulting evidence is adequate.

What does a real ultrasound disclosure reveal?

FUJIFILM Sonosite’s 12-page PX disclosure D24031-18 Rev A is dated October 2025. The download filename identifies PX 4-5; the document header names PX without spelling out a full application-build range. Treat it as one worked example and confirm applicability before using it for a specific console. The observations below describe the form, not a test of a used device or a comparison of OEM security. ³

Two distinctions deserve follow-up. First, a blanket statement that PX cannot use directory authentication would be wrong: PAUT-2 identifies external authentication through MS Active Directory and LDAP, while AUTH-1.2 says customers cannot push group policies. Authentication support and domain-policy administration are separate questions. Second, the CSUP and RMOT answers above cannot justify a blanket “no remote access of any kind” claim. Request an explanation of the applicable update mode and configuration. ³

The form’s encryption and export rows also have a narrower purpose than a handover procedure. Use the separate patient-data sanitization guide for the evidence needed before transfer. The PX USB export guide addresses study state and administrator controls.

Where can buyers obtain the document?

Check the manufacturer’s current support or product-security route first, then ask the seller to help obtain the applicable record. Search-engine copies can help identify a document number, but a mirror does not establish authorship, completeness or currency. Save the official source or written support response along with the file.

Philips’ registration instructions demonstrate a real access step, while the PX file demonstrates one directly accessible document. Neither supports a claim that all forms from one OEM are open or that a competitor with a portal is less transparent. The GE page is useful for advisories, but its presence cannot prove that the buyer’s MDS2 is available. Access routes for other manufacturers were not verified for this guide. ^{3 4 5}

Build document delivery into the purchase discussion before payment. Ask who will contact the OEM, which installed release will be delivered, how unresolved questions will affect acceptance, and who owns follow-up. A seller’s promise to send “an MDS2” is weaker than a commitment to supply an applicable manufacturer disclosure or document the unresolved gap for buyer review.

Four routes when the form is missing or outdated

The following routes are an editorial intake tool. Hughes recommends asking for a current form, sending the manufacturer the NEMA template and instructions when none exists, and considering whether requirements can be met as supplied, with compensating controls, or not at all. The table applies that guidance to a used-console handover; it is not a regulator-approved procedure. ²

Route 4 is an exception review, not a promise that segmentation makes an undocumented scanner acceptable. State exactly what remains unknown, how it could affect the intended workflow, and why proposed restrictions would address it. Reviewers may decide the uncertainty cannot be managed. A missing PDF alone does not prove the asset unsafe; an available PDF alone does not prove it safe.

For broader fleet decisions about support horizons and isolation, see the legacy ultrasound cybersecurity guide. This article stops at the evidence and decision handoff. It does not prescribe a firewall design, patch policy or vulnerability-testing procedure.

What changes after a board repair or software reload?

Start with the actual work performed. “Probe,” “power supply,” “beamformer” and “motherboard” are not sufficient descriptions of whether a service event changes firmware, identifiers, stored information or security settings. Some work may leave the relevant configuration unchanged, but establish that from service evidence. Do not assign a universal zero-impact classification to a component family.

Do not require a user-performed firmware hash check unless the manufacturer actually provides an approved method. The PX example makes that limitation concrete: SAHD-3 describes integrity checks during boot, while SAHD-4 says the owner/operator cannot perform software integrity checks. A procurement worksheet cannot invent a verification capability the device does not expose. ³

An earlier disclosure may remain useful after service if its scope still covers the documented configuration. If work changes a relevant answer, retain the old record as history, identify the delta and request manufacturer clarification or a revised disclosure. A third-party service report documents that provider’s work; it cannot silently become a replacement manufacturer statement.

What alternative evidence can reviewers consider?

For an unobtainable form, assemble a question-by-question evidence gap rather than declaring the device “low risk.” The facility’s security team decides which other records and controls are adequate. Useful inputs include the manufacturer’s security guidance, ports/protocols documentation, applicable advisories, support status and the installed-state record. Attribute each answer to its actual source and date.

• Clinical workflow: which receivers, data flows and functions are necessary, and which would be lost if an interface were restricted?
• Manufacturer boundaries: which updates, agents or configuration changes are supported, and which questions remain unanswered?
• Proposed controls: who owns implementation, how effectiveness will be checked and what operational limitations remain?
• Residual uncertainty: what cannot be verified, who may accept that risk, and when the decision expires or must be reopened?

A VLAN label, static IP or MAC address is not evidence that traffic is appropriately restricted or that an endpoint is secure. Do not copy generic port numbers into a deployment plan. The local network team should derive any allowed flows from the exact system documentation and intended integration. Do not run active scans on a clinical device or change credentials and interfaces under this article’s authority; obtain manufacturer guidance and facility approval for the specific assessment.

The outcome can be refusal to connect or refusal to buy. If a restricted deployment is accepted, record the actual restrictions, the checks showing they work and who will maintain them. Network approval is also distinct from clinical release, infection-control readiness and acceptance of repaired hardware. Each responsible team retains its own release decision.

What should the security intake file record?

Hughes recommends linking disclosures to the device’s asset-management, CMMS or other shared risk record and checking for updates when product changes occur. CMMS means computerized maintenance management system. The following is a suggested record structure for this transaction, not a mandatory accreditation checklist or a guarantee of an audit outcome. ²

Keep technical records in the facility’s approved controlled location. For external requests, provide the minimum asset information needed and remove patient identifiers, credentials and sensitive network details from screenshots. The useful output is a traceable decision with named unresolved items, not a dossier that makes unsupported promises of compliance.

Where Rongtao fits—and where it does not

Rongtao Medical provides multi-brand ultrasound board repair, probe services and replacement parts. Its documented brand scope includes GE, Philips, Siemens, Hitachi, Mindray, Samsung, Toshiba/Canon, Aloka and Biosound Esaote. Ask what part identity, revision, work-scope and real-machine test evidence can be supplied for the particular item. Do not treat a hardware test record as an attestation of software integrity or network security.

The Sonosite PX is a public-document example, not a claim of Rongtao Sonosite repair coverage or OEM authorization. Rongtao does not issue manufacturer MDS2 disclosures or approve a hospital network connection. Refer document applicability to the manufacturer and security acceptance to the receiving organization. OEM names identify equipment; they do not establish affiliation or endorsement.

For service or parts enquiries on supported equipment, use Rongtao’s technical enquiry form. Include OEM, exact model, serial, installed release, manufacturer part number, readable photos of both board sides and labels, symptoms/error code, quantity and destination. State the documentation you need and any known service changes. Do not send patient data or credentials.

Frequently asked questions

Does FDA recognition make an MDS2 a connection permit?

No. The recognition entry concerns a standard intended to assist risk assessment; it does not approve a console or authorize its use on a particular network. It also warns that conformance may not meet every relevant cybersecurity requirement. The facility must determine the requirements and acceptance process that apply to its use. ¹

Does a completed form prove the console is secure?

No. It describes manufacturer-disclosed capabilities and limits. It does not independently verify the installed state, the effectiveness of the facility’s controls, or the absence of vulnerabilities. Ask which answers depend on options or settings and preserve the local assessment.

Can a form cover another software version?

Only if its scope or manufacturer clarification supports applicability. Do not assume that a different release is covered—or automatically unsupported—just from the filename. Record the installed variant and resolve differences with the manufacturer. ²

How is an SBOM different?

An MDS2 describes security capabilities. An SBOM inventories software components. The PX form says an SBOM is available but does not supply its component list. Request the release-matched inventory and its delivery format when needed; do not infer those details from a “Yes” answer. ³

Do we need a new form after a board repair?

Review the service delta first. If the same disclosure still covers the configuration, record the basis for retaining it. If hardware, firmware, software or settings changed a relevant answer—or that effect cannot be established—seek clarification and hold any affected approval. There is no universal exemption by component name.

What if the OEM cannot supply the disclosure?

Keep the request and response, identify unanswered questions and submit alternative evidence to the facility’s designated risk owners. They may accept documented restrictions, request more evidence, keep the system disconnected or decline the acquisition. Absence of a form is not permission to bypass that decision.

Limits and recheck triggers

This is a document review as of October 24, 2026, not a survey of used-system problems, a security test or a vendor ranking. The OEM access observations cover one retrieved PX file and two public policy/portal pages; authenticated libraries and other manufacturers were not assessed. No incidence, failure rate, price, universal compatibility or audit-success claim is made.

Recheck when software, relevant hardware, options, network use, manufacturer guidance, vulnerability advisories or support status changes. Preserve superseded records so reviewers can see what informed the earlier decision. An unresolved manufacturer answer should remain visibly unresolved, even when the rest of the intake file is complete.