Careset Problem V1.3

[bdc-ehealth]

@annenerenhausen

Careset Problem V1.3.docx

[bdc-ehealth]

The logical model based on this document can be reviewed on: https://build.fhir.org/ig/hl7-be/core-clinical/branches/issue-22/

[HenkLacour]

Hello

We noticed some differences between the visual diagram (page 6 in Careset Problem V1.3.docx) on the one hand, and the logical model description (BeModelProblem) on the other hand.

Here are our remarks concerning cardinality:

• For References ‘Problem(cause)’, acte medical (casue) and ‘mediciation’, the diagram has cardinality 0..n, while BeModelProblem says 1..1. (this should be 0..n in BeModelProblem?)
• Category has cardinality 1..1 in diagram, but 0..1 in BeModelProblem
• Clinicalstatus has cardinality 0..1 in diagram, but 1..1 in BeModelProblem
• The field Identifier is mandatory in the logical model as well as in the diagram – however it is optional in de resource profile BeProblem (0..1). Is that difference logical model versus profile on purpose?

Other remarks:

• Performer Exists in the diagram but not in BEModelProblem
• Recorder exists in BeModelProblem (and is mandatory, 1..1), but does not exists in diagram above
• Asserter exists in BeModelProblem, but does not exists in the diagram above

Best regards,
Henk Lacour

SHIFT Project

[bdc-ehealth]

@annenerenhausen

@[email protected] requests the Dutch version of this document.

[bdc-ehealth]

@HenkLacour , @annenerenhausen

the logical model is based on the table (2.4) in the document. There seem to be internal inconsistencies in the document between the diagrams and the textual information. @annenerenhausen (RIZIV/INAMI) will have to modify the document.

[FilipTNH]

Regarding the condition.category:

https://hl7.org/fhir/R4/condition.html
provides 2 options for condititon.category, with a clear definition: problem-list-item | encounter-diagnosis
or a Condition Category Codes ([Extensible]

Do we need the 7 options as described in
https://www.ehealth.fgov.be/standards/fhir/core-clinical/ValueSet-be-vs-problem-category.html
provides BeVSProblemCategory
Problem and Diagnosis seem to match problem-list-item and encounter-diagnosisProblem
The other options are under discussion in the Careset Problme V1.3 document.
I hope we will stay as close to the general model and value sets as possible.

[annabel-uzl]

I agree with @FilipTNH and would like to just see the two options for category (problem-list-item | encounter-diagnosis) as described in the international profile.

Also, I would like a way to link problem list items to eachother. In the international profile there is an extension 'dueTo' https://build.fhir.org/ig/HL7/fhir-extensions/StructureDefinition-condition-dueTo.html which exists both in R4 and R5. Is that something we can use?

[chrjol]

Regarding the condition.category:

https://hl7.org/fhir/R4/condition.html provides 2 options for condititon.category, with a clear definition: problem-list-item | encounter-diagnosis or a Condition Category Codes ([Extensible]

Do we need the 7 options as described in https://www.ehealth.fgov.be/standards/fhir/core-clinical/ValueSet-be-vs-problem-category.html provides BeVSProblemCategory Problem and Diagnosis seem to match problem-list-item and encounter-diagnosisProblem The other options are under discussion in the Careset Problme V1.3 document. I hope we will stay as close to the general model and value sets as possible.

I agree with @FilipTNH. IT is not easy to assign a category when you have 7 different choices

[annabel-uzl]

CareSet.BeProblem - short.docx

Some remarks we made within a smaller group and would like to discuss in the WG (or BWG) (See document for more info - but not too much more - we compared with the Document in this thread not with the online build profile)

• Evidence element is missing and we would like to add it
  
  (We could also link encounters to the condition and put the symptoms in the encounter, but also in favor of being able to link manifestations directly to the condition. Link different features to complex diseases to get a complete overview. But not everyone will use it (probably GP not) so definitely not mandatory!)
• ConditionDueTo/Cause has cardinality 1..1: will there always be a cause registered? -> No, this should be 0..1
• Cause is limited to some resources: Immunization can also be a cause?
• Stage element also not present (would like to have it, e.g. when deriving an oncology profile from the BeProblem profile) -> This should be there but of course not mandatory
  (SNOMED international will publish a white paper on how to capture scales and stages)
  
• RecordedDate & Recorder card 1 seems ok
• ClinicalStatus card ok (we can use default active)
• CourseOfDisease BeExtension was a proposal, should be discussed in the business WG but we don’t see a usecase for this and are not in favor
• Encounter element also not present --> should be there
  
• [Condition] Cardinality discrepancy bodysite BeProblem #49 Cardinality bodySite 0..* instead of 0..1
• Category: what is the valueset (GP uses it as encounter-diagnoses or problem-list-item), but examples in the document resemble reporting (?) and grouping (e.g. diabetic)
  -> Grouping done by the statistician and how they want to use it – grouping can change over time.
  -> Not the hospital that should do it
  -> See also discussion above
• We want a way to link different conditions to each other (certainly if condition is just a proposal) – you have the verificationStatus but you cannot link Conditions with it (condition-related?)

Other remarks on CareSet document

• [Condition/Observation] Alternation between BodyLocalisation and BodyLocation in the documents #54 Alternation between BodyLocalisation and BodyLocation
• [Condition/Observation] Reference to FHIR R5 (should be R4?) #53 Reference to FHIR R5 (should be R4?)
• [Condition] !!! ValueSet 'Code' BeProblem #50 ValueSet code - working on a white list

---

@bdc-ehealth @KarlienHL7Belgium @annenerenhausen : none of the people in the mini WG can be present the 27th (next main WG for Problem/Observation). I think most of the thinks need to be discussed in the business WG ?