USCoreR4 Implementation Guide CI Build

This is the Continuous Integration Build of the USCoreR4 Implementation Guide, based on FHIR Version 3.6.0. 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 problems and health concerns 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 problems
  • Record or update a Patient’s problem
Mandatory Data Elements and Terminology

The following data-elements are mandatory (i.e data MUST be present). These 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 problem
  2. a verification status
  3. a category
  4. a code that identifies the problem
  5. a patient

Profile specific implementation guidance:

  • The US Core Condition Category Codes support the separate concepts of problems and health concerns so API consumers can separate health concerns and problems. However this is not mandatory for 2015 certification
  • 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 or in addition to SNOMED CT.
Examples
  • Condition-hc1 is an example of a condition categorized as a “problem”
  • Condition-example is an example of a condition categorized as a “health-concern”

Formal Views of Profile Content

Description of Profiles, Differentials, and Snapshots.

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

Published on Thu Aug 21 00:00:00 PDT 2014 as a draft by Health Level Seven International (Infrastructure and Messaging - Data Access Framework).

This profile builds on Condition

Summary

Mandatory: 4 elements
Must-Support: 5 elements

Structures

This structure refers to these other structures:

Snapshot View

NameFlagsCard.TypeDescription & Constraintsdoco
.. Condition I0..*US Core Condition Profile
us-core-1: A code in Condition.category SHOULD be from US Core Condition Category Codes value set.
... id Σ0..1idLogical id of this artifact
... meta Σ0..1MetaMetadata about the resource
... implicitRules ?!Σ0..1uriA set of rules under which this content was created
... language 0..1codeLanguage of the resource content
Binding: CommonLanguages (preferred)
... text 0..1NarrativeText summary of the resource, for human interpretation
... contained 0..*ResourceContained, inline Resources
... extension 0..*ExtensionAdditional content defined by implementations
... modifierExtension ?!0..*ExtensionExtensions that cannot be ignored
... identifier Σ0..*IdentifierExternal Ids for this condition
... clinicalStatus ?!SΣI0..1CodeableConceptactive | recurrence | relapse | inactive | remission | resolved
Binding: ConditionClinicalStatusCodes (required)
... verificationStatus ?!SΣI1..1CodeableConceptunconfirmed | provisional | differential | confirmed | refuted | entered-in-error
Binding: ConditionVerificationStatus (required)
... category S1..*CodeableConceptproblem-list-item | encounter-diagnosis
Binding: US Core Condition Category Codes (preferred)
... severity 0..1CodeableConceptSubjective severity of condition
Binding: Condition/DiagnosisSeverity (preferred)
... code SΣ1..1CodeableConceptIdentification of the condition, problem or diagnosis
Binding: Problem Value Set (extensible)
... bodySite Σ0..*CodeableConceptAnatomical location, if relevant
Binding: SNOMEDCTBodyStructures (example)
... subject SΣ1..1Reference(US Core Patient Profile)Who has the condition?
... encounter Σ0..1Reference(Encounter)Encounter created as part of
... onset[x] Σ0..1dateTime, Age, Period, Range, stringEstimated or actual date, date-time, or age
... abatement[x] I0..1dateTime, Age, Period, Range, stringWhen in resolution/remission
... recordedDate Σ0..1dateTimeDate record was first recorded
... recorder Σ0..1Reference(Practitioner | Patient | RelatedPerson)Who recorded the condition
... asserter Σ0..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 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*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 0..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 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... code ΣI0..*CodeableConceptManifestation/symptom
Binding: ManifestationAndSymptomCodes (example)
.... detail ΣI0..*Reference(Resource)Supporting information found elsewhere
... note 0..*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 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.

GET /Condition?patient=[id]

Example: GET [base]/Condition?patient=1032702

Support: Mandatory to support search by patient.

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

GET /Condition?patient=[id]&clinicalstatus=active,recurrance,remission

Example: GET [base]/Condition?patient=1032702&clinicalstatus=active,relapse,remission

Support: Optional to support search by status.

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

GET /Condition?patient=[id]&category=problem

Example: GET [base]/Condition?patient=1032702&category=problem

Support: Optional to support search by patient and category.

Implementation Notes: earch for all Problems for a patient. Fetches a bundle of all Condition resources for the specified patient with a category code of “problem” (how to search by reference) and (how to search by token).

GET /Condition?patient=[id]&category=health-concern

Example: GET [base]/Condition?patient=1032702&category=health-concern

Support: Optional to support search by patient and category.

Implementation Notes: Search for all Health Concerns for a patient. Fetches a bundle of all Condition resources for the specified patient with a category code of “health-concern”(how to search by reference) and (how to search by token).