The demo data still contains identifiers for every resource. I didn't remove those.

To do: check for which resources the identifier can be removed (no business identifier in MIMIC) and for which it should stay.

Based on the demo data, I found:

• The profile MimicObservationDatetimeevents only allows Quantity for value[x], but the demo data contains a dateTime. Should value[x] here also allow dateTime?
  If so, change * value[x] only Quantity to * value[x] only Quantity or dateTime in SD_MimicObservationDatetimeevents.fsh

• The profile MimicProcedureICU only allows dateTime for performed[x], but the demo data contains a Period range. Should performed[x] also allow Period?
  If so, change * performed[x] only dateTime to * performed[x] only dateTime or Period in SD_MimicProcedureICU.fsh

Pain code is still in the MimicObservationTypeED value set, it needs to be in MimicObservationTypeVital instead. Maybe I forgot to move it.. or did we eventually decide to not move pain to MimicObservationVitalSigns? We went back and forth on this and now I don’t remember!

Should we change the cardinality of Encounter.type in MimicEncounter to 0..*?

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?

There is a MIMIC codesystem for units http://fhir.mimic.mit.edu/CodeSystem/units. Does UCUM contain all values in that CS? If yes, we could change all unit references to UCUM. If not, it can stay (no action).