Device Exports: Test That Patient Names Survive Unchanged

When a device displays a patient name correctly but the hospital receives question marks, garbled text, or a clipped name, test the complete export path. Write a separate interface requirement for encoding and its declaration, name-part mapping, normalization, field limits, and failure handling. Then send synthetic accented, CJK, and boundary-length fixtures through the actual receiver, retrieve the stored record, and compare the decoded name against the approved expectation. A screenshot alone cannot establish that the stored and returned text survived.

Use two distinct outcomes: a supported name must survive without unapproved changes; an unsupported or over-limit name must produce the specified visible failure or controlled disposition. A warning attached to a shortened name does not make that name unchanged. The matrix below is an editorial proposal for manufacturer verification, not an FDA-prescribed test set. No device or hospital interface was tested for this article.

Why this matters: ASTP/ONC describes patient matching as linking records through several demographic fields, including names and birth dates. That makes exported-name integrity relevant to the matching workflow, while a name alone cannot establish patient identity. ASTP/ONC: patient identity and record matching.

Find the first point where the name changes

Start with one reproducible synthetic record and keep its test identifier separate from the name. Draw the route that the data actually follows: device entry, internal storage, serializer, interface engine, hospital parser, receiving database, and retrieval or return export. Include intermediate conversion services. A direct device-to-test-tool connection can help isolate a defect, but it does not exercise an omitted production interface engine.

At each accessible boundary, capture both the original payload and the decoded field value. Record which decoder and character-set assumption were used. Compare adjacent checkpoints until you find the first divergence. If the outgoing payload is intact and the receiving database is changed, changing the device font will not answer the observed failure. If the stored values agree but one screen looks wrong, investigate presentation separately.

• Declaration mismatch: the sender and receiver may assign different meanings to the same bytes. Check the declared encoding before treating a successful transport acknowledgement as evidence about the name.

• Length-unit mismatch: an interface may count bytes while a requirements document says characters. Record the unit at every limit instead of assuming the input widget and database share one interpretation.

• Normalization mismatch: visually similar strings may contain different sequences. Preserve the original captures so the comparison policy cannot conceal an unexpected transformation.

• Silent clipping: inspect the received value, not just whether the export completed. Include a fixture whose distinguishing final character would be lost if a field were shortened.

• Name-model mismatch: compare mapped parts as well as the display name. A rebuilt display string can look plausible even when a family-name element was populated from the wrong source field.

Apply the rules of the selected interface

HL7 v2: declare the actual message encoding

HL7 table 0211 identifies 7-bit ASCII as the default when the character-set field is omitted. For a UTF-8 message, MSH-18 uses the single value UNICODE UTF-8; it cannot add other character sets, and the message must have no byte order mark. Verify the agreed v2 version and interface profile as well as this terminology table. HL7 character-set rules.

A receiver that happens to accept undeclared UTF-8 has not demonstrated a correct declaration. In the negative test, remove the declaration deliberately and evaluate the documented error policy. Do not use the malformed case as a normal operating configuration merely because one hospital system tolerates it.

DICOM: separate component-group limits from byte capacity

DICOM Specific Character Set (0008,0005) declares the repertoire; ISO_IR 192 selects UTF-8, while absence invokes the ISO-IR 6 default. Person Name (PN) uses carets between components and equals signs between up to three representation groups: alphabetic, ideographic, and phonetic. Each group has a 64-character maximum, including its group delimiter, and combining marks count separately. These are DICOM rules, not a universal export-name limit. DICOM PS3.5, sections 6.1 and 6.2.

Build boundary fixtures using the complete encoded name structure, including applicable delimiters. CJK characters can consume more UTF-8 bytes without consuming more PN characters individually. Decomposed accents can increase the PN character count. Test database byte capacity and PN group conformance as separate conditions.

FHIR R5: compare the display form and structured parts

FHIR R5 defines strings as Unicode sequences, with a general ceiling of 1,048,576 characters. HumanName.text represents the display name and can accompany structured parts. When updating a name with both text and parts present, applications must ensure that the text contains no content absent from the parts. The order within each part type must also be preserved. Strings allow leading and trailing whitespace, with XML-specific removal advice. Check the selected representation and implementation guide before adopting a whitespace policy. FHIR R5 string and HumanName definitions.

