Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Careset Problem V1.3 #22

Open
bdc-ehealth opened this issue Dec 6, 2023 · 8 comments
Open

Careset Problem V1.3 #22

bdc-ehealth opened this issue Dec 6, 2023 · 8 comments

Comments

@bdc-ehealth
Copy link
Contributor

@annenerenhausen

Careset Problem V1.3.docx

@bdc-ehealth
Copy link
Contributor Author

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

@HenkLacour
Copy link

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

BeModelProblem - HL7 FHIR Implementation Guide: Transversal Clinical Core v1 0 1 2023-12-12 07-43-57

Careset Problem V1 3 (1) 2023-12-12 07-38-04

@bdc-ehealth
Copy link
Contributor Author

@annenerenhausen

@bartvandenbosch@uzleuven.be requests the Dutch version of this document.

@bdc-ehealth
Copy link
Contributor Author

@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
Copy link

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
Copy link

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
Copy link

chrjol commented Mar 21, 2024

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
Copy link

annabel-uzl commented Jun 13, 2024

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
    image
    (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)
    image
  • 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
    image
  • [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


@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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants