Profile Comparison between http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition-encounter-diagnosis vs http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-Condition

Messages

Metadata

Name	Value		Comments
abstract	false
baseDefinition	http://hl7.org/fhir/StructureDefinition/Condition	http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition	Values Differ
copyright	Used by permission of HL7 International, all rights reserved Creative Commons License		Removed the item 'Used by permission of HL7 International, all rights reserved Creative Commons License'
date	2022-04-20	2020-12-14T04:01:34+00:00	Values Differ
description	The US Core Condition Encounter Diagnosis Profile is based upon the core FHIR Condition Resource and meets the U.S. Core Data for Interoperability (USCDI) v2 *Encounter Diagnosis* requirements. In version 5.0.0, The US Core Condition Profile has been split into the US Core Condition Encounter Diagnosis Profile and US Core Condition Problems and Health Concerns Profile. To promote interoperability and adoption through common implementation, this profile defines constraints and extensions on the Condition resource for the minimal set of data to record, search, and fetch information about an encounter diagnosis. It identifies which core elements, extensions, vocabularies, and value sets **SHALL** be present in the resource when using this profile. It provides the floor for standards development for specific use cases.	Profile for Social Determinants of Health (SDOH) conditions.	Values Differ
experimental	false		Removed the item 'false'
fhirVersion	4.0.1
jurisdiction
jurisdiction[0]	urn:iso:std:iso:3166#US
kind	resource
name	USCoreConditionEncounterDiagnosisProfile	SDOHCCCondition	Values Differ
publisher	HL7 International - Cross-Group Projects	HL7 International - Patient Care WG	Values Differ
purpose
status	active	draft	Values Differ
title	US Core Condition Encounter Diagnosis Profile	SDOHCC Condition	Values Differ
type	Condition
url	http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition-encounter-diagnosis	http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-Condition	Values Differ
version	6.0.0-ballot	2.0.0	Values Differ

Structure

Name	L Flags	L Card.	L Type	L Description & Constraints	R Flags	R Card.	L Type	L Description & Constraints	Comments
Condition	C	0..*	Condition	Detailed information about conditions, problems or diagnoses	C	0..*	USCoreCondition	Detailed information about SDOH conditions, problems or diagnoses SDOH-Con-1: Can only have a max of one asserter.	Elements differ in short: 'Detailed information about conditions, problems or diagnoses' vs 'Detailed information about SDOH conditions, problems or diagnoses' Elements differ in definition: '\-' vs 'For representation of SDOH conditions.' Elements differ in comments: '\-' vs 'Many of the SDOHCC profiles reference one another. One flow supported by this IG is that QuestionnaireResponses result in Observations that can be used as evidence for Conditions that can lead to Goals, ServiceRequests and Procedures. However, alternatives paths (e.g., to arrive at SDOH Conditions) are also possible. One specific use for this profile is to represent a Health Concern that is either; 1) directly asserted based on the patient’s answer to a specific question from an SDOH screening questionnaire or 2) computed/generated based on the patient’s answers to multiple questions. The questions and answers from the screening questionnaire are also represented using SDC Questionnaire, SDC QuestionnaireResponse and SDOHCC Screening Response Observation.'
id	Σ	0..1	id	Logical id of this artifact	Σ	0..1	id	Logical id of this artifact
meta	Σ	0..1	Meta	Metadata about the resource	Σ	0..1	Meta	Metadata about the resource
implicitRules	?!Σ	0..1	uri	A set of rules under which this content was created	?!Σ	0..1	uri	A set of rules under which this content was created
language		0..1	code	Language of the resource content Binding: CommonLanguages (preferred): A human language. Additional Bindings Purpose AllLanguages Max Binding		0..1	code	Language of the resource content Binding: CommonLanguages (preferred): A human language. Additional Bindings Purpose AllLanguages Max Binding
text		0..1	Narrative	Text summary of the resource, for human interpretation		0..1	Narrative	Text summary of the resource, for human interpretation
contained		0..*	Resource	Contained, inline Resources		0..*	Resource	Contained, inline Resources
Slices for extension		0..*	Extension	Extension Slice: Unordered, Open by value:url		0..*	Extension	Extension Slice: Unordered, Open by value:url
modifierExtension	?!	0..*	Extension	Extensions that cannot be ignored	?!	0..*	Extension	Extensions that cannot be ignored
identifier	Σ	0..*	Identifier	External Ids for this condition	Σ	0..*	Identifier	External Ids for this condition
clinicalStatus	?!SΣC	0..1	CodeableConcept	active | recurrence | relapse | inactive | remission | resolved Binding: ConditionClinicalStatusCodes (required)	?!SΣC	0..1	CodeableConcept	active | recurrence | relapse | inactive | remission | resolved Binding: ConditionClinicalStatusCodes (required)
verificationStatus	?!SΣC	0..1	CodeableConcept	unconfirmed | provisional | differential | confirmed | refuted | entered-in-error Binding: ConditionVerificationStatus (required)	?!SΣC	0..1	CodeableConcept	unconfirmed | provisional | differential | confirmed | refuted | entered-in-error Binding: ConditionVerificationStatus (required)	Elements differ in comments: 'verificationStatus is not required. For example, when a patient has abdominal pain in the ED, there is not likely going to be a verification status. The data type is CodeableConcept because verificationStatus has some clinical judgment involved, such that there might need to be more specificity than the required FHIR value set allows. For example, a SNOMED coding might allow for additional specificity.' vs 'verificationStatus is not required. For example, when a patient complains of stress during a provider encounter, there is not likely going to be a verification status. The data type is CodeableConcept because verificationStatus has some clinical judgment involved, such that there might need to be more specificity than the required FHIR value set allows. For example, a SNOMED coding might allow for additional specificity. For SDOH conditions that are autogenerated based on a questionnaire response, the Condition.asserter is a “Device” AND Condition.Category should be "health-concern". In that case, Condition.verificationStatus should be "unconfirmed" and should be changed to “confirmed” only after review and concurrence by the provider and patient.'
Slices for category	S	1..*	CodeableConcept	category codes Slice: Unordered, Open by pattern:$this Binding: ConditionCategoryCodes (extensible): A category assigned to the condition.	SC	1..*	CodeableConcept	problem-list-item | encounter-diagnosis | health-concern Slice: Unordered, Open by value:$this Binding: US Core Condition Category Codes (extensible)	Elements differ in short: 'category codes' vs 'problem-list-item | encounter-diagnosis | health-concern'
severity		0..1	CodeableConcept	Subjective severity of condition Binding: Condition/DiagnosisSeverity (preferred): A subjective assessment of the severity of the condition as evaluated by the clinician.		0..1	CodeableConcept	Subjective severity of condition Binding: Condition/DiagnosisSeverity (preferred): A subjective assessment of the severity of the condition as evaluated by the clinician.
code	SΣ	1..1	CodeableConcept	Identification of the condition, problem or diagnosis Binding: US Core Condition Code (extensible): Valueset to describe the actual problem experienced by the patient	SΣ	1..1	CodeableConcept	Identification of the condition, problem or diagnosis Binding: US Core Condition Code (required)	Elements differ in requirements: '0..1 to account for primarily narrative only resources.' vs 'Code is required and must be selected from the bound value set.'
bodySite	Σ	0..*	CodeableConcept	Anatomical location, if relevant Binding: SNOMEDCTBodyStructures (example): Codes describing anatomical locations. May include laterality.	Σ	0..0			Element maximum cardinalities differ: '2147483647' vs '0'
subject	SΣ	1..1	Reference(US Core Patient Profile)	Who has the condition?	SΣ	1..1	Reference(US Core Patient Profile)	Who has the condition?	Elements differ in definition: 'Indicates the patient or group who the condition record is associated with.' vs 'Indicates the patient who the condition record is associated with.' Elements differ in requirements: 'Group is typically used for veterinary or public health use cases.' vs 'US Core Condition Profile restricts subject to patient.'
encounter	SΣ	0..1	Reference(US Core Encounter Profile)	Encounter created as part of	Σ	0..1	Reference(Encounter)	Encounter created as part of	Elements differ in definition for mustSupport: 'true' vs 'false'
onset[x]	SΣ	0..1	dateTime S, Age, Period, Range, string	Estimated or actual date, date-time, or age	SΣ	0..1	dateTime, Period	Estimated dateTime or Period	Elements differ in short: 'Estimated or actual date, date-time, or age' vs 'Estimated dateTime or Period' Elements differ in definition: 'Estimated or actual date or date-time the condition began, in the opinion of the clinician.' vs 'Estimated or actual dateTime or Period the condition began.' Elements differ in comments: 'Age is generally used when the patient reports an age at which the Condition began to occur.' vs 'For SDOH conditions that have their onset over an extended (or fuzzy) period (e.g., the past month), Condition.onset may use a lower precision representation (e.g., month/year or year) as opposed to a higher precision representation (e.g., year/month/date/hour/min).'
abatement[x]	SC	0..1	dateTime S, Age, Period, Range, string	When in resolution/remission	SC	0..1	dateTime, Period	When in resolution/remission	Elements differ in definition: 'The date or estimated date that the condition resolved or went into remission. This is called "abatement" because of the many overloaded connotations associated with "remission" or "resolution" - Conditions are never really resolved, but they can abate.' vs 'The estimated or actual dateTime or Period that the condition resolved or went into remission. This is called "abatement" because of the many overloaded connotations associated with "remission" or "resolution".' Elements differ in comments: 'There is no explicit distinction between resolution and remission because in many cases the distinction is not clear. Age is generally used when the patient reports an age at which the Condition abated. If there is no abatement element, it is unknown whether the condition has resolved or entered remission; applications and users should generally assume that the condition is still valid. When abatementString exists, it implies the condition is abated.' vs 'There is no explicit distinction between resolution and remission because in many cases the distinction is not clear. If there is no abatement element, it is unknown whether the condition has resolved or entered remission; applications and users should generally assume that the condition is still valid. When abatementString exists, it implies the condition is abated. For SDOH Conditions that have a fuzzy abatement period, a lower precision representation (e.g., month/year or year) may be used. However, for SDOH Conditions that end at a specific point in time (e.g., food insecurity may abate upon acquiring a new job or gaining eligibility to a food program) a higher precision representation (e.g., year/month/date) may also be used.'
recordedDate	SΣ	0..1	dateTime	Date record was first recorded	Σ	0..1	dateTime	Date record was first recorded	Elements differ in definition for mustSupport: 'true' vs 'false'
recorder	Σ	0..1	Reference(Practitioner | PractitionerRole | Patient | RelatedPerson)	Who recorded the condition	Σ	0..1	Reference(Practitioner | PractitionerRole)	Who recorded the condition
asserter	Σ	0..1	Reference(Practitioner | PractitionerRole | Patient | RelatedPerson)	Person who asserts this condition	SΣC	0..1	Reference(RelatedPerson | US Core Patient Profile | US Core Practitioner Profile | US Core PractitionerRole Profile)	Person or device that asserts this condition	Elements differ in short: 'Person who asserts this condition' vs 'Person or device that asserts this condition' Elements differ in definition: 'Individual who is making the condition statement.' vs 'The individual or device making the condition statement.' Elements differ in definition for mustSupport: 'false' vs 'true' Type Mismatch: Reference([CanonicalType[http://hl7.org/fhir/StructureDefinition/Practitioner], CanonicalType[http://hl7.org/fhir/StructureDefinition/PractitionerRole], CanonicalType[http://hl7.org/fhir/StructureDefinition/Patient], CanonicalType[http://hl7.org/fhir/StructureDefinition/RelatedPerson]]) vs Reference([CanonicalType[http://hl7.org/fhir/StructureDefinition/RelatedPerson], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-practitioner], CanonicalType[http://hl7.org/fhir/us/core/StructureDefinition/us-core-practitionerrole]])
stage	C	0..*	BackboneElement	Stage/grade, usually assessed formally	C	0..0			Element maximum cardinalities differ: '2147483647' vs '0'
id		0..1	string	Unique id for inter-element referencing		0..1	string	Unique id for inter-element referencing
extension		0..*	Extension	Additional content defined by implementations		0..*	Extension	Additional content defined by implementations
modifierExtension	?!Σ	0..*	Extension	Extensions that cannot be ignored even if unrecognized	?!Σ	0..*	Extension	Extensions that cannot be ignored even if unrecognized
summary	C	0..1	CodeableConcept	Simple summary (disease specific) Binding: ConditionStage (example): Codes describing condition stages (e.g. Cancer stages).	C	0..1	CodeableConcept	Simple summary (disease specific) Binding: ConditionStage (example): Codes describing condition stages (e.g. Cancer stages).
assessment	C	0..*	Reference(ClinicalImpression | DiagnosticReport | Observation)	Formal record of assessment	C	0..*	Reference(ClinicalImpression | DiagnosticReport | Observation)	Formal record of assessment
type		0..1	CodeableConcept	Kind of staging Binding: ConditionStageType (example): Codes describing the kind of condition staging (e.g. clinical or pathological).		0..1	CodeableConcept	Kind of staging Binding: ConditionStageType (example): Codes describing the kind of condition staging (e.g. clinical or pathological).
evidence	C	0..*	BackboneElement	Supporting evidence	SC	0..*	BackboneElement	Supporting evidence	Elements differ in definition for mustSupport: 'false' vs 'true'
id		0..1	string	Unique id for inter-element referencing		0..1	string	Unique id for inter-element referencing
extension		0..*	Extension	Additional content defined by implementations		0..*	Extension	Additional content defined by implementations
modifierExtension	?!Σ	0..*	Extension	Extensions that cannot be ignored even if unrecognized	?!Σ	0..*	Extension	Extensions that cannot be ignored even if unrecognized
code	ΣC	0..*	CodeableConcept	Manifestation/symptom Binding: ManifestationAndSymptomCodes (example): Codes that describe the manifestation or symptoms of a condition.	ΣC	0..*	CodeableConcept	Manifestation/symptom Binding: ManifestationAndSymptomCodes (example): Codes that describe the manifestation or symptoms of a condition.
detail	ΣC	0..*	Reference(Resource)	Supporting information found elsewhere	ΣC	0..*	Reference(Resource)	Supporting information found elsewhere Slice: Unordered, Open by profile:resolve()
note		0..*	Annotation	Additional information about the Condition		0..*	Annotation	Additional information about the Condition
Documentation for this format