You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Condition.encounter is not required by R4 and not even must-support by US Core v4
Same with Observation.encounter (for at least the Labs & Vitals profiles)
Same with AllergyIntolerance.encounter (which I know we don't have a core table for yet)
I assume there are non-encounter examples, but that's what I was thinking of right now.
An EHR might very well choose to not provide Encounters. That might be crazy? I dunno. But nothing in the FHIR spec or US Core is asking them to fill that field out, even if the data is available to them.
So by providing those fields in core, are we encouraging study authors to develop bad habits like using the encounter_ref field for joins. And then when an EHR comes by with full US Core compliance and those fields are all null, the study might not find any conditions if they are expecting encounter joins to work (rather than patient joins, which the spec does require).
Maybe we need Encounters too badly (for sequence of event thinking) to drop them and the chance of having such a rude EHR is slim. 🤷
But worth thinking about not overpromising on fields that aren't in US Core, as we add core tables.
The text was updated successfully, but these errors were encountered:
there are a number of fields in here that are outside of US core - and we've got requests for more (#190#185, for two).
there's a needle to thread here between clinical value/ease of use/spec compliance. and since we're basically saying 'we need flattened tables for analyst usage' to avoid all the complex type detection stuff, we're sort of overloading the core study.
so, just spitballing some options:
have a different study do maximal unnesting, and then have a core study select from that
have a 'pure core profile' subset of tables or views inside the existing core study
mark in documentation someplace that a field is optional
Examples:
An EHR might very well choose to not provide Encounters. That might be crazy? I dunno. But nothing in the FHIR spec or US Core is asking them to fill that field out, even if the data is available to them.
So by providing those fields in
core
, are we encouraging study authors to develop bad habits like using theencounter_ref
field for joins. And then when an EHR comes by with full US Core compliance and those fields are allnull
, the study might not find any conditions if they are expecting encounter joins to work (rather than patient joins, which the spec does require).Maybe we need Encounters too badly (for sequence of event thinking) to drop them and the chance of having such a rude EHR is slim. 🤷
But worth thinking about not overpromising on fields that aren't in US Core, as we add core tables.
The text was updated successfully, but these errors were encountered: