Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mikix opened this issue Mar 18, 2024 · 3 comments
Closed
Labels
question Further information is requested

Comments

@mikix
Copy link
Contributor

mikix commented Mar 18, 2024

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. 🤷

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

@mikix mikix added the question Further information is requested label Mar 18, 2024
@dogversioning
Copy link
Contributor

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
Copy link
Contributor Author

mikix commented Mar 18, 2024

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
Copy link
Contributor

closing this as covered via #280

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants