The BIN number used for dental, and pharmacy, in Canada are 6 digits, there are no 00103, 0103 or 103 just 000103 so you could shorten the reference by removing leading zeros then advise the market to prepend leading zeros.

Paul

No answer yet. Can you reach out to them?

Hi,
Just checking if we have an answer yet so that we can proceed with the proposed solution...

Hi Everyone,

Thank you for the helpful discussion and clarifications regarding the treatment of leading zeros in ITRANS identifiers and their relationship to OID assignment under the HL7 Canada OID root

To summarize the shared understanding and decision path.
1. The ITRANS identifier (e.g., 000103) and the assigned OID (2.16.840.1.113883.3.19.2.3.103) are separate identifiers with different purposes. They do not need to be parsed together by receiving systems, and no semantic meaning should be inferred from the internal arcs of the OID. As noted, OIDs should always be treated as opaque identifiers.
2. In accordance with ITU-T X.660 canonical form rules, leading zeros in OID arcs are not significant. They may appear in submitted values, but the canonical (registered and published) OID must not include padded arcs. This aligns with HL7 best practices ( HL7 Implementation Guidance for Unique Object Identifiers, Release 1 November, 2011 and current CA-URI governance.
3. Before finalizing the registration pattern, we need confirmation on whether leading zeros in ITRANS identifiers are purely formatting fillers to a six-digit width, or if they carry semantic meaning within their domain. If the zeros are not significant, then the corresponding OID arc should use the non-padded integer form (e.g., 103). If the zeros are significant within ITRANS, then the mapping strategy would need to be revisited
4. Assuming the leading zeros are confirmed as non-significant, HL7 Canada would, Register or edit existing OIDs using the canonical (non-padded) arc. Document this rule in the OID Registry and governance notes to ensure consistent implementation by partners and terminology services.

Next Steps
1. ITRANS to confirm whether leading zeros are purely formatting or meaningful within their internal identifier semantics.
2. HL7 Canada OID Registry SME to proceed with canonical OID (no leading zeros) once confirmation is received.
3. Update OID documentation that OIDs must not be parsed and that mapped identifiers may contain padded formats, but OIDs will always follow canonical ITU-T X.660 representation.
4. Communicate final guidance to implementers and vendors once mapping rules are finalized

Please let me know if there are any other items to conisder with this proposed path
Anil

Hi Elliot,

We had previously had a discussion in that the preference was to use the ITRANS number as the OID under the ITRANS root - thus ITRANS maintains the uniqueness, and not someone else.

There was also a strongly expressed preference that new identifiers not be created as the Itrans ids had been in use for 20+ years.

That the OID and Itrans ID have the same "103" in them is significant as the OID is directly set to match the Itrans ID to guarantee uniqueness.

Based on information Paul provided, it would seem the leading 0s can be trimmed for the OIDs as the ITRANS number is always 6 digits, so there won't be a form that has less than 3 zeroes in front of the "103".

Meaning the solution (once confirmed) is to delete the leading zeroes when registering the ITRANS ids for each insurance vendor, and to keep the numbers matching (as per Paul's suggestion).

Randy Nonay wrote:

Hi all,
We just need to verify that the leading 0s are simply fillers to make 6 digit values, or if they are actually significant. IE are 103, 0103, 00103, and 000103 all equivalent in their domain?

Once we can get an answer to this, we can make the proper correction for ITRANS identifiers/OIDS.

If they aren't significant, we can just remove them for the OID. If they are, then a different solution is needed.

I don't see why leading zeroes for an ITRANS identifier have any bearing on an OID. You have two identifiers for Quickcard, the ITRANS identifier (000103) and an OID (2.16.840.1.113883.3.19.2.3.103). They are different things, they have different values; the fact that both have "103" in them is incidental.

Further, best practice is that OIDs should never be parsed. They may be issued according to some scheme that the issuer uses to make sure they don't create duplicates, but a receiver should only do lookups based on the entire OID. The fact that the issuer put "103" in the OID because happens to be part of another identifier is irrelevant to the receiver of the OID. The receiver should check if the received OID matches 2.16.840.1.113883.3.19.2.3.103) and if so, they know it is Quickcard; they should not parse out the "103" and look that up in some other system.