This page is part of the US Core (v3.1.1: STU3) based on FHIR R4. The current version which supercedes this version is 5.0.1. For a full list of available versions, see the Directory of published versions

• Narrative Content
• Detailed Descriptions
• XML
• JSON

StructureDefinition-us-core-provenance

This profile sets minimum expectations for the Provenance resource to record, search, and fetch Provenance information associated with a record. It identifies which core elements, extensions, vocabularies and value sets SHALL be present in the resource when using this profile. This FHIR Provenance profile here covers the minimal (basic) information to support lineage of information. Prior to reviewing this profile, implementers are encouraged to read the Basic Provenance guidance page which documents several key use cases.

Example Usage Scenarios:

The following are example usage scenarios for the US Core Provenance profile:

• Query for the Provenance records associated with an Allergy
• Query for the Provenance records associated with a Problem

Mandatory and Must Support Data Elements

The following data-elements are mandatory (i.e. data MUST be present) or must be supported if the data is present in the sending system (Must Support definition). They are presented below in a simple human-readable explanation. Profile specific guidance and examples are provided as well. The Formal Profile Definition below provides the formal summary, definitions, and terminology requirements.

Each Provenance must have:

1. resource(s) the Provenance record is supporting (target)
2. a date and time for the activity

Each Provenance must support:

1. an author responsible for the update
2. the author organization responsible for the information
3. the transmitter that provided the information
4. the transmitter organization responsible for the transmission (if the transmitter is a device the transmitter organization must also be valued).

Profile specific implementation guidance:

• The US Core Provenance resource SHALL be supported for these US Core resources:
  • US Core AllergyIntolerance Profile
  • US Core CarePlan Profile
  • US Core CareTeam Profile
  • US Core Condition Profile
  • US Core DiagnosticReport Profile for Laboratory Results Reporting
  • US Core DiagnosticReport Profile for Report and Note exchange
  • US Core DocumentReference Profile
  • US Core Encounter Profile
  • US Core Goal Profile
  • US Core Immunization Profile
  • US Core Implantable Device Profile
  • US Core Laboratory Result Observation Profile
  • US Core MedicationRequest Profile
  • US Core Patient Profile
  • US Core Pediatric BMI for Age Observation Profile
  • US Core Pediatric Weight for Height Observation Profile
  • US Core Procedure Profile
  • US Core Pulse Oximetry Profile
  • US Core Smoking Status Observation Profile
  • The Vital Signs Profile from the FHIR Specification
• If a system receives a provider in Provenance.agent.who as free text they must capture who sent them the information as the organization. On request they SHALL provide this organization as the source and MAY include the free text provider.

Examples

• Allergyintolerance Provenance Example: A searchset Bundle including both AllergyIntolerance and Provenance

Formal Views of Profile Content

Description of Profiles, Differentials, and Snapshots.

The official URL for this profile is: http://hl7.org/fhir/us/core/StructureDefinition/us-core-provenanceCopy

Published on Mon Aug 05 00:00:00 AEST 2019 as active by the HL7 US Realm Steering Committee.

This profile builds on Provenance

---

Downloads: StructureDefinition: (XML, JSON), Schema: XML Schematron

Quick Start

Below is an overview of the required set of Server RESTful FHIR interactions - for example, search and read operations - for this profile. See the Conformance requirements for a complete list of supported RESTful interactions for this IG.

• See the General Guidance section for additional rules and expectations when a server requires status parameters.
• See the General Guidance section for additional guidance on searching for multiple patients.

Mandatory Search Parameters:

The following search parameters, search parameter combinations SHALL be supported. Any listed search parameter modifiers, comparators, chains and composites SHALL also be supported UNLESS they are listed as “optional” in which case they SHOULD be supported.:

1. SHALL support searching for all US Core Profile resource types listed above for a patient and all the Provenance records for those resources using a combination of the patient and _revinclude search parameters:

   GET [base]/[Resource]?patient=[id]&_revinclude=Provenance:target

   Example:

   1. GET [base]/AllergyIntolerance?patient=[id]5&_revinclude=Provenance:target

   Implementation Notes: Fetches a bundle of all resources of a particular type for the specified patient (how to search by reference) and any corresponding Provenance resources.

2. SHALL support searching for a particular instance of a US Core Profile resource type listed above and all its Provenance resources using combination of the _id and the _revinclude search parameters:

   GET [base]/[Resource]?_id=[id]&_revinclude=Provenance:target

   Example:

   1. GET [base]/AllergyIntolerance?_id=[id]&_revinclude=Provenance:target

   Implementation Notes: Fetches a bundle of a resource of a particular type (within the clients authorization scope) and any corresponding Provenance resources. (how to search by token)