HL7 FHIR® US Core Implementation Guide STU3 Release 3.1.1

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

StructureDefinition-us-core-condition

This profile sets minimum expectations for the Condition resource to record, search, and fetch a list of conditions 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 Condition profile:

  • Query for a Patient’s current or historical conditions
  • Record or update a Patient’s conditions

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

  1. a status of the condition*
  2. a category
  3. a code that identifies the condition
  4. a patient

*The status element has the following constraints: SHALL be present if verification status is not entered-in-error and SHALL NOT be present if verification Status is entered-in-error.

Each Condition must support:

  1. a verification status

Profile specific implementation guidance:

  • The US Core Condition Category Codes support the separate types of conditions so API consumers can separate health concerns, problems, and encounter diagnoses.
  • The 2015 Certification rule requires the use of SNOMED CT for problem list entries. Following the rules for extensible binding to coded data types, ICD or other local codes can be used as translations to SNOMED CT.
  • The US Core Condition Code supports ICD-9-CM for historical purposes only. ICD-10-CM is available and may be used as the primary code for current encounter diagnoses.
  • To search for an encounter diagnosis, query for Conditions that reference the Encounter of interest and have a category of encounter-diagnosis. An example search is shown in the Quick Start section below.

Examples

  • Condition-hc1 is an example of a condition categorized as a “health-concern”
  • Condition-example is an example of a condition categorized as a “problem”

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

Published on Sat Jun 27 00:00:00 AEST 2020 as active by the Health Level Seven International (Infrastructure and Messaging - Data Access Framework).

This profile builds on Condition

Condition

Summary of the Mandatory Requirements

  1. One or more CodeableConcepts in Condition.category with an extensible binding to US Core Condition Category Codes
  2. A CodeableConcept in Condition.code with an extensible binding to US Core Condition Code
  3. A Patient Reference in Condition.subject

Summary of the Must Support Requirements

  1. A CodeableConcept in Condition.clinicalStatus with a required binding to Condition Clinical Status Codes
  2. A CodeableConcept in Condition.verificationStatus with a required binding to ConditionVerificationStatus

Summary of Constraints

  1. Condition.clinicalStatus SHALL NOT be present if verification Status is entered-in-error
  2. If condition is abated, then clinicalStatus must be either inactive, resolved, or remission
  3. Condition.clinicalStatus SHALL be present if verificationStatus is not entered-in-error and category is problem-list-item
  4. A code in Condition.category SHOULD be from US Core Condition Category Codes value set.
NameFlagsCard.TypeDescription & Constraintsdoco
.. Condition I0..*ConditionDetailed information about conditions, problems or diagnoses
us-core-1: A code in Condition.category SHOULD be from US Core Condition Category Codes value set.
... clinicalStatus S0..1CodeableConceptactive | recurrence | relapse | inactive | remission | resolved
Binding: ConditionClinicalStatusCodes (required)
... verificationStatus S0..1CodeableConceptunconfirmed | provisional | differential | confirmed | refuted | entered-in-error
Binding: ConditionVerificationStatus (required)
... category SI1..*CodeableConceptproblem-list-item | encounter-diagnosis | health-concern
Binding: US Core Condition Category Codes (extensible)
... code S1..1CodeableConceptIdentification of the condition, problem or diagnosis
Binding: US Core Condition Code (extensible)
... subject S1..1Reference(US Core Patient Profile)Who has the condition?

