Implementer FYI - Resource ID Data Type Constraints

Additional implication:

- All FHIR R4 profiles will show MyMedication.id, MyImmunization.id, MyPatient.id, etc as "String" type in the snapshot view, in both Simplifier and HL7 Publisher formats. They all inherit the base FHIR R4 definitions, which says all logical ids are strings, and is not a display error.

To put this in a more concrete example:

For all resources except for the base "Resource", FHIR R4 (4.0.1) incorrectly defined their logical id defined as "string" type , - Medication.id, Immunization.id, Patient.id, Organization.id, etc are defined as "string" type instead of "id" type. This is a defect, and is fixed from FHIR R4B (4.3.0) onwards.

Implications:
- Some validators/tools may allow logical ids such as "123##^@1234aa df sdf"
- Systems (DBs, processors) expecting logical id formats will fail when trying to use the "123##^@1234aa df sdf" logical id
- The HL7 Validator Command Line (java) correctly validates logical ids in R4 and will catch the above non-conformance, but other validation packages might not.


Separately and unrelated, there is a visual bug in the current FHIR (R4B) spec at hl7.org/fhir/resource.html#resource that shows Resource.id as string type. The underlying spec is correctly defining this as "id" type. Completely unrelated and unfortunate red herring.

This is a PSA regarding namedresource.id data type that one of our Canadian FHIR Implementers recently ran into. We felt it was helpful to raise in case others in our community weren't aware of it and are starting to work with vendors to generate and test examples.

There is a known issue with namedResource.id where the data type & data type extensions were mistyped in the base spec that may lead implementers to use the string data type rather than id data type - leading to constraints on namedResource.id being looser than what will be enforced by validation tools/expected by databases that have been configured to use the id data type. Even though the data type for resource.id is shown as “string” (which allows for special characters), there are more deeply layered mechanical expectations in earlier and later versions of FHIR for namedResource.id (that may impact what conformance artifacts expect and how databases are configured) that will enforce the “id” data type’s tighter rules of regex (alphanumeric w 64 char limit).

So any FHIR implementers in Canada using R4 and R4B should be aware of this discrepancy moving forward and avoid providing guidance/implementing design for resource.id that doesn’t conform to the regex constraints below for the id data type.

Id data type constraints:
Any combination of upper- or lower-case ASCII letters ('A'..'Z', and 'a'..'z', numerals ('0'..'9'), '-' and '.', with a length limit of 64 characters. (This might be an integer, an un-prefixed OID, UUID or any other identifier pattern that meets these constraints.)
Regex: [A-Za-z0-9\-\.]{1,64}

Those who are interested in exploring the technical nitty gritty/history of the issue can find more information on the chat.fhir.org discussion here and in the jira ticket here .