Contact Us

SMART on FHIR

Storing Source Information

Note: Opala’s publicly documented APIs are read-only. The guidance and examples on this page describe standard FHIR behavior on a Firely-based server for reference. Write operations and administrative server behaviors are not available on public endpoints.

Resource.meta.source exists on every FHIR resource and records the origin of the data as a URI (e.g., another FHIR server, a document, or an application). If a client includes meta.source on create/update, the server persists that value in the resource’s metadata.

Per the FHIR specification, meta.source is a single URI that identifies the source system. In Opala’s platform it is stored exactly as provided. For richer lineage (e.g., request or transaction IDs), the standard mechanism is the Provenance resource (not exposed on Opala’s public APIs). You can also indicate origin using a coded meta.tag value, which is searchable via _tag.

Clients set meta.source by including a URI in Resource.meta.source in the request body. The server does not derive or augment meta.source from HTTP headers (e.g., it does not combine a request ID into meta.source). If you must capture request correlation IDs, model them with Provenance in environments where it is supported.

Capturing

Clients set meta.source by placing a URI in Resource.meta.source in the request body. The server does not derive or augment meta.source from HTTP headers (e.g., it does not combine a request ID into meta.source). If you must capture request correlation IDs, model them using Provenance in environments where it is supported (standard FHIR; not exposed on Opala’s public APIs).

Example (create with meta.source):

POST https://{baseurl}/Patient
Content-Type: application/fhir+json

{
      “resourceType”: “Patient”,
      “meta”: {
            “source”: “https://example.com/some-app”
      },
      “name”: [
            {
                  “family”: “Gold”
            }
      ]
}

Notes:

  • The value is a single URI. A request ID does not support the appending of “#…”.

  • Opala does not map custom HTTP headers to populate Meta.source (for example, X-Request-ID or X-Request-System are ignored for this purpose).

If meta-source is omitted, no source URI is stored on the resource.

Use the _source search parameter to filter by a resource’s meta.source URI (exact match; URL-escape as needed).

Examples:

GET https://{baseurl}/Patient?_source=https://somesystem.example.org/foo
GET https://{baseurl}/Observation?_source=https%3A%2F%2Fpartner.example.com%2Fapp%2Fingest

Notes:

  • _source matches a single URI value (meta.source). Do not use a URI#requestId convention.

  • For request/transaction IDs or richer lineage, use standard Provenance where available (reference context only; not exposed on Opala’s public APIs).

  • If you are targeting a non-Opala Firely environment, confirm _source support in the server’s CapabilityStatement.

Example: Storing Source Information

The following request sets a source URI on a new resource.

POST https://{baseurl}/Patient
Content-Type: application/fhir+json

Body:
{
      “resourceType”: “Patient”,
      “meta”: {
            “source”: “https://somesystem.example.org/foo”
      },
      “name”: [
            {
                  “family”: “Gold”
            }
      ]
}

If meta.source is omitted, no source URI is stored on the resource. If you need request correlation IDs, include them in a related Provenance resource (not in meta.source), if Provenance is available.