B2B ultrasound repair & tested partsGlobal shippingEmail quote intakeNeed help? info@rongtaomedical.com
Rongtao Medical
RONGTAO MEDICAL
ULTRASOUND REPAIR · PROBE SOLUTIONS · TESTED PARTS
Contact Us
Repair GuidesOctober 11, 2026 · 14 min read · Rongtao Medical

Chinese Patient Names Break on Export: Trace Ultrasound DICOM Character Sets

Names arriving as question marks or garbage characters do not prove hardware failure. Trace the Specific Character Set declaration, component groups and receiver support across each hop.

Ultrasound DICOM character sets workflow diagram illustrating patient name encoding across Modality Worklist, scanner instance generation, and PACS archive display.

The Symptom at the Console: Why Do Chinese Names Fail Downstream?

Consider a fictional acceptance test at a bilingual ultrasound facility. The scanner displays the test name 张小东 correctly, and a subsequent send reports success. On the PACS workstation, however, the name appears as question marks or garbled text. That discrepancy is enough to investigate demographic delivery even when the image is visible; it is not a diagnosis of the scanner or archive.

Three superficially similar outcomes need different evidence: a replacement glyph on screen, literal question-mark bytes in an object, and a study rejected by the receiver. Only the first describes presentation; the second identifies a damaged representation at the inspected hop; the third needs a status code and receiver log before its cause is known. Preserve the original artifacts and compare adjacent stages rather than inferring a cause from a screenshot.

For healthcare technology management (HTM) teams, independent service organizations and distributors accepting used or repaired systems, the immediate decision is who should investigate. If association and image delivery work while only name text fails, check application encoding, mapping and rendering first. This does not certify every board as healthy. Separate connectivity symptoms belong in our guide to ultrasound DICOM and PACS output failures; collect hardware evidence before requesting component repair.

DICOM text attributes contain encoded character data, and a console display need not use the same representation as the exported object. The Modality Worklist (MWL) response, scanner-created instance, archive database and viewer can therefore disagree. The useful trace pairs a declaration with the bytes and decoded value at each boundary, keeping authorized demographic updates separate from encoding faults. 1 3

Specific Character Set (0008,0005) controls the extended repertoire for affected text Value Representations (VRs), including SH, LO, ST, LT, PN, UC and UT. It does not redefine every attribute: constrained fields such as unique identifiers (UIDs) and dates retain their own rules. Check Patient’s Name (0010,0010) specifically rather than treating a readable pixel annotation as proof of a correct PN value. 1 2

When the declaration is absent: PS3.5 specifies the default ISO-IR 6 repertoire and prohibits code extension for those text fields. Chinese bytes supplied without a valid declaration do not conform to that encoding. The standard does not prescribe a universal rejection or stripping outcome: a particular receiver may store opaque bytes, substitute characters or reject the instance. Record the observed behavior and the product’s documented policy. 1 11

For the Chinese paths considered here, distinguish ISO 2022 code extension from a single multi-byte encoding. A valid term still needs support at every relevant endpoint:

  1. Code extension: ISO 2022 IR 58 identifies the GB2312 repertoire. In the standard’s Chinese example, \ISO 2022 IR 58 has an empty first value, meaning the default repertoire, followed by the Chinese set. ISO_IR 58 is not a defined term. The supported combination and escape handling must be checked in the implementation. 2 4 5
  2. One multi-byte set: ISO_IR 192 (UTF-8), GB18030 and GBK each require a single value in (0008,0005), without ISO 2022 code extension. An object declaring ISO_IR 192\ISO 2022 IR 58 violates that rule. UTF-8 requires minimal-length encoding; changing the declaration alone does not transcode existing bytes. 1 2
Declaration or termChinese repertoireMechanismValue ruleDecision boundary
\ISO 2022 IR 58GB2312; the DICOM table lists 6,763 characters 2ISO 2022 code extension, G1Chinese set in Value 2 or later; empty Value 1 means the default repertoireVerify escapes and supported combinations. This limited repertoire cannot represent every Chinese name.
ISO_IR 192Unicode encoded as UTF-8Multi-byte without code extensionExactly one valueVerify every receiver, conversion path and viewer; UTF-8 alone is not an interoperability guarantee.
GB18030GB18030 repertoireMulti-byte without code extensionExactly one valueA defined DICOM term does not establish support in a specific product or software release.
GBKRestricted subset of GB18030One- and two-byte encoding without code extensionExactly one valueVerify that every test character is representable and both endpoints support the set.
ISO_IR 58 (not a defined term)No defined DICOM declaration under this spellingInvalid termDo not substitute for ISO 2022 IR 58Inspect the dataset and logs. A charset value in a dataset is not itself a presentation-context negotiation item.
Table 1: DICOM Defined Terms for Chinese Character Repertoires and Implementation Constraints

Source: DICOM PS3.3 C.12.1.1.2 and PS3.5 6.1; implementation support must be checked separately.

Person Name (PN) Component Groups: Why Do Hanzi Belong in the Ideographic Group?

A valid character-set declaration does not by itself establish a correct Person Name (PN) layout. DICOM PS3.5 Section 6.2.1.2 separates the parts of a name, such as family and given names, into components. It separates alphabetic, ideographic and phonetic representations into component groups. Check both the encoding and this structure when comparing the source name with the receiver’s display. 3

Within any single representation, a name may contain up to five components separated by caret (^) characters: FamilyName^GivenName^MiddleName^Prefix^Suffix. To support multilingual healthcare workflows where individuals possess both Romanized transliterations (such as Pinyin) and native ideographic or phonetic scripts, DICOM establishes up to three component groups, separated by equal sign (=) delimiters: Alphabetic Group = Ideographic Group = Phonetic Group.

Placement under UTF-8: PS3.5 6.2.1.2 restricts the alphabetic group to U+0020–U+1FFF plus specified punctuation and kana when UTF-8, GB18030 or GBK is used. Hanzi such as 张 lie outside that range and belong in the ideographic group. An ideographic-only name may therefore start with =, for example =张^小东. Keep group placement and byte decoding as separate checks. 3

The standard’s informative example: Annex K.2 illustrates Zhang^XiaoDong=张^小东= with \ISO 2022 IR 58. It is an encoding example, not evidence that a particular scanner supports this path. 5

  • Alphabetic group: Zhang^XiaoDong uses the default repertoire in this example, with no escape sequence in the first group.
  • Ideographic group: after =, the example designates ISO-IR 58 to G1 with 1B 24 29 41 before 张; its GB2312 bytes are D5 C5.
  • Next name component: after ^, the example repeats 1B 24 29 41 before 小东. ASCII remains in G0, so there is no additional escape back to ASCII before the delimiter in this particular G1 example.
  • Optional trailing group: the final = marks an empty phonetic group; a trailing empty group and delimiter may be omitted. Chinese-language names can have phonetic representations too. 3 5

Layout versus corruption: if a received value contains 张^小东 in the first group, record that layout separately from a decode failure. A viewer may display it, while another may impose the standard’s component-group restriction. Do not label a readable name as irrecoverably corrupt, infer how common this layout is, or rewrite historical clinical records to make a test pass. Resolve the expected representation with the modality and archive owners. 3

Triage: What Evidence Localizes the First Changed Hop?

Table 2 lists hypotheses, not one-to-one diagnoses. Compare unmodified source and receiver artifacts for the same fictional instance. If a display shows question marks but the stored PN still contains valid Hanzi, the characters have not been lost from that object. If a later copy contains 3F bytes while the preceding copy does not, investigate the intervening conversion. A byte inspection must use a tool that exposes the original value, not merely its decoded text output. 11 13 14

Observed symptomPossible causesEvidence to compareOwner and next decision
Question marks or replacement glyphsDisplay/decoder failure, or substitution during a conversionCompare original PN bytes at worklist, scanner output and retrieved archive copy. Literal 3F at one hop does not identify where substitution began.Modality/PACS/IT owners locate the first change. Lost characters cannot be reconstructed from those question-mark bytes alone; preserve earlier authorized sources.
Garbled textDeclaration/byte mismatch, or an intermediary/viewer using a different decoderCompare (0008,0005), raw PN and decoded groups at adjacent hops. E5 BC A0 is the UTF-8 encoding of 张; verify the whole value, not just this prefix.The owner of the first mismatch evaluates a supported configuration or vendor correction in the test environment.
Rejected or missing studyUnsupported charset is one possibility; SOP Class, identity or other constraints may also failRetain the actual response status and receiver log; compare the affected instance with each conformance statement.Archive and modality administrators determine the documented rejection reason before altering a setting.
Pinyin visible; Hanzi absentViewer selects only the alphabetic group, or an earlier hop removed the ideographic groupCheck whether the stored PN contains the second group and whether the required viewer can display it.Viewer owner reviews representation preferences; source owner investigates missing data.
Name already wrong on the consoleWorklist response encoding, scanner decoding or console presentationCompare the test MWL response with console display and scanner-created PN. Verify the exact scanner release’s supported incoming sets.Worklist and modality owners compare capabilities; no assumed universal UTF-8 switch.
Truncated or partly missing nameApplication field cap, rendering issue, conversion loss or PN length violationCount characters using the declared encoding. The 64-character limit includes the component-group delimiter and counts each combining character separately; ISO 2022 escapes are excluded. It is not a byte limit.Software owner checks the first changed hop. Preserve the full source name rather than shortening clinical names. 3
Table 2: Diagnostic Triage Matrix for Ultrasound Chinese Patient Name Corruption

Source: Engineering synthesis from DICOM encoding rules and the dated Conquest, fo-dicom and Slicer cases; possible causes require local verification.

Reading the Conformance Statement: What Do the Scanner and Archive Actually Support?

Use the exact model, software release and application entity’s conformance statement on both sides. PS3.2 provides a standard disclosure template; it is not, by itself, a legal obligation or proof that two products interoperate. Older statements can use different section numbers. Match the content below rather than requiring an old device’s PDF to contain today’s table labels. 6 7

Look for four disclosures, keeping input, output and display support separate:

  • Supported sets: current template Table N.1-15 lists the DICOM terms and IANA names. A product’s actual list, not the template’s example rows, determines its claimed support. 7
  • Attribute presentation and editing: Table N.5-164a asks which fields support extended characters and how fonts or substitutions are handled. Patient’s Name support does not establish equivalent support for every descriptive field. 6
  • Received-to-created-instance mapping: Table N.5-165 describes conversions, including MWL values used in created instances. Its Japanese-to-UTF-8 example demonstrates how to document a mapping; it is not a default rule for Chinese data. 6
  • Unsupported-set behavior: find the product’s documented response and any configuration limitations. Distinguish storing, displaying, querying and exporting; success in one operation does not establish the others. 6

Two product-specific examples: these documents illustrate why appearance and brand are poor substitutes for a release-specific capability check. They do not establish support for the reader’s installed system.

  • TOMTEC-ARENA TTA2: the Philips-hosted statement D.32.0131-16 is dated 17 November 2021. Sections 7/7.1, printed pages 29–30, list ISO_IR 192 and GB18030 for decoding/display support. Section 5.2.2, printed page 27, says its media export encoding is UTF-8. That media-specific statement must not be generalized to every network export path. 8
  • Philips Lumify R5.0: HSDP-1299212, version 01 dated 17 August 2023, Table 37 on page 35 lists ISO_IR 100 as its supported extended set; created-instance tables also declare that term. The statement lists no Chinese-capable set. It does not establish whether the mobile app accepts Chinese entry or how an unsupported name is handled. Confirm those questions with the applicable OEM documentation and a synthetic test. 9

The takeaway for biomedical specialists is clear: never assume DICOM character-set capabilities based on equipment appearance, cart price, or manufacturer reputation. Every system's exact model and software revision must be cross-checked against its conformance statement before designing an integration workflow.

Downstream Reality: PACS Archiving, Coercion, and Viewer Rendering

Once a Service-Object Pair (SOP) instance leaves the ultrasound cart, check archive storage, demographic updates and viewer rendering separately. A stored object and a readable name on one client do not establish correct presentation on every required viewer. The examples below show why each operation needs its own evidence.

Archive versus Health Level Seven (HL7): dcm4che Archive 5 documentation lists ISO 2022 IR 58, ISO_IR 192, GB18030 and GBK for DICOM decoding/display. It separately states that multi-character-set escape sequences in HL7 v2 messages are unsupported. This is one product’s boundary, not a rule that all hospital interfaces require a UTF-8 gateway. Keep any HL7 interface verification with the facility’s integration team. 10

Authorized updates versus decoding faults: the Sectra PACS 28.1 statement, March 2026, section 8.1.4 and Table 8.3, lists Patient’s Name among fields that may be modified during export. It attributes coercion to updated hospital information system/HL7 information, import grouping or configuration. Compare the audit history and source of an update before calling every changed name an encoding error. A supported product capability does not authorize an engineer to edit a clinical record. 16

Toolkit limits: J. Riesmeier’s November 2011 DCMTK description explains that string bytes could be stored without checking the accuracy of the Specific Character Set declaration. This historical example explains why a successful file operation need not validate the text. It does not establish the behavior of every current toolkit or appliance. A decoded dump can conceal substitutions or transcoding; retain the original instance and use an appropriate raw-value inspection method. 11

Dated implementation cases: Conquest thread 50545 (July 2023) records different Traditional Chinese presentation across server/database/viewer paths; the maintainer describes a converter assuming ISO_IR 100. In fo-dicom 4.03 issue 938 (2019), an explicit UTF-8 parameter removed an umlaut’s question-mark substitution, but the query still failed; the reporter later used a different encoding. Slicer issue 4778 (March 2020) records a display regression and discussion of preview builds and Windows code pages, with a remaining discrepancy. These cases support checking each layer; they do not prove a universal fix, irrecoverable source loss or present-day product failure. 12 13 14

Synthetic Round-Trip Verification Protocol

The following is a proposed acceptance workflow for the facility’s modality and PACS/IT owners. Adapt it to the documented capabilities and required name representations of the installed releases. Passing it demonstrates the tested text path; it does not replace electrical safety, image-quality or other return-to-service checks.

Use facility-approved fictional demographics and an isolated test destination with controlled access. Keep test objects clearly identified and out of clinical matching/reporting workflows. Handle any existing clinical discrepancy under the facility’s privacy and record-correction process. For a repair shipment, follow the separate patient-data export and erasure handoff. Preserve originals and audit records; retyping a displayed name is not evidence that the producing fault is fixed.

  1. Define the test contract: record scanner, worklist, archive and viewer releases; expected name groups; the sets each operation supports; and any approved conversion. Create a fictional worklist order. Use Zhang^XiaoDong=张^小东= as one test value, plus a facility-chosen fictional value representing any additional scripts required. Do not assume GB2312 covers every character.
  2. Compare the MWL response and console: the authorized worklist/modality team records (0008,0005), PN bytes and decoded groups in the response. Compare the console with the representations it documents, rather than requiring every device to show three groups simultaneously. Retain any substitution or truncation evidence.
  3. Inspect the scanner-created instance: produce an OEM-supported nonpatient test object and send it to the approved test receiver. Inspect the stored instance with a DICOM-aware tool, retaining the original bytes separately from a decoded dump. Pair (0008,0005) with (0010,0010). For the ISO 2022 IR 58 example check component escapes; for UTF-8 verify its own bytes without ISO 2022 escapes. Document any deliberate conversion from the worklist response.
  4. Compare the retrieved archive object: retrieve the same fictional instance through an approved workflow and compare its declaration, decoded PN groups and raw value with the scanner output. Explain any encoding conversion or authorized demographic update from the archive’s documentation and audit record. If bytes were replaced, locate the earliest artifact still containing the intended characters. Archive responsibility and deletion are a separate decision covered in the storage-commitment guide; commitment does not prove a name is readable.
  5. Verify the required viewers and sign off: check each viewer used in the acceptance scope, its software version and required name representation. Record the first divergence, responsible owner and retest result. A screenshot proves presentation only. Keep unresolved demographic discrepancies out of the accepted workflow pending the facility’s disposition, and coordinate other checks through the maintenance and acceptance checklist.
