Two Hospitals Reuse a Patient Number: Check the Issuer Before Ultrasound Import

The support ticket: a familiar number on an outside study

Fictional illustration: Hospital A receives an ultrasound study from Clinic B on approved transfer media. Its Patient ID is 940218, a number already used locally. The receiving picture archiving and communication system (PACS) presents a possible patient match. The biomedical team is asked whether the cart is faulty or whether the study can be attached to that chart.

The number alone cannot settle either question. Clinic B may have assigned it to a different person, or the same person may have identifiers in both organizations. A header may also carry an incorrect registration selection. An unresolved match should remain in the facility’s approved exception workflow while the PACS and patient-identity owners verify the source records. Do not assume that every import product displays the same warning or provides an isolation function.

An overlay links records from different people; a fractured record separates records belonging to one person. Dennison’s patient-identity maturity paper discusses both risks in consolidated imaging enterprises. An issuer check addresses identifier scope, but it cannot by itself establish that the original acquisition was assigned to the correct patient. ⁵

What does a DICOM Patient ID prove — and what does the Standard never promise?

The Digital Imaging and Communications in Medicine (DICOM) standard separates patient, order and study identifiers. Study Instance UID (0020,000D) is a unique study identifier; Patient ID (0010,0020) is the patient identifier used by an assigning authority. A correctly formed study identifier does not validate the patient binding. ^{2 3}

In DICOM PS3.3 Section C.7.1.1 (Patient Module, Table C.7-1), attribute Patient ID (0010,0020) is defined simply as: ²

Patient ID (0010,0020): Primary identifier for the Patient.— DICOM PS3.3 Section C.7.1.1 Table C.7-1

Patient ID is Type 2 in the cited Patient Module: the element is required, but an unknown value may be empty. Its definition does not give it universal uniqueness. The practical question is which identification scheme assigned the value, and whether the receiving system has a verified mapping for that scheme. A missing or temporary identifier needs the local reconciliation process, rather than an assumption that the study is invalid. ^{1 2}

For example, fictional Hospital A and Clinic B can each use 100452. A shared string does not show whether their records describe the same person. Do not infer the issuing scheme from number length, punctuation, a familiar prefix or the transport endpoint alone. Keep the authority and its provenance with the number during review.

What the issuer and its qualifiers establish

Issuer of Patient ID identifies the authority that issued the patient number. The identity domain is the issuing scheme; the patient identifier is interpreted within that domain. DICOM PS3.3 Section 10.15 defines the issuer macro and its relationship to the HL7 v2 CX datatype used in PID-3. The cited current and 2019e editions contain this mechanism. ^{1 4}

The authority may be a system, organization, agency or department. The issuer attribute corresponds to the local namespace component of the HL7 assigning authority. A bare value such as RIS is only meaningful within an agreed configuration: unrelated organizations may use the same label. Conversely, historic and current issuer labels may be approved aliases for one domain. Compare configured authority mappings, not just text equality. ^{1 5}

The optional Issuer of Patient ID Qualifiers Sequence (0010,0024) provides further authority or identifier context. Only one item is permitted. Its components include: ¹

• Universal Entity ID (0040,0032): a universal or unique identifier for the assigning authority. If both it and Issuer of Patient ID are present, they must identify the same authority.
• Universal Entity ID Type (0040,0033): required when Universal Entity ID is present; it identifies the format used. Check the standard’s defined terms and the local authority registry.
• Identifier Type Code (0040,0035): describes the identifier type using HL7 Table 0203. This is distinct from Type of Patient ID (0010,0022), whose defined terms include TEXT, RFID and BARCODE.
• Assigning Facility Sequence (0040,0036), Assigning Jurisdiction Code Sequence (0040,0039) and Assigning Agency or Department Code Sequence (0040,003A): provide location, jurisdiction or agency context. These do not authorize the reader to guess an absent authority.

Type 3 describes optional presence; it is not a measurement of how often a field is populated. The PIM3 model describes Level 0 systems as assuming a single identity domain rather than qualifying patient identifiers across domains. Combining domains without suitable controls can create collisions; this is a risk, not an inevitable outcome of every import. ^{1 5}

Why did the Standard retire an attribute for lacking an issuer?

The Patient Module also provides Other Patient IDs Sequence (0010,1002) for alternate identifiers. This is relevant when one person has identifiers at several organizations: a second number is not automatically a second person. ²

The current table explains that this sequence replaced the retired Other Patient IDs (0010,1000), whose individual values lacked an issuer. This supports retaining issuer context for each alternate identifier. It does not document a collision rate or make optional issuer values mandatory. ²

Each alternate-identifier item includes a Patient ID and Type of Patient ID and incorporates the issuer macro. The issuer attributes in that macro remain optional. Check each item’s scope rather than assuming every alternate number inherits the top-level authority. ^{1 2}

For a service team, the useful consequence is an evidence question: does the received record preserve the authority for the identifier being compared? A sequence capable of carrying issuer information is not proof that the sender populated it or that the receiver uses it correctly.

Why is order identity not patient identity? Accession numbers and their own issuer

An accession match can help the authorized team locate an originating order. It cannot override a conflict in the patient evidence. The same accession string can occur in unrelated issuing schemes, just as patient numbers can. Keep the order’s authority separate from the authority that assigned the Patient ID.

DICOM PS3.3 Table C.7-3 defines Accession Number as the departmental information-system identifier for an Imaging Service Request. Its optional Issuer of Accession Number Sequence scopes that request identifier. ³

The distinction is practical: a patient can have several orders, and a receiving institution may create its own order for an external study. Preserve the connection to the external order through the approved import workflow. A single-item accession-issuer sequence does not store two accession numbers. ^{3 12}

Our MPPS worklist state guide covers procedure-step status and its order links. This article stops at patient-identity evidence: neither a completed workflow state nor an apparently unique accession proves that an external study belongs to a local chart.

Import reconciliation can legitimately use local patient and procedure information obtained through worklists or demographic queries. IHE describes this as an integration workflow, with exception management for incorrect selections. Do not confuse an import option that resolves order numbering with a verified patient match. Follow the receiver’s documented workflow rather than a universal rule about what a wizard must do. ¹²

What do real ultrasound chains do with issuers? Conformance-statement evidence

These examples describe different roles in the chain: modalities create instances, a worklist broker supplies information and an archive may supplement attributes. They are not a ranking, a compatibility matrix or evidence that a particular installation behaves as tested. The row limits matter as much as the stated behavior.

• GE Venue 40 v2.xx, DOC0837847 Rev 2, Table 3-3, p.24: Patient ID is sourced from user interface (UI) entry or worklist; Issuer of Patient ID is documented as worklist-sourced. The document does not list a manual issuer source. Inspect a permitted test export before concluding what is absent on a particular installed build. The PDF carries a 2011 copyright; its hosting path contains 2018 dates, which are not a software release date. ⁷
• ExactVu 2.9/3.0, Rev 1.3, Section 4.2.2.3.1.3: the created-instance table marks Patient ID as sourced from the modality worklist (MWL) when available and otherwise generated; the issuer row is marked generated. The document explains that generated values can come from user input, acquisition details or a random string; it does not specify the issuer value or whether devices share a namespace. It is not limited in the table to manual-entry cases. ⁸
• Sectra Connectivity Hub 9.5.0.2442, August 2025, Section 3.2.1, p.14: the worklist table maps Patient ID from HL7 PID-3.1 and its assigning authority from PID-3.4. Verify both the incoming values and the configured broker mapping; the row does not prove what a downstream scanner ultimately stores. ⁹
• Philips Lumify R5.0, HSDP-1299212, Table 40, p.38: the stored Patient Module documents Patient ID from worklist, user input or system generation. It does not list Issuer of Patient ID in that table. This is a documentation limit, not evidence for a remote-AE issuer configuration or for how often handheld studies omit issuers. ¹⁰
• dcm4che Archive 5, documentation version 5.35, Device configuration: the issuer setting provides defaults and can be used by configured archive attribute coercions to supplement missing assigning authority on receipt and other transactions. Supplementation depends on invoking that configuration; it is not an unconditional behavior of all incoming studies. A receiver-supplied value must not be mistaken for an authority verified at the sender. ¹¹

