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

Joint profiles: what to do with 1..1 elements in either ED or MIMIC-IV #7

Open
PhilipvD opened this issue Aug 2, 2022 · 3 comments

Comments

@PhilipvD
Copy link
Collaborator

PhilipvD commented Aug 2, 2022

Example: Patient.birthDate is (always?) present in MIMIC-IV but is not in MIMIC-ED. When creating the ED Patient example instance I changed the cardinality of Patient.birthDate to 0..1 instead of 1..1. But after some thought I figured that maybe it's better to keep 1..1 cardinalities whenever an element is always present in either of the databases, and then add a dataAbsentReason extension with code 'unsupported' (http://hl7.org/fhir/R4B/valueset-data-absent-reason.html) if needed.

If we do that for every element that should be 1..1 in ED or IV (joint profiles Procedure, Patient, Encounter, Condition) validation won't be broken.

What do you think?

@alexmbennett2
Copy link
Contributor

For joint profiles I think we would go with 0..1 cardinality if it is present in one but not another. I think it adds unnecessary extensions and these profiles are to encapsulate all of MIMIC.

For the example of birthDate I had a couple thoughts/clarifications. Right now there is no MIMIC-ED patient, as all patients overlap between MIMIC-ED and MIMIC-IV. So patients are created in MIMIC-IV and just referenced by the MIMIC-ED resources. So every patient will have a birthDate since they are generated from the MIMIC-IV side of things.

Overall the only joint profiles are Encounter and Condition (since Patient assumes the MIMIC-IV source). The elements that are required for those two profiles shows up in both so, it looks like we are fine on that front.

  • Encounter requires identifier, subject, period, status, class, and type
  • Condition requires encounter, subject, category, and code

@PhilipvD
Copy link
Collaborator Author

PhilipvD commented Aug 2, 2022

I see now. I was still thinking of MIMIC-IV and MIMIC-ED as two different entities.

Then birthDate should be added to the Patient profile as 1..1. I will remove the MIMIC-ED Patient example (so that it's clear there's only one type of patient).

@jpwiedekopf
Copy link
Collaborator

I'd agree with Alex's way of going about it, using 0..1 cardinalities. While data-absent-reason is exactly the right call here, I'd think that for users of MIMIC-FHIR it'd be easier in their analyses to assume that values might be missing entirely, instead of having to query for the extension.

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

3 participants