Background: We’re building a FHIR API on top of a couple of existing legacy applications with a goal of eventually consolidating into a true microservice. Each of those applications is broken up by tenant. This means that for every request to our API we need to know which application and tenant it’s related to. To support this, we’re considering including an applicationId and tenantId as identifiers in the FHIR Identifier block so our consumers have this information available.
For now, my specific questions are about understanding the true intent of the identifier block:
- Is it ok to use the Identifiers block for contextual identifiers, such as applicationId and tenantId as I’ve described above as long we define a specific uri for each of them? …or is the intent that each item in the identifiers block is simply an alternate identifier for the given FHIR resource?
- Should each item in the Identifiers block point to a FHIR object that can be retrieved via a GET?
Any insights appreciated!
Scott C.
>Solution :
Patient.identifier must contain identifiers that are identifying the patient and should be unique to that patient. The same goes for Observations, Procedures and other records. If you want to track ownership of a record by a particular system, that’d be better captured using meta.tag or possibly meta.source.