For each transfer, distinguish values present at export from values added later. Ask for the exact modality release, broker and archive versions, and the applicable conformance sections. A generic issuer or a receiver default needs a documented interpretation. A filled field is not necessarily stronger evidence than a missing field if nobody can explain where its value came from.

The pre-import check sequence: read, compare, classify, route

Use this four-stage evidence sequence within the facility’s approved import process. It is an editorial synthesis of the cited standards and informatics principles, not a validated patient-matching algorithm. The operator who authorizes a match and the criteria for doing so are defined by institutional policy. ^{5 6 12}

Stage 1: Read the received identity block without changing it. An authorized team member should use an approved read-only viewer or metadata tool in the facility’s secure environment. Keep the original received files protected. Record whether the export is an original clinical transfer, a de-identified copy or a restored backup; missing identity values have different implications in each case.

• Patient ID (0010,0020)
• Issuer of Patient ID (0010,0021) and Qualifiers Sequence (0010,0024)
• Patient's Name (0010,0010)
• Patient's Birth Date (0010,0030) and Patient's Sex (0010,0040)
• Accession Number (0008,0050) and Issuer of Accession Number (0008,0051)
• Study Instance UID (0020,000D), Series Instance UID (0020,000E) and Service-Object Pair (SOP) Instance UID (0008,0018) to locate the affected objects; SOP Class UID (0008,0016) identifies the object type. ^{3 14 15}
• Manufacturer and Manufacturer’s Model Name (0008,0070 / 0008,1090), plus the installed software release from the equipment record.

Stage 2: Compare identity domains and provenance. Through authorized systems, compare the received values with the proposed local record and the sending organization’s confirmed registration information. Verify the configured authority mapping rather than treating an issuer string as authentication.

• Issuer appears to match: check qualifiers and the authority registry. Two sites may both use a generic label such as RIS. Even a recognized domain and matching demographics do not exclude an original wrong-patient selection.
• Issuer differs: verify whether the values identify different domains or approved aliases for one domain. The records may describe different people or the same person with cross-domain identifiers. Do not force a match; ask the identity team to verify the relationship.
• Issuer is absent or defaulted: establish who supplied the Patient ID and whether a gateway or receiver added an authority. Do not fill the gap with a clinic name guessed from a disk label. A missing optional field is not itself a device fault.

Stage 3: Compare demographics and describe uncertainty. Name, birth date and sex can expose a mismatch, but they are not unique identifiers or error-proof checksums. Our patient-name character-set guide covers representation problems. Birth dates and sex values can also be missing, mistyped or corrected; a disagreement does not prove two different people.

Stage 4: Route and record the decision. The authorized PACS and patient-identity teams decide whether to link, reconcile, create a record or decline the import under local policy. Preserve the original received identity and an audit of approved mappings. If a study may already be on the wrong chart, escalate through the facility’s patient-safety and archive-correction procedure; repeated imports or informal deletion can make the evidence harder to reconstruct.

Five fictional cases and the evidence to escalate

The following five fictional cases illustrate where the evidence sequence changes the handoff. They are not reports of actual patient incidents or product test results, and they do not supply import or database configuration instructions.

Case 1: Two sites both assign 100452. Hospital A acquires Clinic B. Each has a record numbered 100452. The migration team must verify Clinic B’s original authority and the approved local mapping before moving studies. Merely prefixing numbers may separate collisions without linking the same person’s records across domains. Have the enterprise identity owners design and validate the migration, including exception review. ^{5 6}

Case 2: A cart creates a local ID. A worklist-free exam uses fictional identifier GEN-004. That identifier can be legitimate in its local scheme without being an enterprise medical record number (MRN). The Sonosite PX entry guide covers one platform’s generated-ID setting; it does not establish this example’s output format. The receiving identity team must verify the registration relationship before assigning the images to a hospital chart.