doco Documentation for this format
NameFlagsCard.TypeDescription & Constraintsdoco
.. Condition I0..*ConditionDetailed information about conditions, problems or diagnoses
us-core-1: A code in Condition.category SHOULD be from US Core Condition Category Codes value set.
... 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 condition
... clinicalStatus ?!SΣI0..1CodeableConceptactive | recurrence | relapse | inactive | remission | resolved
Binding: ConditionClinicalStatusCodes (required)
... verificationStatus ?!SΣI0..1CodeableConceptunconfirmed | provisional | differential | confirmed | refuted | entered-in-error
Binding: ConditionVerificationStatus (required)
... category SI1..*CodeableConceptproblem-list-item | encounter-diagnosis | health-concern
Binding: US Core Condition Category Codes (extensible)
... severity I0..1CodeableConceptSubjective severity of condition
Binding: Condition/DiagnosisSeverity (preferred)
... code SΣI1..1CodeableConceptIdentification of the condition, problem or diagnosis
Binding: US Core Condition Code (extensible)
... bodySite ΣI0..*CodeableConceptAnatomical location, if relevant
Binding: SNOMEDCTBodyStructures (example)
... subject SΣI1..1Reference(US Core Patient Profile)Who has the condition?
... encounter ΣI0..1Reference(Encounter)Encounter created as part of
... onset[x] ΣI0..1Estimated or actual date, date-time, or age
.... onsetDateTimedateTime
.... onsetAgeAge
.... onsetPeriodPeriod
.... onsetRangeRange
.... onsetStringstring
... abatement[x] I0..1When in resolution/remission
.... abatementDateTimedateTime
.... abatementAgeAge
.... abatementPeriodPeriod
.... abatementRangeRange
.... abatementStringstring
... recordedDate ΣI0..1dateTimeDate record was first recorded
... recorder ΣI0..1Reference(Practitioner | PractitionerRole | Patient | RelatedPerson)Who recorded the condition
... asserter ΣI0..1Reference(Practitioner | PractitionerRole | Patient | RelatedPerson)Person who asserts this condition
... stage I0..*BackboneElementStage/grade, usually assessed formally
con-1: Stage SHALL have summary or assessment
.... 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
.... summary I0..1CodeableConceptSimple summary (disease specific)
Binding: ConditionStage (example)
.... assessment I0..*Reference(ClinicalImpression | DiagnosticReport | Observation)Formal record of assessment
.... type I0..1CodeableConceptKind of staging
Binding: ConditionStageType (example)
... evidence I0..*BackboneElementSupporting evidence
con-2: evidence SHALL have code or details
.... 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
.... code ΣI0..*CodeableConceptManifestation/symptom
Binding: ManifestationAndSymptomCodes (example)
.... detail ΣI0..*Reference(Resource)Supporting information found elsewhere
... note I0..*AnnotationAdditional information about the Condition

doco Documentation for this format

Condition

Summary of the Mandatory Requirements

  1. One or more CodeableConcepts in Condition.category with an extensible binding to US Core Condition Category Codes
  2. A CodeableConcept in Condition.code with an extensible binding to US Core Condition Code
  3. A Patient Reference in Condition.subject

Summary of the Must Support Requirements

  1. A CodeableConcept in Condition.clinicalStatus with a required binding to Condition Clinical Status Codes
  2. A CodeableConcept in Condition.verificationStatus with a required binding to ConditionVerificationStatus

Summary of Constraints

  1. Condition.clinicalStatus SHALL NOT be present if verification Status is entered-in-error
  2. If condition is abated, then clinicalStatus must be either inactive, resolved, or remission
  3. Condition.clinicalStatus SHALL be present if verificationStatus is not entered-in-error and category is problem-list-item
  4. A code in Condition.category SHOULD be from US Core Condition Category Codes value set.

Differential View

NameFlagsCard.TypeDescription & Constraintsdoco
.. Condition I0..*ConditionDetailed information about conditions, problems or diagnoses
us-core-1: A code in Condition.category SHOULD be from US Core Condition Category Codes value set.
... clinicalStatus S0..1CodeableConceptactive | recurrence | relapse | inactive | remission | resolved
Binding: ConditionClinicalStatusCodes (required)
... verificationStatus S0..1CodeableConceptunconfirmed | provisional | differential | confirmed | refuted | entered-in-error
Binding: ConditionVerificationStatus (required)
... category SI1..*CodeableConceptproblem-list-item | encounter-diagnosis | health-concern
Binding: US Core Condition Category Codes (extensible)
... code S1..1CodeableConceptIdentification of the condition, problem or diagnosis
Binding: US Core Condition Code (extensible)
... subject S1..1Reference(US Core Patient Profile)Who has the condition?

doco Documentation for this format

Snapshot View

NameFlagsCard.TypeDescription & Constraintsdoco
.. Condition I0..*ConditionDetailed information about conditions, problems or diagnoses
us-core-1: A code in Condition.category SHOULD be from US Core Condition Category Codes value set.
... 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 condition
... clinicalStatus ?!SΣI0..1CodeableConceptactive | recurrence | relapse | inactive | remission | resolved
Binding: ConditionClinicalStatusCodes (required)
... verificationStatus ?!SΣI0..1CodeableConceptunconfirmed | provisional | differential | confirmed | refuted | entered-in-error
Binding: ConditionVerificationStatus (required)
... category SI1..*CodeableConceptproblem-list-item | encounter-diagnosis | health-concern
Binding: US Core Condition Category Codes (extensible)
... severity I0..1CodeableConceptSubjective severity of condition
Binding: Condition/DiagnosisSeverity (preferred)
... code SΣI1..1CodeableConceptIdentification of the condition, problem or diagnosis
Binding: US Core Condition Code (extensible)
... bodySite ΣI0..*CodeableConceptAnatomical location, if relevant
Binding: SNOMEDCTBodyStructures (example)
... subject SΣI1..1Reference(US Core Patient Profile)Who has the condition?
... encounter ΣI0..1Reference(Encounter)Encounter created as part of
... onset[x] ΣI0..1Estimated or actual date, date-time, or age
.... onsetDateTimedateTime
.... onsetAgeAge
.... onsetPeriodPeriod
.... onsetRangeRange
.... onsetStringstring
... abatement[x] I0..1When in resolution/remission
.... abatementDateTimedateTime
.... abatementAgeAge
.... abatementPeriodPeriod
.... abatementRangeRange
.... abatementStringstring
... recordedDate ΣI0..1dateTimeDate record was first recorded
... recorder ΣI0..1Reference(Practitioner | PractitionerRole | Patient | RelatedPerson)Who recorded the condition
... asserter ΣI0..1Reference(Practitioner | PractitionerRole | Patient | RelatedPerson)Person who asserts this condition
... stage I0..*BackboneElementStage/grade, usually assessed formally
con-1: Stage SHALL have summary or assessment
.... 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
.... summary I0..1CodeableConceptSimple summary (disease specific)
Binding: ConditionStage (example)
.... assessment I0..*Reference(ClinicalImpression | DiagnosticReport | Observation)Formal record of assessment
.... type I0..1CodeableConceptKind of staging
Binding: ConditionStageType (example)
... evidence I0..*BackboneElementSupporting evidence
con-2: evidence SHALL have code or details
.... 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
.... code ΣI0..*CodeableConceptManifestation/symptom
Binding: ManifestationAndSymptomCodes (example)
.... detail ΣI0..*Reference(Resource)Supporting information found elsewhere
... note I0..*AnnotationAdditional information about the Condition

doco Documentation for this format

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.

  • The syntax used to describe the interactions is described here.

  • 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 for all conditions including problems, health concerns, and encounter diagnosis for a patient using the patient search parameter:

    GET [base]/Condition?patient=[reference]

    Example:

    1. GET [base]/Condition?patient=1137192

    Implementation Notes: Fetches a bundle of all Condition resources for the specified patient (how to search by reference)

Optional Search Parameters:

The following search parameter combinations SHOULD be supported.:

  1. SHOULD support searching using the combination of the patient and clinical-status search parameters:

    GET [base]/Condition?patient=[reference]&clinical-status=http://terminology.hl7.org/CodeSystem/condition-clinical|active,http://terminology.hl7.org/CodeSystem/condition-clinical|recurrance,http://terminology.hl7.org/CodeSystem/condition-clinical|remission

    Example:

    1. GET [base/Condition?patient=1032702&clinical-status=http://terminology.hl7.org/CodeSystem/condition-clinical|active,http://terminology.hl7.org/CodeSystem/condition-clinical|recurrance,http://terminology.hl7.org/CodeSystem/condition-clinical|remission

    Implementation Notes: Fetches a bundle of all Condition resources for the specified patient and all "active" statuses (active,relapse,remission). This will not return any "entered in error" resources because of the conditional presence of the clinicalStatus element. (how to search by reference and how to search by token)

  2. SHOULD support searching using the combination of the patient and category search parameters:

    GET [base]/Condition?patient=[reference]&category={system|}[code]

    Example:

    1. GET [base]/Condition?patient=1032702&category=http://terminology.hl7.org/CodeSystem/condition-category|problem-list-item
    2. GET [base]/Condition?patient=1032702&category=http://hl7.org/fhir/us/core/CodeSystem/condition-category|health-concern
    3. GET [base]/Condition?patient=1032702&category=http://terminology.hl7.org/CodeSystem/condition-category|encounter-diagnosis

    Implementation Notes: Fetches a bundle of all Condition resources for the specified patient and category. (how to search by reference and how to search by token)

  3. SHOULD support searching using the combination of the patient and code search parameters:

    GET [base]/Condition?patient=[reference]&code={system|}[code]

    Example:

    1. GET [base]/Condition?patient=1032702&code=[http://snomed.info/sct|442311008]

    Implementation Notes: Fetches a bundle of all Condition resources for the specified patient and code. (how to search by reference and how to search by token)

  4. SHOULD support searching using the combination of the patient and onset-date search parameters:

    • including support for these onset-date comparators: gt,lt,ge,le
    • including optional support for composite AND search on onset-date (e.g.onset-date=[date]&onset-date=[date]]&...)

    GET [base]/Condition?patient=[reference]&onset-date={gt|lt|ge|le}[date]{&onset-date={gt|lt|ge|le}[date]&...}

    Example:

    1. GET [base]Condition?patient=555580&date=ge2018-01-14

    Implementation Notes: Fetches a bundle of all Condition resources for the specified patient and date. (how to search by reference and how to search by date)