StageRecordPass evidence or unresolved boundary
Test contractFictional name/groups, required scripts, endpoint/release list and documented supportEvery required character and representation has a supported path; unsupported cases have a named owner.
MWL responseDeclaration, original PN value and decoded groupsSource values match the agreed fictional order.
Scanner-created objectDeclaration, PN bytes/groups, instance reference and mappingExpected name survives; any declared encoding conversion is documented.
Retrieved archive copySame instance reference, declaration, PN groups and update historyDecoded characters are preserved, or a documented authorized change explains the difference. Byte identity is expected only where no conversion occurred.
Viewer presentationViewer/release, selected group and screenshot of fictional demographicsRequired representations display correctly; storage and display results are recorded separately.
DispositionFirst differing hop, owner, approved change, retest and facility sign-offUnresolved issues stay explicit. Do not delete originals or silently alter clinical records.
Table 3: Fictional-name acceptance record to attach to the engineering ticket

Source: Proposed facility worksheet; no real patient data or universal tolerance is specified.

If one hop cannot support the required characters: stop treating UTF-8 as a universal switch. Ask the responsible vendors and facility owner whether a supported update or a validated conversion can preserve all required characters and name groups. ASCII transliteration does not preserve Hanzi, and a narrower repertoire may not represent a rare character. Document any approved reduced workflow as a limitation rather than claiming complete multilingual acceptance; retain clinical corrections under the facility’s governance process.

Recheck triggers: repeat the agreed synthetic test after a worklist/PACS migration, modality software change, viewer update or relevant conformance-statement revision. The standard links are the current online edition reviewed on 11 October 2026; named product documents and issue reports are dated examples, not claims about all current releases.

Where Rongtao Medical Fits — And Where It Does Not

Clarifying operational boundaries between clinical software engineering and medical hardware servicing protects healthcare facilities from costly misdirected repairs and extended equipment downtime.

Rongtao Medical provides component-level ultrasound board repair, probe service and tested parts. Its published service facts specify 48-hour real-machine testing for every repaired board, standard 5–8 business-day board-repair turnaround and a typically 90-day warranty. Confirm item-specific scope, availability, turnaround and warranty in the quotation; the testing claim does not establish full clinical workload or validation of a hospital’s multilingual integration. 15

Escalate to hardware service when qualified investigation identifies a physical fault or separate connectivity/boot symptoms. A corrupted name alone does not identify a failed board, connector or transceiver. Retain symptom logs and model/revision evidence so a service provider can assess the actual hardware question.

PACS and radiology information system (RIS) configuration, interface mapping and clinical-record reconciliation belong with the facility’s IT, archive and OEM teams. Rongtao’s documented board/parts services do not establish a PACS integration or database-consulting offering. If application evidence identifies a charset mismatch, address that supported software path before buying hardware; continue to assess any independent hardware symptoms on their own evidence.

Name readability is one acceptance criterion. Numeric measurement delivery is a different task: the DICOM SR measurement-delivery guide explains that path. Image-based reporting can remain valid where it meets the facility’s requirements; it is not automatically defective because it lacks structured fields.

Quote-ready hardware handoff: if a hardware issue remains, send the evidence below through the approved contact channel. Keep patient demographics and clinical images out of a commercial enquiry; fictional logs or redacted evidence are sufficient for initial scope discussion.

  • Equipment: OEM, exact model, software release and relevant hardware revision.
  • Component: manufacturer part number and revision from the label, plus clear label photos. Only qualified staff should remove a board; request both sides when it is already safely removed.
  • Symptoms: observed fault/error, when it occurs, separate connectivity or boot symptoms, and prior service history. Provide approved redacted or fictional diagnostic evidence.
  • Supply request: quantity, repair or replacement preference and destination country. Confirm compatibility, current availability and terms against the actual item.

For verified hardware diagnostics, circuit board exchanges, or ultrasound transducer repairs, explore our capabilities at Rongtao Medical Repair Services or submit your technical repair inquiry directly through Rongtao Medical Contact.

