Xt-EHR / xt-ehr-common

Creative Commons Zero v1.0 Universal
1 stars 0 forks source link

Use of FHIR for logical models might be confusing #24

Open kruzikh opened 3 weeks ago

kruzikh commented 3 weeks ago

Anabeth Askevold: Use of CodeableConcept as well as use of elements of the codeable concepts in the logical model should ba avoided.

danka74 commented 2 weeks ago

Could we perhaps use some visual cue in the template to separate Logical Models and Implementable Specifications?

costateixeira commented 2 weeks ago

that means messing with the template. I can try to think of a proposal

danka74 commented 2 weeks ago

that means messing with the template. I can try to think of a proposal

I did a, tongue in cheek, update of the template in this branch: https://github.com/Xt-EHR/xt-ehr-common/tree/lm-visual-cue https://build.fhir.org/ig/Xt-EHR/xt-ehr-common/branches/lm-visual-cue/

costateixeira commented 2 weeks ago

I noticed, but that changes the colors for everything , right? and I assume the purpose is to differentiate The "think of a proposal" is because I think this is valuable in general, not only for this case.

On Tue, Oct 1, 2024 at 2:34 PM Daniel Karlsson @.***> wrote:

that means messing with the template. I can try to think of a proposal

I did a, tongue in cheek, update of the template in this branch: https://github.com/Xt-EHR/xt-ehr-common/tree/lm-visual-cue https://build.fhir.org/ig/Xt-EHR/xt-ehr-common/branches/lm-visual-cue/

— Reply to this email directly, view it on GitHub https://github.com/Xt-EHR/xt-ehr-common/issues/24#issuecomment-2385660492, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD3HUUHRG4HKTXZKR5XMDTLZZKJF7AVCNFSM6AAAAABO6755PGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBVGY3DANBZGI . You are receiving this because you were assigned.Message ID: @.***>

costateixeira commented 2 weeks ago

note that the original request was about using FHIR (data types?) so keeping this open

kruzikh commented 2 weeks ago

I am afraid that we might be missing the target. Coloring will possible distinguish between model and implementable specs but the problem reported will remain. The problem is that if we will continue using CodeableConcept in the logical model which includes text and coding and in the same time heaving in the model a text element, e.g. in Condition class we have:

Data element Description Data type
Description Condition specification in narrative form Narrative
Code Code identifying the condition, problem or diagnosis CodeableConcept

There might be a confusion why we have Description and a Code of type CodeableConcept which also have text element, which can be also used for the description of the condition.

So, my proposal is to use Coding instead of CodeableConcept in this case and leave codeableConcept only where a textual element if not explicitly mentioned.