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.

Hi all,

Just a quick clarification - the Issue on the Quikcard oid is not about matching the standard OID format, but the question of the significance of the leading 0s in the ITRANS identifiers.

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.

Hi everyone,

Here are my thoughts for your consideration regarding the OID.


1. Canonical format of the OID

Here we use the 2.16.840.1.113883.3.19.2.3.103 and 2.16.840.1.113883.3.19.2.3.000103 as an example to demonstrate the Canonical format of the OID.

The OID 2.16.840.1.113883.3.19.2.3.103 is in canonical OID format and conforms to the ITU-T X.660 series standards.

The alternative representation 2.16.840.1.113883.3.19.2.3.000103 may work in some systems; however, when transmitted to another module, it is likely to be normalized back to the canonical form(i.e. without the leading zeros).


2. Representation of an OID as the value of system in FHIR.

FHIR requires the system element to be a URI.
When representing an system using an OID, it should always use the urn:oid: scheme.
If an OID such as 2.16.840.1.113883.3.19.2.3.103 is used as the value of the system element, it shall be represented as:
urn:oid:2.16.840.1.113883.3.19.2.3.103

We need to confirm that either leading 0s can be deleted (ITRANS will need to be contacted for this) or start creating URIs that doesn't use the code directly, and can be mapped to the ITRANS value as needed

Anne, I think that is the correct approach, however, I'd wait for Infoway to confirm. (Another approach would be a completely different OID to prevent confusion.)

Implementers can maintain a mapping between ITRANS codes (with leading zeroes) and OIDs, if needed.

Thanks very much for your input. As it will not pass FHIR validation, we cannot use the OID with leading zeroes. We will therefore need a proper OID to be issued for Quikcard and request your assistance on this. Please confirm.

I am not asking iTrans or the existing implementers to change anything, as it has been in production for many years and it has been working but we cannot use it as our transactions will fail.

Thanks very much,
A.