Should the core tables not encourage using fields that aren't even must-support?

[mikix]

Examples:

• 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. :shrug:

But worth thinking about not overpromising on fields that aren't in US Core, as we add core tables.

[dogversioning]

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
• leave as is and debug when its a problem

[mikix]

Yeah some combo of documentation / leaving alone and being aware of it as we onboard sites with unusual EHRs is probably fine enough.

I was just surprised at how lightly-supported Encounter references could be! But in practice, they do have wide support.

[dogversioning]

closing this as covered via #280