Case 3: Studies return after repair. An authorized backup is re-imported after service. Compare the retained study, series and SOP Instance identifiers and the patient evidence with the archive record. A Study UID match alone does not prove identical instances or rule out a patient-binding error. Preserve the backup while the archive owner investigates. The pre-repair data-handling guide owns preservation and sanitization decisions; this case does not authorize deletion or UID changes.

Case 4: The receiving site creates a new order. Hospital B assigns a local accession while the received image carries Hospital A’s accession. Record both in the approved reconciliation system with their correct authorities. Issuer of Accession Number Sequence scopes one accession and permits a single item; adding another issuer there is not a way to preserve two orders. The teams responsible for PACS and the radiology information system (RIS) must use their supported external-to-local mapping. ^{3 12}

Case 5: A familiar number with a different birth date. Outside media carries fictional Patient ID 55412 and no issuer. The candidate local record has the same name but a different birth date. Hold the proposed match and obtain verified source registration information. The discrepancy may be a collision or a registration error. Do not infer a new person, create a guest record or enter an invented issuer based on the media label.

When identity is uncertain: demographics, provenance and the hard stops

The service-side boundary is to preserve evidence and avoid unauthorized clinical-record changes. When clinicians need an uncertain external study urgently, use the facility’s urgent identity-verification and clinical escalation pathway. An article cannot replace that procedure. These three limits apply to the support investigation:

• Do not patch identity tags to make a file fit. Keep the received original and use approved read-only inspection. Uncontrolled changes can obscure provenance and create a false match. Preserve the original received files and the audit of any authorized reconciliation.
• Do not accept a proposed match without the required evidence. Authorized import reconciliation may legitimately map identifiers and demographics. IHE specifies workflows for it; the distinction is a verified, documented mapping versus an improvised overwrite. ¹²
• Do not run patient merges from a service guide. Reconciliation, merge and recovery capabilities depend on the system and institutional policy. Leave them to authorized PACS/RIS and identity-governance personnel; there is no universal claim here that every merge is irreversible.

When values differ between the sending copy and the stored object, identify the first point of change: modality export, transfer gateway, import application or archive. Ask the owners for authorized before-and-after evidence and enabled mapping rules. The DICOM network and I/O guide covers the separate transport investigation. An identity discrepancy alone is not evidence to order a replacement board.

Who owns identity reconciliation and cross-referencing?

The permanent disposition belongs to the facility’s authorized imaging-informatics and patient-identity teams, which may include Health Information Management (HIM) and a Master Patient Index (MPI) or enterprise MPI service. Job titles and permissions vary. Clinical engineers provide equipment and transfer evidence; the identity owners verify the person and the local record relationship.

The IHE Patient Identifier Cross-referencing (PIX) profile supports sharing patient identity information and retrieving cross-referenced identifiers across domains. It defines transactions, not the enterprise’s matching algorithm or policies. It also does not repair poor source demographics automatically. ⁶

For a fictional person with Hospital A identifier 100452 and Clinic B identifier 98765, an approved cross-reference can represent that relationship while keeping the domains distinct. The presence of a PIX service does not prove that this relationship has been verified, that a particular viewer queries it, or that every image header remains unchanged. Those are implementation questions. ⁶

IHE also specifies import reconciliation using local patient and procedure information. Its Radiology Technical Framework Rev 23.0 retains the deprecated original IRWF text and directs new implementations toward IRWF.b, listed separately for Trial Implementation. These are integration references for the responsible teams, not a configuration recipe. Recheck the installed products’ supported workflow before deciding how external identifiers will be represented. ¹²

Compile a focused escalation package. Identifiable headers, logs and screenshots remain inside the facility’s approved secure support channel. Share the minimum necessary information with authorized PACS/RIS and identity staff. External service enquiries should use redacted technical evidence; do not send patient records through a general website contact form.

• Received and candidate-local identity values, including issuer qualifiers and which values are missing, held in the authorized facility record.
• Sending system model and installed software version; export method, worklist/manual-entry state and the applicable conformance section.
• Transfer path and receiving software version, with any known issuer-default or coercion rule and the stage where values changed.
• Affected study, series and SOP Instance identifiers and order references, handled as potentially identifying information.
• The proposed match, the unresolved discrepancy, original-file preservation status and the named team responsible for disposition.