The primitive ceiling does not establish a hospital database capacity. Ask the receiving team to identify its practical field limits and profile constraints. For a proprietary CSV, USB, or database export, write that interface’s own specification; neither a DICOM cap nor an HL7 header automatically applies.

Turn the interface agreement into testable requirements

Assign requirement identifiers before execution. The following entries are proposed specification prompts: fill them with the actual supported endpoints and approved behavior. Avoid a blanket statement such as “supports international names,” which gives a tester no objective answer when a receiver accepts one script and corrupts another.

Treat name-part assumptions as requirements too. W3C’s internationalization guidance warns against imposing one cultural name model and against assuming a character occupies one byte. Use the person-provided full name where the workflow permits it; where structured fields are necessary, make their mapping explicit. This is general design guidance, not a medical-device regulation. W3C: personal names around the world.

A useful proposed requirement might say: for the named supported interface, every accepted synthetic fixture must be retrievable with the approved name parts and without lost punctuation or text. Unsupported input must follow the specified blocking path. Separate the text-integrity condition from message syntax, capacity, and notification conditions so one passing check cannot compensate for another failing check.

Define equality before running the comparison

NFC canonical normalization can make a precomposed accent and its decomposed equivalent comparable. UAX #15 describes canonical and compatibility forms and notes W3C’s NFC recommendation. NFKC and NFKD can erase distinctions such as character width; do not treat them as identity-preserving export transformations. Normalization stability applies to characters assigned in the relevant Unicode versions, not an unlimited promise about future input. Unicode UAX #15.

For a requirement permitting canonical equivalence, compare decoded strings after NFC normalization. Keep raw values too. If the requirement instead preserves the exact original sequence, normalized equality is insufficient. Raw byte equality is useful at an unchanged transport boundary; it is not the general comparison for a name moved between different serializations. Decode and extract the relevant fields first.

For example, the synthetic character fixture é can be U+00E9 or e followed by U+0301. The first representation uses two UTF-8 bytes and the second three. That calculated example explains why visual inspection and byte-count limits need separate checks. It does not establish any device’s capacity.

import unicodedata

def nfc_equal(expected: str, observed: str) -> bool:
    # Inputs must already be decoded and extracted from the interface payload.
    return unicodedata.normalize("NFC", expected) == unicodedata.normalize("NFC", observed)

assert nfc_equal("Renée", "Rene\u0301e")
assert not nfc_equal("Zoë", "Zoe")
assert not nfc_equal("Ｒｅｎｅｅ", "Renee")

This helper tests one comparison condition. It does not validate an HL7 message, count a DICOM group, check name-part mapping, or confirm record association. Do not strip accents, fold case, collapse spaces, transliterate, or replace punctuation in the preservation comparator unless that specific transformation is separately specified and evaluated. A search key may serve a different purpose from the name stored for exchange.

Use a synthetic round-trip matrix with explicit outcomes

All strings below are invented test fixtures, not patient records or references to identifiable people. The proposed matrix is unexecuted: it contains expected behavior, not observed results. Expand each family for every supported export route. “Return” means an authorized read-back or return export from the receiving system, decoded with its documented encoding; it does not require the device itself to offer re-import.

The protocol rules behind these fixtures are documented in HL7 table 0211, DICOM PS3.5, FHIR R5 datatypes, and UAX #15. The choice of cases and acceptance workflow here is an editorial proposal.

For the four-character capacity check, use the synthetic Japanese-script placeholder 仮名試験. It has four Unicode code points and twelve UTF-8 bytes, calculated from this exact fixture. A four-byte field cannot store it unchanged. Do not infer a universal minimum name-field size from this example; its purpose is to expose a mistaken byte-versus-character assumption.

For the limit family, attach the generated fixture itself to the protocol rather than a description such as “a very long name.” Add a combining mark near the boundary. Cutting at a code-point boundary can still separate a base letter from its mark, so define treatment of the whole sequence. Prefer blocking or quarantine when the full value cannot be represented. If shortening is supported, require deterministic behavior, retention of the original, and an explicit indicator, and evaluate the resulting identity risk separately.

