HL7 FHIR® US Core Implementation Guide STU3 Release 3.1.0

This page is part of the US Core (v3.1.0: 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

StructureDefinition-us-core-careteam

This profile sets minimum expectations for the CareTeam resource for identifying the Care Team members associated with a patient. It identifies which core elements, extensions, vocabularies and value sets SHALL be present in the resource when using this profile.

Example Usage Scenarios:

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

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 CareTeam must have:

  1. a patient
  2. a participant role for each careteam members
  3. names of careteam members which can be:
    • a practitioner (doctor, nurse, therapist)
    • the patient
    • a relative or friend or guardian
    • an organization

Each Condition must support:

  1. a status code

Profile specific implementation guidance:

  • none

Examples

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-careteam

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

This profile builds on CareTeam


CareTeam

Summary of the Mandatory Requirements

  1. A Patient Reference in CareTeam.subject
  2. One or more Participants in CareTeam.participant with the following constraints: CareTeam.participant.onBehalfOf can only be populated when CareTeam.participant.member is a Practitioner

Summary of the Must Support Requirements

  1. A code in CareTeam.status with a required binding to CareTeamStatus

Summary of Constraints

  1. CareTeam.participant.onBehalfOf can only be populated when CareTeam.participant.member is a Practitioner
NameFlagsCard.TypeDescription & Constraintsdoco
.. CareTeam I0..*Planned participants in the coordination and delivery of care for a patient or group
... id Σ0..1stringLogical id of this artifact
... meta ΣI0..1MetaMetadata about the resource
... implicitRules ?!ΣI0..1uriA set of rules under which this content was created
... language I0..1codeLanguage of the resource content
Binding: CommonLanguages (preferred)
Max Binding: AllLanguages
... text I0..1NarrativeText summary of the resource, for human interpretation
... contained 0..*ResourceContained, inline Resources
... extension I0..*ExtensionAdditional content defined by implementations
... modifierExtension ?!I0..*ExtensionExtensions that cannot be ignored
... identifier ΣI0..*IdentifierExternal Ids for this team
... status ?!SΣI0..1codeproposed | active | suspended | inactive | entered-in-error
Binding: CareTeamStatus (required)
... category ΣI0..*CodeableConceptType of team
Binding: CareTeamCategory (example)
... name ΣI0..1stringName of the team, such as crisis assessment team
... subject SΣI1..1Reference(US Core Patient Profile)Who care team is for
... encounter ΣI0..1Reference(Encounter)Encounter created as part of
... period ΣI0..1PeriodTime period team covers
... participant SI1..*BackboneElementMembers of the team
.... id 0..1stringUnique id for inter-element referencing
.... extension I0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!ΣI0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... role SΣI1..1CodeableConceptType of involvement
Binding: US Core CareTeam Provider Roles (extensible)
.... member SΣI1..1Reference(US Core Patient Profile | US Core Practitioner Profile | US Core Organization Profile | RelatedPerson)Who is involved
.... onBehalfOf ΣI0..1Reference(Organization)Organization of the practitioner
.... period I0..1PeriodTime period of participant
... reasonCode I0..*CodeableConceptWhy the care team exists
Binding: SNOMEDCTClinicalFindings (example)
... reasonReference I0..*Reference(Condition)Why the care team exists
... managingOrganization ΣI0..*Reference(Organization)Organization responsible for the care team
... telecom I0..*ContactPointA contact detail for the care team (that applies to all members)
... note I0..*AnnotationComments made about the CareTeam

doco Documentation for this format

CareTeam

Summary of the Mandatory Requirements

  1. A Patient Reference in CareTeam.subject
  2. One or more Participants in CareTeam.participant with the following constraints: CareTeam.participant.onBehalfOf can only be populated when CareTeam.participant.member is a Practitioner

Summary of the Must Support Requirements

  1. A code in CareTeam.status with a required binding to CareTeamStatus

Summary of Constraints

  1. CareTeam.participant.onBehalfOf can only be populated when CareTeam.participant.member is a Practitioner

Snapshot View

NameFlagsCard.TypeDescription & Constraintsdoco
.. CareTeam I0..*Planned participants in the coordination and delivery of care for a patient or group
... id Σ0..1stringLogical id of this artifact
... meta ΣI0..1MetaMetadata about the resource
... implicitRules ?!ΣI0..1uriA set of rules under which this content was created
... language I0..1codeLanguage of the resource content
Binding: CommonLanguages (preferred)
Max Binding: AllLanguages
... text I0..1NarrativeText summary of the resource, for human interpretation
... contained 0..*ResourceContained, inline Resources
... extension I0..*ExtensionAdditional content defined by implementations
... modifierExtension ?!I0..*ExtensionExtensions that cannot be ignored
... identifier ΣI0..*IdentifierExternal Ids for this team
... status ?!SΣI0..1codeproposed | active | suspended | inactive | entered-in-error
Binding: CareTeamStatus (required)
... category ΣI0..*CodeableConceptType of team
Binding: CareTeamCategory (example)
... name ΣI0..1stringName of the team, such as crisis assessment team
... subject SΣI1..1Reference(US Core Patient Profile)Who care team is for
... encounter ΣI0..1Reference(Encounter)Encounter created as part of
... period ΣI0..1PeriodTime period team covers
... participant SI1..*BackboneElementMembers of the team
.... id 0..1stringUnique id for inter-element referencing
.... extension I0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!ΣI0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... role SΣI1..1CodeableConceptType of involvement
Binding: US Core CareTeam Provider Roles (extensible)
.... member SΣI1..1Reference(US Core Patient Profile | US Core Practitioner Profile | US Core Organization Profile | RelatedPerson)Who is involved
.... onBehalfOf ΣI0..1Reference(Organization)Organization of the practitioner
.... period I0..1PeriodTime period of participant
... reasonCode I0..*CodeableConceptWhy the care team exists
Binding: SNOMEDCTClinicalFindings (example)
... reasonReference I0..*Reference(Condition)Why the care team exists
... managingOrganization ΣI0..*Reference(Organization)Organization responsible for the care team
... telecom I0..*ContactPointA contact detail for the care team (that applies to all members)
... note I0..*AnnotationComments made about the CareTeam

doco Documentation for this format

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


Quick Start

Below is an overview of the required set of 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 and search parameter combinations SHALL be supported.:

  1. SHALL support searching using the combination of the patient and status search parameters:
    • including support for composite OR search on status (e.g.status={[system]}|[code],{[system]}|[code],...)

    GET [base]/CareTeam?patient=[reference]&status=active

    Example:

    1. GET [base]/CareTeam?patient=1137192&status=active

    Implementation Notes: Fetches a bundle of all CareTeam resources for the specified patient and status =active (how to search by reference and how to search by token)