HL7 for provider identifiers and master data
Provider identifiers appear everywhere in HL7: ordering provider, attending doctor, result interpreter, document author, verifier, transcriptionist, pharmacist, scheduler, and billing provider. They are often carried in the XCN datatype. The trap is treating the display name as the identity.
Provider master data may arrive through PMU_B01 personnel messages, MFN_M02 master-file messages, local extracts, or manual dictionaries. The receiver needs to know which identifiers are authoritative for each downstream system.
This is synthetic sample data for learning and testing. Open it in HL7 Soup Web before mapping it so the segment groups, repeated fields, and coded values are visible.
Identifier Authority Is The Safety Feature
A provider number without assigning authority is just a string. The same number may appear in an internal credentialing system, a national provider registry, a local scheduling system, and an old billing system with different meanings. Keep identifier type and assigning authority with the identifier.
XCN values can contain identifier, family name, given name, assigning authority, identifier type, and more. Do not parse only the name components and call that provider matching.
- Keep national, local, licensing, and application-specific identifiers distinct.
- Store inactive and effective dates when provided.
- Test name changes separately from identifier changes.
Where Provider Data Appears
In ADT, providers appear in PV1. In orders, they appear in ORC and OBR. In documents, they appear in TXA. In billing, they appear in FT1, PR1, and related segments. A provider master interface should make all those feeds easier to match, not create a second unmatched identifier universe.
Store The Role And The Context
A provider row alone is rarely enough. Store the role as well as the identity: attending, ordering, referring, interpreting, copy-to, author, verifier, billing provider, or local variants. Also store the context where that role was found, such as message, visit, order/request group, document, charge, or a specific OBR group.
For databases and JSON outputs, it is often simpler to keep one provider-role shape with a context pointer than to create a separate table for every HL7 location a provider can appear. The important rule is not the table name; it is that role, assigning authority, identifier type, and source context survive the transformation. Use HL7 Soup Web to inspect the XCN components, then make the provider mapping explicit in Integration Soup so support can see which provider role was used.
A Practical Integration Soup Workflow
In Integration Soup, build provider mapping as a visible dictionary or transformation layer. Log the incoming provider ID, assigning authority, outbound provider ID, and destination system. When provider data updates arrive through PMU or MFN, route add/update/deactivate behavior deliberately.
The transformers tutorial is the right starting point for provider identifier mapping. Use HL7 Soup Web to inspect XCN components before assuming which caret holds the value you need.
The Test Pack I Would Ask For
Ask for a new provider, name change, specialty change, inactive provider, multiple identifiers, missing national ID, provider with same name as another provider, and a sample order/result/document that references that provider.