Sources

  1. DICOM PS3.5, current online edition (2026d), Section 6.1: Support of Character Repertoires. Reviewed 11 October 2026. Default G0 repertoire ISO-IR 6, code extension techniques, single-value restrictions for ISO_IR 192 and GB18030, and escape sequence insertion rules.
  2. DICOM PS3.3, current online edition (2026d), Section C.12.1.1.2: Specific Character Set Defined Terms (Tables C.12-2 through C.12-5). Reviewed 11 October 2026. Definitions for ISO 2022 IR 58 (Simplified Chinese GB2312), ISO_IR 192 (Unicode UTF-8), GB18030, and GBK; prohibition of duplicate values; empty Value 1 semantics.
  3. DICOM PS3.5, current online edition (2026d), 6.2 and 6.2.1.2. Person Name components and groups, repertoire restrictions and 64-character group length (not bytes), excluding escape sequences. Reviewed 11 October 2026.
  4. DICOM PS3.5, current online edition (2026d), Annex K.1: Character Sets for the Chinese Language in DICOM (informative). Reviewed 11 October 2026. GB2312 (ISO-IR 58) encoding, code extension techniques, and designation escape sequences (G0 ASCII: ESC 02/08 04/02; G1: ESC 02/04 02/09 04/01).
  5. DICOM PS3.5, current online edition (2026d), Annex K.2 (informative). Chinese PN example, G1 escape re-invocation and delimiter handling. Reviewed 11 October 2026.
  6. DICOM PS3.2, current online edition (2026d), Section N.5.7: Specific Character Sets (Conformance Statement Template). Reviewed 11 October 2026. Disclosure requirements for attribute-level extended character support (Table N.5-164a), received-to-sent character set mapping (Table N.5-165), and unsupported character set behavior.
  7. DICOM PS3.2, current online edition (2026d), Section N.1.7: Specific Character Sets (Conformance Statement Template). Reviewed 11 October 2026. Conformance disclosure requirements for Table N.1-15 listing supported character sets with IANA names, classified by single/multi-byte and code extension capability.
  8. TOMTEC Imaging Systems GmbH. TOMTEC-ARENA TTA2 DICOM Conformance Statement D.32.0131-16, 17 November 2021 (Philips-hosted UWS TTA v2.50 PDF). Sections 5.2.2 and 7/7.1, printed pages 27 and 29–30: media export UTF-8 and supported sets. Reviewed 11 October 2026.
  9. Philips. DICOM Conformance Statement - Ultrasound Lumify R5.0, Document ID HSDP-1299212, version 01 dated 17 August 2023. Reviewed 11 October 2026. Documents ISO_IR 100 (Latin-1) only, with no Chinese-capable character set supported.
  10. dcm4che. DICOM Archive 5: Support of Character Sets documentation. Reviewed 11 October 2026. Multi-byte decoding and display support across ISO 2022 IR 58, ISO_IR 192, GB18030, and GBK; HL7 MSH-18 character mapping; explicit boundary that multi-character-set escape sequences in HL7 v2 messages are unsupported.
  11. Riesmeier, J. Enhanced character set support in DCMTK. Blog publication, November 2011; reviewed 11 October 2026. Explains transparent storage of string element byte streams without internal charset validation and outlines libiconv-based convertToUTF8() transcoding.
  12. K-PACS & ConQuest forum thread 50545, July 2023. Different Traditional Chinese presentation across database/server/viewer paths; a maintainer describes a converter assuming ISO_IR 100. Dated implementation case, reviewed 11 October 2026.
  13. fo-dicom issue 938, October 2019, fo-dicom 4.03 on Windows 10. Explicit encoding removed question-mark substitution; UTF-8 did not alone resolve the query. Dated implementation case, reviewed 11 October 2026.
  14. 3D Slicer issue 4778, March 2020. Accented-name display regression, preview-build and Windows code-page discussion with a remaining discrepancy. Dated implementation case, reviewed 11 October 2026.
  15. Rongtao Medical. Published repair services: component-level board repair, 48-hour real-machine testing, standard turnaround and typical warranty subject to quotation. Reviewed 11 October 2026.
  16. Sectra Workstation and Sectra Core 28.1 DICOM Conformance Statement, March 2026. Section 8.1.4 and Table 8.3, printed pages 99–100: export coercion of Patient’s Name and other demographics. Reviewed 11 October 2026.

Talk to Rongtao Medical

Rongtao Medical is an ISO 13485:2016 and ISO 9001:2015 independent ultrasound service provider — board-level repair, tested replacement parts, and 48-hour real-machine testing for partners in 140+ countries.