An issue was identified with the FHIR package supplied with this version of the specification, which has been rectified.
Please click here to view the patched v1.1.1-public-beta specification with the updated FHIR package.
Handling identifiers
This specification has attempted to promote as much re-usability as possible by using the GP Connect Data model (STU3 representation) - e.g., the same model as Access Record: Structured - but with ITK3 as the vehicle to transport that 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-08816a1e2e74Encounter/6125a4f6-50f7-4ae6-955a-44ca44a99864Practitioner/583fdceb-05df-484a-a1b1-ef148cf5e13e
This approach is preferred going forward; however, it cannot be harnessed while using ITK3.