| FHIR Element 3 STU Definition | Binding Strengths 3 (STU) | Questions/Proposal to the group | Comments |
|---|---|---|---|
clinicalStatus 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 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 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 |
| 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 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? | |||
Overview
Content Tools
Apps
8 Comments
Abdul Rauf
Interesting ..
Jeremy Rogers
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%.
Jeremy Rogers
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:
Jeremy Rogers
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
Susan Matney
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.
Jeremy Rogers
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:
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
Jeremy Rogers
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.)
Bruce Goldberg
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...".