Open PhilipvD opened 2 years ago
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.
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).
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.
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?