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

BeModelPatient: additional data elements #134

Open
ildossche opened this issue Aug 2, 2024 · 7 comments · May be fixed by #141
Open

BeModelPatient: additional data elements #134

ildossche opened this issue Aug 2, 2024 · 7 comments · May be fixed by #141

Comments

@ildossche
Copy link

Upon verification of the current elements in the profile, following data elements are of interest to add in BeModelPatient:

  • Patient.extension:birthPlace
  • Patient.identifier:SSIN
  • Patient.active
  • Patient.telecom
  • Patient.multipleBirth[x]
  • Patient.contact
  • Patient.communication
  • Patient.link
    As well as the references to generalPractitioner and managingOrganization.

In addition, two suggestions for the ID's to obtain a closer alignment between model and profile:

Profile BePatient BeModelPatient current ID BeModelPatient proposed ID
Patient.deceased[x] BeModelPatient.death.deceased BeModelPatient.deceased.boolean
Patient.deceased[x] BeModelPatient.death.date BeModelPatient.deceased.date

Small typo noticed in practitioner https://build.fhir.org/ig/hl7-be/core/branches/releasecandidate/StructureDefinition-be-practitioner.html: last constraint is listing SINN instead of SSIN

@bdc-ehealth
Copy link
Contributor

bdc-ehealth commented Oct 2, 2024

WG: in the logical model the birthplace is represented currently by birth.address, we will change this to birth.place. We will add the National Register Number (0..1). Active could be added as well, but we would like to have a definition of active. Telecom: is this a must support field? What kind of telecom-addresses do we want to keep here? MultipleBirth: do we really need this on the generic Belgian level (especially as MS), or can this be handled in a more specific profile. Contact: same questions as MultipleBirth. The other remaining fields raise the same questions. @ildossche can you comment on this?

@KarlienHL7Belgium
Copy link

@ildossche : could you please provide your feedback for our next meeting on 16 Oct ?

@bdc-ehealth bdc-ehealth linked a pull request Oct 2, 2024 that will close this issue
@ildossche
Copy link
Author

@KarlienHL7Belgium Apologies for the delay. Input from my end:

  • Active: suggestion to add based on what was present in the profile. There the definition is "Whether this patient's record is in active use". (From secondary use perspective not a field which we'll need to capture, but good to be aligned with the profile).
  • Telecom: in my opinion, in the context of pandemic preparedness, yes, a must support field. In the profile it is recommended to have at least a one phone or email address. Is it needed to specify in the model which kind? Can we also refer to the datatype ContactPoint like in the profile?
  • multipleBirth: is included in the R4 Patient resource (https://hl7.org/fhir/R4/patient.html) so not sure why we would prefer not to include it in the Belgian profile? I'm probably missing some context on the discussion. @bdc-ehealth feel free to setup a short call and/or I'll try to join on Wednesday 13/11. Thanks

@bdc-ehealth
Copy link
Contributor

WG: active will not be a part of the model, because its definition/meaning is largely system related, and we define nation wide profiles.

@bdc-ehealth
Copy link
Contributor

WG: telecom will be added to the logical model, but it will be optional. The contactpoint is the contact point for direct communication, this means that in some cases this can be the contactpoint for the closest next-of-kin (then the contact point will also occur under "contact" (=next of kin)).

@bdc-ehealth
Copy link
Contributor

WG: multipleBirth will be added to the logical model, but it will not be mandatory.

@bdc-ehealth
Copy link
Contributor

WG: we will add contact, communication, generalPractitioner and managingOrganisation, but not in a mandatory way. If this information is explicitly needed in a use case, a specific profile needs to be made.

For link: we think this relationship is too abstract on a logical level, and we would like to add a more functional relationship for the options that can be expressed by link. If the need arises we will add them on a more functional level.

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

Successfully merging a pull request may close this issue.

3 participants