Page tree
Skip to end of metadata
Go to start of metadata
FHIR   Element 3 STU DefinitionBinding Strengths 3 (STU)Questions/Proposal   to the groupComments  

clinicalStatus
    The clinical status of the condition.
   

Comments: This element is labeled as a modifier because the  status contains codes that mark the condition as not currently valid or   of concern.

Required
    [0..1]
   
    HL7
    hl7.org/fhir/condition-clinical
Add guidance this information   can be captured in the condition.code as the clinical condition: if the   ClinicalStatus can be represented from the codeableConcept Condition.code, it   should not be entered here.
   
    Ex:  Asthma - currently active   (finding)
    Ex:  Inactive thyroid disease   (finding)
    Ex:  Recurrent anxiety   (finding)
    Ex:  Diabetes resolved   (finding) 
   
 
verificationStatus
    The verification status to support the clinical status  of the  condition.
Required
    [0..1]
   
    hl7.org/fhir/ValueSet/condition-ver-status
Should this  element include 'suspected' 
  Add an example  when a Condition is provisional or differential and then becomes confimed 

Category
    A category assigned to the condition.
   

Comments: The categorization is often highly contextual   and may appear poorly differentiated or not very useful in other contexts.

Example
    [0..*]
   
    hl7.org/fhir/ValueSet/condition-category
This element   seems to allow categorisation of types of information found in the resource,   such as: symptom, sign, diagnosis, event, complaint, etc. Is it used for   other purposes? 
  Should there be   guidance to use the list resource with this element? 

Severity
    A subjective assessment of the severity of the   condition as evaluated by the clinician.

Comments:  Coding of the severity with a terminology is preferred, where possible.

Preferred
    [0..1]
   
    Include these codes as defined in http://snomed.info/sct
   
    Severe, Moderate, Mild
Change binding the proposed   intensional definition for this value set: < 272141005 |Severities| 

 Add guidance on validation of   content that is a normal condition, to avoid inappropriate information, e.g.   pregnancy. 
  Add guidance this information   can be captured in the condition.code as the clinical condition: if the   Severity can be represented from the Condition.code codeableConcept, it   should not be entered here.
   
    Ex:  Fatal infectious mononucleosis   (disorder)
    Ex:  Mild gingivitis (disorder)
    Ex:  Moderate head injury   (disorder)
    Ex:  Severe myopia (disorder)   
 

Code

Identification of the condition, problem or diagnosis.

Example
    [0..1]
   
    Include codes from http://snomed.info/sct    where concept is-a 404684003 (Clinical   finding)
     
    Include these codes as defined in http://snomed.info/sct
     
    160245001
    No current problems or disability
   
Change binding strength to Preferred so SNOMED CT is the   Clinical Terminology of choice for this data element, and change binding the   proposed intensional definition for this value set:
    (< 404684003 |Clinical finding|
     INCLUDE << 420134006   |Propensity to adverse reactions|
     INCLUDE << 473010000   |Hypersensitivity condition|
     INCLUDE << 79899007 |Drug   interaction|
    MINUS << 69449002 |Drug action|
    MINUS << 441742003 |Evaluation finding|
    MINUS << 307824009 |Administrative status|
    MINUS << 385356007 |Tumor stage finding|
    MINUS << 80631005 |Clinical stage finding| )
    OR < 413350009 |Finding with explicit context|
    OR < 272379006 |Event|

Corrected ECL expression

((
< 404684003 |Clinical finding|
   OR << 420134006   |Propensity to adverse reactions|
   OR << 473010000   |Hypersensitivity condition|
   OR << 79899007 |Drug   interaction|
) MINUS (
<< 69449002 |Drug action|
OR << 441742003 |Evaluation finding|
   OR << 307824009 |Administrative status|
   OR << 385356007 |Tumor stage finding|
   OR << 80631005 |Clinical stage finding|
))
OR < 413350009 |Finding with explicit context|
OR < 272379006 |Event|

  There is a proposed change to   the Scope and Usage of this resource to better reflect the in   scope elements for this resource.  
  Add guidance when the   condition.code may include the Severity, the ClinicalStatus even the   verificationStatus (confirmed) as the clinical condition: if the   Condition.code includes the severity and/or the clinical status and/or the   verification status these elements should not be captured to avoid duplicated   information.
     
    Ex.: Tuberculoma of spinal cord confirmed (disorder)
    Ex.: Suspected fetal abnormality affecting management of mother (disorder)
 
  There is a proposed change to   the Scope and Usage of this resource to better reflect the in   scope elements for this resource.
   
    Suggest that the ‘Allergic to X’ be recorded in the condition.code when   this is not a reason for an encounter. Use both the Condition and the   AllergyIntolerance resources when there is an acute state.
 
  Add an example for when the   Condition.code is not required. 

bodySite
    The anatomical location where this condition manifests   itself.

Comments: Only used if not implicit in code   found in Condition.code. If the use case requires attributes from the   BodySite resource (e.g. to identify and track separately) then use the   standard extension body-site-instance. May be a summary code, or a reference   to a very precise definition of the location, or both.

Example
    [0..*]
   
    Include codes from http://snomed.info/sct     where concept is-a 442083009 (Anatomical or   acquired body structure)
   
The binding strength should be   changed for Preferred [0..*] 
  In the examples f202 and f203,   we can see a major discrepancy between the Condition.code and the BodySite.   Should there be guidance when this element is used and how should data be   consolidated for analysis and retrieval? 
stage.summary
    A simple summary of the stage such as "Stage   3". The determination of the stage is disease-specific.
Example
    [0..1]
    Include codes from http://snomed.info/sct where concept is-a   385356007
    (Tumour stage finding)
   
The binding strength should be   changed for Preferred [0..*] 
  The Content Logical Definition   does not seem aligned on the Expansion shown on the page. Add the following   to the Content Logical Definition:
    http://snomed.info/sct where concept is-a     80631005 Clinical stage finding (finding)
 
  Add a «Comment» similar to the   Severity element.
    Comments: Coding of the Stage with a terminology is preferred, where   possible.
 
  Add guidance this information   can be captured in the condition.code as the clinical condition: if the   Condition.Stage.Summary can be represented from the codeableConcept   Condition.code, it should not be entered here.
   
    Ex:  Pressure ulcer stage 3   (disorder)
    Ex:  Systolic heart failure stage D   (disorder)
    Ex:  Mammography assessment (Category   1) - Negative (finding)
    Ex:  Stage 2 pulmonary sarcoidosis   (disorder)
 
  Is there a dependency between   this element and the verificationStatus? 
  Please review the Example f204   whcih does not seem to comply to the definition of this element.  
stage.assessment
    Reference to a formal record of the evidence on which   the staging assessment is based.
There is no Terminology binding currently
    [0..*]
Is there a dependency between   this element and the verificationStatus? 
evidence.code
    A manifestation or symptom that led to the recording of   this condition.
Example
    [0..*]
   
    Include codes from http://snomed.info/sct     where concept is-a 404684003 (Clinical   finding)
   
Change binding strength to Preferred so SNOMED CT is the   Clinical Terminology of choice for this data element and change binding to   the same as for the Condition.code unless there is a rationale for the   bindings to be different, knowinf that the SNOMED CT clinical finding   hierarchy does not have specific sub-hierarchies that are signs or symptoms. Will include the values from the Observation Resource plus items from the Condition Resource.
  Provide guidance for when to use   the evidence.code vs the Observation Resource
  Please review the Example f201,   f002 and f003 which do not seem to comply to the definition of this   element.  
evidence.detail
    Links to other relevant information, including   pathology reports.
There is no Terminology binding currently
    [0..*]
Is there a dependency between   this element and the verificationStatus? The detail field here allows a reference to be made to 0..* Observation Resources.
  How are the other data element   adjusting when a value is populated in this field? Are there validation on   all associated fields? Refer to example f202-malignancy.
    Refer to example f203-sepsis. In this use case, if the report is only   sepsis, how and will the code be validated against that information?
 



 
  • No labels

