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

Left:US Core Condition Encounter Diagnosis Profile (http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition-encounter-diagnosis)
Right:SDOHCC Condition (http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-Condition)

Messages

ErrorStructureDefinition.urlValues for url differ: 'http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition-encounter-diagnosis' vs 'http://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-Condition'
ErrorStructureDefinition.versionValues for version differ: '6.1.0' vs '2.1.0'
InformationStructureDefinition.nameValues for name differ: 'USCoreConditionEncounterDiagnosisProfile' vs 'SDOHCCCondition'
InformationStructureDefinition.titleValues for title differ: 'US Core Condition Encounter Diagnosis Profile' vs 'SDOHCC Condition'
InformationStructureDefinition.statusValues for status differ: 'active' vs 'draft'
InformationStructureDefinition.dateValues for date differ: '2022-04-20' vs '2023-07-27T20:42:33+00:00'
InformationStructureDefinition.publisherValues for publisher differ: 'HL7 International - Cross-Group Projects' vs 'HL7 International Patient Care WG'
ErrorStructureDefinition.baseDefinitionValues for baseDefinition differ: 'http://hl7.org/fhir/StructureDefinition/Condition' vs 'http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition'
WarningConditionElements differ in short: 'Detailed information about conditions, problems or diagnoses' vs 'Detailed information about SDOH conditions, problems or diagnoses'
WarningConditionElements differ in definition: '\-' vs 'For representation of SDOH conditions.'
WarningConditionElements 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.'
WarningCondition.clinicalStatusElements differ in short: '(USCDI) active | recurrence | relapse | inactive | remission | resolved' vs 'active | recurrence | relapse | inactive | remission | resolved'
WarningCondition.verificationStatusElements differ in short: '(USCDI) unconfirmed | provisional | differential | confirmed | refuted | entered-in-error' vs 'unconfirmed | provisional | differential | confirmed | refuted | entered-in-error'
WarningCondition.verificationStatusElements 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.'
WarningCondition.categoryElements differ in short: '(USCDI) category codes' vs 'problem-list-item | encounter-diagnosis | health-concern'
WarningCondition.codeElements differ in short: '(USCDI) Identification of the condition, problem or diagnosis' vs 'Identification of the condition, problem or diagnosis'
WarningCondition.codeElements 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.'
InformationCondition.bodySiteElement maximum cardinalities differ: '2147483647' vs '0'
WarningCondition.subjectElements differ in short: '(USCDI) Who has the condition?' vs 'Who has the condition?'
WarningCondition.subjectElements 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.'
WarningCondition.subjectElements differ in requirements: 'Group is typically used for veterinary or public health use cases.' vs 'US Core Condition Profile restricts subject to patient.'
WarningCondition.encounterElements differ in short: '(USCDI) Encounter created as part of' vs 'Encounter created as part of'
WarningCondition.encounterElements differ in definition for mustSupport: 'true' vs 'false'
WarningCondition.onset[x]Elements differ in short: '(USCDI) Estimated or actual date, date-time, or age' vs 'Estimated dateTime or Period'
WarningCondition.onset[x]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.'
WarningCondition.onset[x]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).'
WarningCondition.abatement[x]Elements differ in short: '(USCDI) When in resolution/remission' vs 'When in resolution/remission'
WarningCondition.abatement[x]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'.'
WarningCondition.abatement[x]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.'
WarningCondition.recordedDateElements differ in short: '(USCDI) Date record was first recorded' vs 'Date record was first recorded'
WarningCondition.recordedDateElements differ in definition for mustSupport: 'true' vs 'false'
WarningCondition.asserterElements differ in short: 'Person who asserts this condition' vs 'Person or device that asserts this condition'
WarningCondition.asserterElements differ in definition: 'Individual who is making the condition statement.' vs 'The individual or device making the condition statement.'
WarningCondition.asserterElements differ in definition for mustSupport: 'false' vs 'true'
ErrorCondition.asserterType 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]])
InformationCondition.stageElement maximum cardinalities differ: '2147483647' vs '0'
WarningCondition.evidenceElements differ in definition for mustSupport: 'false' vs 'true'

Metadata

NameValueComments
.abstractfalse
    .baseDefinitionhttp://hl7.org/fhir/StructureDefinition/Conditionhttp://hl7.org/fhir/us/core/StructureDefinition/us-core-condition
    • Values Differ
    .copyrightUsed 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'
    .date2022-04-202023-07-27T20:42:33+00:00
    • Values Differ
    .descriptionThe 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 and constrains the way the elements are used 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
    .experimentalfalse
    • Removed the item 'false'
    .fhirVersion4.0.1
      .jurisdiction
        ..jurisdiction[0]urn:iso:std:iso:3166#US
          .kindresource
            .nameUSCoreConditionEncounterDiagnosisProfileSDOHCCCondition
            • Values Differ
            .publisherHL7 International - Cross-Group ProjectsHL7 International Patient Care WG
            • Values Differ
            .purpose
              .statusactivedraft
              • Values Differ
              .titleUS Core Condition Encounter Diagnosis ProfileSDOHCC Condition
              • Values Differ
              .typeCondition
                .urlhttp://hl7.org/fhir/us/core/StructureDefinition/us-core-condition-encounter-diagnosishttp://hl7.org/fhir/us/sdoh-clinicalcare/StructureDefinition/SDOHCC-Condition
                • Values Differ
                .version6.1.02.1.0
                • Values Differ

                Structure

                NameL FlagsL Card.L TypeL Description & ConstraintsR FlagsR Card.L TypeL Description & ConstraintsCommentsdoco
                .. Condition C0..*ConditionDetailed information about conditions, problems or diagnoses
                C0..*USCoreConditionDetailed 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..1idLogical id of this artifactΣ0..1idLogical id of this artifact
                  ... meta Σ0..1MetaMetadata about the resourceΣ0..1MetaMetadata about the resource
                    ... implicitRules ?!Σ0..1uriA set of rules under which this content was created?!Σ0..1uriA set of rules under which this content was created
                      ... text 0..1NarrativeText summary of the resource, for human interpretation0..1NarrativeText summary of the resource, for human interpretation
                        ... contained 0..*ResourceContained, inline Resources
                        0..*ResourceContained, inline Resources
                          ... Slices for extension 0..*ExtensionExtension
                          Slice: Unordered, Open by value:url
                          0..*ExtensionExtension
                          Slice: Unordered, Open by value:url
                            ... modifierExtension ?!0..*ExtensionExtensions that cannot be ignored
                            ?!0..*ExtensionExtensions that cannot be ignored
                              ... identifier Σ0..*IdentifierExternal Ids for this condition
                              Σ0..*IdentifierExternal Ids for this condition
                                ... clinicalStatus ?!SΣC0..1CodeableConcept(USCDI) active | recurrence | relapse | inactive | remission | resolved
                                Binding: ?? (required)
                                ?!SΣC0..1CodeableConceptactive | recurrence | relapse | inactive | remission | resolved
                                Binding: ?? (required)
                                • Elements differ in short: '(USCDI) active | recurrence | relapse | inactive | remission | resolved' vs 'active | recurrence | relapse | inactive | remission | resolved'
                                ... verificationStatus ?!SΣC0..1CodeableConcept(USCDI) unconfirmed | provisional | differential | confirmed | refuted | entered-in-error
                                Binding: ?? (required)
                                ?!SΣC0..1CodeableConceptunconfirmed | provisional | differential | confirmed | refuted | entered-in-error
                                Binding: ?? (required)
                                • Elements differ in short: '(USCDI) unconfirmed | provisional | differential | confirmed | refuted | entered-in-error' vs 'unconfirmed | provisional | differential | confirmed | refuted | entered-in-error'
                                • 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 S1..*CodeableConcept(USCDI) category codes
                                Slice: Unordered, Open by pattern:$this
                                Binding: ?? (extensible): A category assigned to the condition.


                                SC1..*CodeableConceptproblem-list-item | encounter-diagnosis | health-concern
                                Slice: Unordered, Open by value:$this
                                Binding: ?? (extensible)
                                • Elements differ in short: '(USCDI) category codes' vs 'problem-list-item | encounter-diagnosis | health-concern'
                                ... severity 0..1CodeableConceptSubjective severity of condition
                                Binding: ?? (preferred): A subjective assessment of the severity of the condition as evaluated by the clinician.

                                0..1CodeableConceptSubjective severity of condition
                                Binding: ?? (preferred): A subjective assessment of the severity of the condition as evaluated by the clinician.

                                  ... code SΣ1..1CodeableConcept(USCDI) Identification of the condition, problem or diagnosis
                                  Binding: ?? (extensible): Valueset to describe the actual problem experienced by the patient

                                  SΣ1..1CodeableConceptIdentification of the condition, problem or diagnosis
                                  Binding: ?? (required): Valueset to describe the actual problem experienced by the patient

                                  • Elements differ in short: '(USCDI) Identification of the condition, problem or diagnosis' vs 'Identification of the condition, problem or diagnosis'
                                  • 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..*CodeableConceptAnatomical location, if relevant
                                  Binding: ?? (example): Codes describing anatomical locations. May include laterality.


                                  Σ0..0
                                  • Element maximum cardinalities differ: '2147483647' vs '0'
                                  ... subject SΣ1..1Reference(US Core Patient Profile)(USCDI) Who has the condition?SΣ1..1Reference(US Core Patient Profile)Who has the condition?
                                  • Elements differ in short: '(USCDI) Who has the condition?' vs '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..1Reference(US Core Encounter Profile)(USCDI) Encounter created as part ofΣ0..1Reference(Encounter)Encounter created as part of
                                  • Elements differ in short: '(USCDI) Encounter created as part of' vs 'Encounter created as part of'
                                  • Elements differ in definition for mustSupport: 'true' vs 'false'
                                  ... onset[x] SΣ0..1dateTime S, Age, Period, Range, string(USCDI) Estimated or actual date, date-time, or ageSΣ0..1dateTime, PeriodEstimated dateTime or Period
                                  • Elements differ in short: '(USCDI) 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] SC0..1dateTime S, Age, Period, Range, string(USCDI) When in resolution/remissionSC0..1dateTime, PeriodWhen in resolution/remission
                                  • Elements differ in short: '(USCDI) When in resolution/remission' vs '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..1dateTime(USCDI) Date record was first recordedΣ0..1dateTimeDate record was first recorded
                                  • Elements differ in short: '(USCDI) Date record was first recorded' vs 'Date record was first recorded'
                                  • Elements differ in definition for mustSupport: 'true' vs 'false'
                                  ... recorder Σ0..1Reference(Practitioner | PractitionerRole | Patient | RelatedPerson)Who recorded the conditionΣ0..1Reference(Practitioner | PractitionerRole)Who recorded the condition
                                    ... asserter Σ0..1Reference(Practitioner | PractitionerRole | Patient | RelatedPerson)Person who asserts this conditionSΣC0..1Reference(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 C0..*BackboneElementStage/grade, usually assessed formally
                                    C0..0
                                    • Element maximum cardinalities differ: '2147483647' vs '0'
                                    .... id 0..1stringUnique id for inter-element referencing0..1stringUnique id for inter-element referencing
                                      .... extension 0..*ExtensionAdditional content defined by implementations
                                      0..*ExtensionAdditional content defined by implementations
                                        .... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
                                        ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
                                          .... summary C0..1CodeableConceptSimple summary (disease specific)
                                          Binding: ?? (example): Codes describing condition stages (e.g. Cancer stages).

                                          C0..1CodeableConceptSimple summary (disease specific)
                                          Binding: ?? (example): Codes describing condition stages (e.g. Cancer stages).

                                            .... assessment C0..*Reference(ClinicalImpression | DiagnosticReport | Observation)Formal record of assessment
                                            C0..*Reference(ClinicalImpression | DiagnosticReport | Observation)Formal record of assessment
                                              .... type 0..1CodeableConceptKind of staging
                                              Binding: ?? (example): Codes describing the kind of condition staging (e.g. clinical or pathological).

                                              0..1CodeableConceptKind of staging
                                              Binding: ?? (example): Codes describing the kind of condition staging (e.g. clinical or pathological).

                                                ... evidence C0..*BackboneElementSupporting evidence
                                                SC0..*BackboneElementSupporting evidence
                                                • Elements differ in definition for mustSupport: 'false' vs 'true'
                                                .... id 0..1stringUnique id for inter-element referencing0..1stringUnique id for inter-element referencing
                                                  .... extension 0..*ExtensionAdditional content defined by implementations
                                                  0..*ExtensionAdditional content defined by implementations
                                                    .... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
                                                    ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
                                                      .... code ΣC0..*CodeableConceptManifestation/symptom
                                                      Binding: ?? (example): Codes that describe the manifestation or symptoms of a condition.


                                                      ΣC0..*CodeableConceptManifestation/symptom
                                                      Binding: ?? (example): Codes that describe the manifestation or symptoms of a condition.


                                                        .... detail ΣC0..*Reference(Resource)Supporting information found elsewhere
                                                        ΣC0..*Reference(Resource)Supporting information found elsewhere
                                                        Slice: Unordered, Open by profile:resolve()
                                                          ... note 0..*AnnotationAdditional information about the Condition
                                                          0..*AnnotationAdditional information about the Condition

                                                            doco Documentation for this format