Make the receiver part of the execution plan

Run the matrix through a local reference parser first to isolate serialization and decoding errors, then through the representative receiving configuration. Keep those results separately identified. A simulator result answers whether the simulator interpreted the message; it does not establish what a hospital’s configured mapper and database will store. If access to the actual endpoint is unavailable, record that limitation and leave its acceptance work open.

1. Create a fresh synthetic record with a distinct test identifier, then record the exact name sequence and expected destination fields before sending.

2. Capture the outgoing message or object and the first receiving representation. Record the sender, middleware, and receiver versions and configuration.

3. Retrieve the stored record through the supported read-back route. Compare content, mapping, declarations, and limit handling independently.

4. Where a return interface exists, import the returned record and repeat the comparison against the original expectation. Do not let an outgoing transformation redefine the baseline.

5. For every failure, retain the first divergent checkpoint and its evidence. Correct the cause, rerun the affected case, and assess adjacent routes for regression coverage.

Keep transport acknowledgement, parsing success, database storage, and correct record association as separate observations. A receiving application may accept a message while a later mapper changes a field. Conversely, a rendering defect may leave stored text intact. The evidence should let another engineer distinguish those possibilities without repeating the investigation from scratch.

Place the evidence in the software verification record

FDA’s final device-software guidance was issued June 14, 2023 and replaced the May 2005 guidance. It gives nonbinding submission recommendations, not a named Unicode dataset. FDA guidance landing page.

The guidance recommends traceable, testable software requirements and architecture documentation covering interfaces and data flow. Basic documentation includes testing summaries at unit, integration, and system levels, identifying the tested software version and overall results, plus system-level protocols and reports with expected and observed results and objective pass/fail decisions. Enhanced adds unit and integration protocols and reports. It allows an IEC 62304 declaration-of-conformity route for specified lifecycle documentation; that is not a blanket replacement for testing evidence. Its QMSR note records the February 2, 2026 effective date, incorporation of ISO 13485:2016, and Clause 7.3 as the home of design-and-development elements. FDA guidance PDF, sections VI.D–H and QMSR note.

For this proposed protocol, give each case an identifier and link it to the relevant interface requirement. Record the exact synthetic input, expected destination fields, comparison method, configuration, and execution steps. After execution, add the observed decoded values, raw-payload evidence locations, individual decisions, and anomaly references. Keep expected and observed results in separate fields; a prefilled expected string is not an execution record.

When an intermediate system changes configuration, use the route map to decide what could be affected. A change to encoding selection may require a different case subset from a change to the name mapper or database column. Explain that choice in the change record. Preserve the earlier failure and the corrective evidence so a later reviewer can see why the final configuration was accepted.

Use the existing software verification and validation guide for the broader lifecycle context, and the verification protocol guide for protocol organization. The specific export evidence here should fit into that controlled record rather than become an unrelated spreadsheet with no requirement links.

Decide what the result actually supports

A passing run supports the stated name-preservation requirements for the tested software, route, receiving configuration, and fixture set. It does not prove that every patient can be uniquely matched, that every language is supported, or that an untested hospital interface will behave the same way. Keep unresolved configurations and unsupported input classes visible in the acceptance record.

Before accepting the interface, ask the team to show one intact accented record, one CJK record, one canonical-equivalence case, and one correctly handled over-limit case at the receiving endpoint. Then inspect the underlying values and mapped fields. If the evidence stops at the device screen or the send acknowledgement, the reader’s original problem remains unanswered.

The practical release decision is whether every supported path preserves the approved name content and every unsupported case follows its explicit disposition. Keep a lossy convenience display, a matching search key, and the exchanged patient name distinct in the requirements. That makes later integration changes reviewable without quietly redefining what “the name survived” means.

Sources

• ASTP/ONC — Patient Identity and Patient Record Matching

• HL7 Terminology — v2 table 0211, alternate character sets

• DICOM PS3.5 — Data Structures and Encoding

• HL7 FHIR R5 — string and HumanName datatypes

• W3C Internationalization — Personal names around the world

• Unicode UAX #15 — Unicode Normalization Forms

• FDA — Content of Premarket Submissions for Device Software Functions

• FDA — Final guidance PDF and QMSR note