8 Comments

  1. Here's the PowerPoint slide I spoke to in last night's ZOOM meeting, showing the full Condition resource as it is currently defined in FHIR 3.0.1.

    Highlighted are the five elements that obviously directly expect a terminology binding (e.g. most obviously Condition.code), plus two others: although neither Condition.clinicalStatus nor  Condition.subject expect a terminology binding themselves, they express semantics that overlaps with what may populate the other five elements if SNOMED is used for the terminology.

    Finally, the example value 'problem-list-item' for Condition.category is also highlighted : if the full range of clinical phenomena that we currently know to be flagged in real EPRs as part of real patients' Problem Lists must be possible to pass as instances of a Condition resource  in order that such Problem Lists may be interoperated when care is transferred, then this implementation choice has significant implications for the required scope of the binding for Condition.code. Broadly, it would need to go significantly beyond either the example FHIR binding:

    <<404684003|Clinical finding| OR 160245001|No current problems or disability|

    ...or Linda Bird's suggested more precise binding from 2016:

    (<404684003 |Clinical finding|
    MINUS
    (<<420134006 |Propensity to adverse reactions| OR <<473010000 |Hypersensitivity condition| OR <<79899007 |Drug interaction| OR <<69449002 |Drug action|
    OR <<
    441742003 |Evaluation finding| OR <<307824009 |Administrative status| OR <<385356007 |Tumor stage finding|))

    OR

    (<413350009 |Finding with explicit context|:246090004 |Associated finding| =
    (<
    404684003 |Clinical finding| MINUS (<<420134006 |Propensity to adverse reactions| OR <<473010000 |Hypersensitivity condition|
    OR <<
    79899007 |Drug interaction| OR <<69449002 |Drug action| OR <<441742003 |Evaluation finding| OR <<307824009 |Administrative status| OR <<385356007 |Tumor stage finding|))

    NB Jury is still out on whether allergy and ADR codes should be excluded from a Condition resource binding on grounds that these EPR items should always be shipped instead as instances of a FHIR AllergyIntolerance resource

    ...because it would also need to include e.g.:

    <14679004|Occupation|
    OR <60134006|Life style|
    OR <82996008|Social status|
    OR <108334009|Religion AND/OR philosophy|
    OR <272379006|Event|
    OR <
    71388002|Procedure|
    OR
    <129125009|Procedure with explicit context|
    OR <
    276445008|A/N risk factors|
    OR <182985004|Response to treatment|
    OR <
    57177007|Family history with explicit context|

    ...since we know that codes from all of the above subhierarchies are found in real world Problem Lists, or in their close cousin the Patient Summary. But even that extended binding scope would still exclude passing an observable-plus-a-value as a 'Problem List' item, such as e.g. 718087004|QRISK2 cardiovascular disease 10 year risk score| = 23.3%.

  2. Also for interest here's a document written earlier this year to help inform the UK CareConnect community on the 'Problem List' issue outlined above:

    In order to further understand the scope of the 'Problem List' interoperation issue, each system suppliers participating in the CareConnect process submitted a brief outline of the 'Problem List' curation functionality and semantic scope offered within their systems. These are summarised in this document:

  3. Rob Hausam mentioned Argonaut, and their design decision to use the DSTU2 Condition resource to ship 'problems'.

    This appears to be still the case: their current profiling of the Condition resource strips it down to just 5 elements, wherein Condition.category is a mandatory element with a preferred valueset comprised of only either 'problem' or 'health-concern'.

    Their binding for Condition.code is extensible:

    (<404684003 |Clinical finding| OR <243796009|Situation with explicit context|)

    ...but looks obviously inconsistent because it lets in <129125009|Procedure with explicit context| whilst excluding <71388002|Procedure|.

    It also excludes many of the codes within the narrative clinical scope statement for the resource as a whole:

    Use to record detailed information about conditions, problems or diagnoses recognized by a clinician. There are many uses including: recording a diagnosis during an encounter; populating a problem list or a summary statement, such as a discharge summary

  4. FWIW, the range CIMI is using for Assertion is only 404684003 |Clinical finding. The context information (e.g. presence/absence, family member, etc.) are separate attributes in the logical model.

  5. By way of testing what effect various possible terminology bindings for the Condition resource might have on the future interoperability of Problem Lists - at least, as these exist in UK primary care - I've been looking at an old corpus I've got in which the coded problem lists of about 1900 real patients are listed. The corpus documents 13368 coded problems, involving 2209 different codes. Semantically, they're a very mixed bag, with some inevitable miscoding:

    SEMANTIC TYPEPROBLEMS
    (disorder)5202
    (finding)2846
    (situation:finding)2088
    (procedure)2086
    (observable entity)530
    (situation:procedure)271
    (regime/therapy)127
    (situation:family history)70
    (morphologic abnormality)28
    (event)25
    (body structure)24
    (record artifact)20
    (environment)19
    (physical object)14
    (situation:other)7
    (qualifier value)6
    (assessment scale)1
    (navigational concept)1
    (occupation)1
    (organism)1
    (person)1


    Within this corpus, a binding to e.g.

    <404684003 |Clinical finding| OR <413350009|Finding with explicit context (situation)|

    ..excludes 10,201 items (24%) of the clinical Problem List payload, including:

    182 instances of 268565007 Adult health examination
    78 instances of 184305005 Cause of death
    72 instances of 270425006 Letter from specialist
    69 instances of 713019007 New patient screening done
    66 instances of 38102005 Excision of gallbladder
    59 instances of 185599003 Cervical smear - 1st call
    58 instances of 80146002 Excision of appendix
    57 instances of 265371001 Diagnostic fibreoptic endoscopic examination of upper gastrointestinal tract
    56 instances of 161800001 H/O: hysterectomy
    55 instances of 11401008 Dilation and curettage of uterus
    54 instances of 267020005 H/O: tubal ligation
    40 instances of 1022441000000101 FBC - full blood count
    37 instances of 90199006 Transurethral prostatectomy
    35 instances of 1000971000000107 Urea and electrolytes level
    35 instances of 266752005 Trauma self-referral
    33 instances of 1003181000000102 Urine test for glucose
    31 instances of 1031081000000108 Liver function tests
    31 instances of 170742000 Diabetic monitoring
    30 instances of 1027131000000103 Thyroid hormone tests
    30 instances of 170757007 Fundoscopy - diabetic check

    A more refined binding e.g. adding:

    MINUS (<<420134006 |Propensity to adverse reactions| OR <<473010000 |Hypersensitivity condition| OR <<79899007 |Drug interaction| OR <<69449002 |Drug action| OR <<441742003 |Evaluation finding| OR <<307824009 |Administrative status| OR <<385356007 |Tumor stage finding|))

    ...excludes a further 12% of the payload, including:

    919 instances of 184229000 Notes summary on computer
    107 instances of 184239006 Repeat prescription card checked/updated
    60 instances of 268542002 Ca cervix screening - not attended
    51 instances of 170552004 Outpatients last attended
    31 instances of 61582004 Allergic rhinitis
    26 instances of 167261002 Urine glucose test negative
    21 instances of 167273002 Urine protein test negative
    19 instances of 87522002 Iron deficiency anaemia
    18 instances of 9014002 Psoriasis
    17 instances of 21719001 Allergic rhinitis due to pollens
    14 instances of 305599003 Under care of podiatrist
    14 instances of 91936005 Allergy to penicillin
    14 instances of 300994001 Registered partially sighted
    13 instances of 275807006 Finding of red blood cell staining
    12 instances of 170551006 Last hospital inpatient
    11 instances of 84027009 Pernicious anaemia
    10 instances of 416098002 Drug allergy
    9 instances of 271737000 Anemia
    9 instances of 389145006 Allergic atopic asthma
    7 instances of 314471005 Minor surgery done

  6. Following the working group meeting this evening, the current candidate binding was agreed to be too restrictive: the testing described above reveals that the exclusion clause <<473010000 |Hypersensitivity condition| would have incorrectly rendered certain immune-mediated conditions (e.g. Psoriasis) as outside the Condition resource scope. It was agreed to replace that single exclusion clause with two more precise constraints (shown in brown below).

    The revised candidate binding for Condition.code is therefore:

    (<404684003 |Clinical finding|
    MINUS (<<418038007|Propensity to adverse reactions to substance (disorder)|
    OR <<418634005|Allergic reaction caused by substance (disorder)| OR <<609406000|Pseudoallergic reaction (disorder)|
    OR <<79899007 |Drug interaction| OR <<69449002 |Drug action|
    OR <<441742003 |Evaluation finding| OR <<307824009 |Administrative status| OR <<385356007 |Tumor stage finding|))
    OR
    (<413350009 |Finding with explicit context|:246090004 |Associated finding| =
     (<404684003 |Clinical finding| MINUS (<<418038007|Propensity to adverse reactions to substance (disorder)|
              OR <<418634005|Allergic reaction caused by substance (disorder)| OR <<609406000|Pseudoallergic reaction (disorder)|
              OR <<79899007 |Drug interaction| OR <<69449002 |Drug action|
              OR <<441742003 |Evaluation finding| OR <<307824009 |Administrative status| OR <<385356007 |Tumor stage finding|))

    [Note: although <<419199007|Allergy to substance (disorder)| and <<609397002|Pseudoallergy to substance (disorder)|
    were also discussed in the meeting, they do not need to be listed as discrete exclusion clauses because they were in fact
    already implied by the existing clause <<418038007|Propensity to adverse reactions to substance (disorder)| ]

    The group would welcome further testing of this revised candidate binding against other corpora of real world coded conditions, or order to test whether it either remains too restrictive, or has become too permissive (e.g. by now admitting volumes of allergy record data that should properly be diverted to the AllergyIntolerance resource.)

  7. The issue seems to be excluding hypersensitivity condition would result in some immune disorders currently classified under hypersensitivity that are typically not thought of as hypersensitivity/allergy/intolerance i.e psoriasis. This is due to the inclusion of the Gell and Coombs classification (609407009 |Immune hypersensitivity reaction by mechanism (disorder)| and 427439005 |Immune hypersensitivity disorder by mechanism (disorder)|) under hypersensitivity condition. One workaround would be to restrict the definition of hypersensitivity to only include causation by external agents and move 609407009 and 427439005 under 414029004 |Disorder of immune function (disorder)| while renaming these as Immune disorder/reaction by mechanism. In the revised hypersensitivity model, allergy and autoimmune disease will classify under Disorder of immune function but hypersensitivity will not. Allergic disorders and reactions will be subsumed by both hypersensitivity condition and disorder of immune function. Below is an excerpt from a response I received from the preeminent immunologist, Dr. SGO Johansen who was the lead author of the WAO/EAAACI hypersensitivity/allergy terminology, regarding the definition of hypersensitivity: 

    “I do not see any problem with overlap between allergy and
    autoimmunity. If you do, perhaps you would consider adding the word "external" or something like it to the definition of hypersensitivity. ..."signs initiated by exposure to a defined external stimulus...".