-
Notifications
You must be signed in to change notification settings - Fork 0
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
How to handle lists in FHIRflat (tracker/discussion) #18
Comments
Condition classBodySite
|
Encounter classreason
diagnosis
|
As long as these fields do not need to be searched, it should be fine to store them nested -- for certain fields like |
Observation classComponent
|
ResearchStudy resourceoutcomeMeasure
progressStatus
comparisonGroup
|
Currently resolved by storing fields with lists containing more than one data item as nested data items, with a "_dense" suffix, as these fields are not expected to be queried regularly in the standard analyses. If codeableConcept fields with 0..* cardinality are found to occur regularly in the input data & in searches, another column containing only the codes in |
Due to the nested & flexible nature of FHIR, there are several components within multiple Resources which contain lists, or multiple layers of nested lists of data.
The purpose of this issue is to collate and track examples of this behaviour, with the aim of finding a solution to map this data into a flat or semi-flat format while limiting the number of restrictions we have to place on the base FHIR resources.
For example, we could restrict the cardinality of some variables to 0..1 rather than 0..* to remove some of the nested lists, but if we wish to ingest FHIR data in the future this may make it incompatible. We would prefer to simply extend FHIR where necessary, rather than restrict existing functionality.
Part of #1
The text was updated successfully, but these errors were encountered: