3 common and 3 less common attributes of FHIR’s Meta element

All FHIR resources have a Meta element containing metadata about the resource. Some attributes are updated by the server, others are populated by the app constructing the resource.

Here are the 3 common attributes of FHIR’s Meta element: 

1. versionId
This is an ID that identifies a saved version of the resource on the FHIR server. Many servers use a GUID here, others use an integer. But it’s a string value, so don’t write code against this assuming a sequential integer, regardless of what the server does.

2. lastUpdated
The date and time that the resource was last updated, populated by the server. Most of us will have used this as a sort parameter in query strings to get the most recently updated resources.

3. profile
A list of FHIR profiles that the resource must conform to. This can be populated by the sender, or populated dynamically by some middleware before the request reaches the FHIR server. Depending on how the server is configured and how the request is structured, it will usually trigger a validation of the resource against the specified profiles.

And Here are the 3 less common attributes of FHIR’s Meta element: 

4. security
A list of Security Labels applied to the resource. Not used as often as it could be, and often ignored when it shouldn’t be! Your app needs to handle Security Labels, especially if you’re receiving Bundles from external sources.

Security Labels tend to fall into one of three categories.

1. Purpose of Use
   • From ‘clinical trial’ to ‘coordination of care’
   • If a resource is labelled as ‘clinical trial’ data, you should not be handling it as if it were regular data.
2. Confidentiality Codes
   • From ‘unrestricted’ to ‘very restricted’
   • A ‘very restricted’ label might signify a VIP patient, or sensitive psychiatric data that should not be shared without explicit permission.
3. Control of Flow
   • From ‘Delete After Use’ to ‘Test Data’
   • If it comes with a ‘Delete After Use’ label, you shouldn’t store it — not even inside an audit trail.

5. tags
Again, seldom used. Tags connect resources to processes and workflows. They can be ignored by consuming applications which might account for their sparse use.

6. source
It identifies the source of the data. It’s often used in place of a Provenance resource, which can fulfil a similar function.

Thanks