Handling identifiers
This specification has attempted to promote as much re-usability as possible by using the GP Connect Data model (STU3 representation) - that is, the same model as Access Record: Structured - but with ITK3 as the vehicle to transport the data around.
There are, however, some differences around identification between the two that need to be addressed.
urn:uuid:[id]
ITK3 uses urn:uuid:[id]
to identify resources within the body of the message. Therefore, this specification has used the same, and this is what receivers are expecting to be within the payload.
id
and identifier
elements accordingly to support Update Record.
resourceName/[id]
Access Record: Structured prefers the resource name followed by the identifier for identification - a process which tends to be more performant, as well as easier to read for a human.
For example:
Patient/17e54bea-340a-46ff-a765-08816a1e2e74
Encounter/6125a4f6-50f7-4ae6-955a-44ca44a99864
Practitioner/583fdceb-05df-484a-a1b1-ef148cf5e13e
This approach is preferred going forward; however, it cannot be harnessed while using ITK3.