What does the historical LOGIQ e recall establish?

Wrong-patient image linkage is a documented ultrasound hazard. FDA’s record for recall Z-1849-2013 describes the GE LOGIQ e software condition in which images could be linked to another patient’s identifier. The record identifies software design as the cause. ¹³

The FDA entry states that the firm planned a software update for affected systems, with service requests tracked to completion. It records initiation on 9 November 2012 and termination on 15 September 2014. It does not establish that issuer collisions caused the defect, document a resulting injury or prove that this article’s checks would prevent that software fault. ¹³

The lesson is limited but useful: an identifier can look plausible while its image binding is wrong. Preserve evidence and ask the appropriate product and clinical teams to investigate a suspected wrong-patient event. Checking issuer scope is one part of import review, not a substitute for manufacturer correction or facility incident management.

For the separate hardware-versus-software service decision, see the GE LOGIQ e symptom guide. Do not generalize this historical recall to other GE products, every LOGIQ e unit or current patient-identity software.

Where Rongtao fits — and where it does not

Rongtao Medical provides independent multi-brand ultrasound board repair, probe services, tested parts and technical support. Supported equipment names identify service coverage, not OEM authorization. For this decision, the useful service contribution is a technical handoff that helps keep an identity investigation separate from an unproven hardware diagnosis.

• Where Rongtao fits: equipment model, part-label and symptom review for a possible ultrasound hardware service case after the facility has assessed the data-integration issue. Board repair typically takes 5–8 business days and warranty is typically 90 days; applicability and final terms depend on the item and service and must be confirmed.
• Where the facility’s teams lead: deciding patient identity, mapping external identifiers, authorizing imports, correcting archive records and performing merges. Rongtao does not replace the PACS/RIS vendor or the facility’s patient-identity governance.

For a hardware enquiry, contact Rongtao Medical with OEM, exact system model and software release, manufacturer part number if known, clear label photos and both sides of any safely accessible board, symptom/error message, service history, quantity and destination country. Board access belongs to qualified personnel. Redact names, patient IDs, study identifiers and other patient data from external logs and images; keep the identifiable escalation package with the authorized facility teams.

Frequently asked questions

Is a DICOM Patient ID unique across hospitals?
Do not assume so. Its assigning authority provides scope. A familiar number in an external study needs authority and provenance checks before the local patient-matching workflow can approve it. ^{1 2}

What is the Issuer of Patient ID and why might it be empty?
It identifies the assigning authority. It is optional in the cited Patient Module. Product release, acquisition workflow and intermediate configuration determine whether and how it is populated; absence alone does not diagnose a fault. ^{1 7 8 11}

Two studies have the same Patient ID but different names—what should I do?
Hold the proposed match and route the discrepancy to the authorized identity team. Different people, registration corrections and name representation errors are possible. Do not create a new patient record or guess an issuer from this discrepancy alone.

Can the accession number help the identity investigation?
It can help locate verified order provenance, but it identifies an Imaging Service Request. It cannot by itself resolve conflicting patient evidence or authorize an overwrite. ³

Can an approved import workflow change DICOM identifiers?
Yes. Governed reconciliation can use verified local patient and procedure information. The prohibited shortcut here is an unauthorized change made just to force acceptance; preserve the original and the approved mapping audit. ¹²

What should I check before importing an outside ultrasound study?
Read the received patient and issuer attributes, compare demographics and authority mappings, establish sender and intermediary provenance, and retain order/study references. Use the facility’s approved disposition; agreement in these fields is not an independent guarantee of identity.

Who should perform a patient merge?
Only personnel authorized under the institution’s PACS/RIS and patient-identity procedures. Permissions, recovery options and documentation depend on the product and policy; this guide does not prescribe a merge operation.

Are modality-generated patient IDs valid outside the site?
They can be meaningful in their original assigning scheme. The receiver must establish the scope and a verified local relationship; a generated number is neither automatically invalid nor automatically an enterprise identity. ^{5 8}