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

[PhilipvD]

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]

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]

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]

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.