Skip to content
This repository has been archived by the owner on Oct 8, 2024. It is now read-only.

Add Reference fields that can be equijoined #6

Open
rbrush opened this issue Sep 6, 2018 · 4 comments
Open

Add Reference fields that can be equijoined #6

rbrush opened this issue Sep 6, 2018 · 4 comments

Comments

@rbrush
Copy link
Collaborator

rbrush commented Sep 6, 2018

FHIR References store a relative URL to the item they are referencing. This is often of the form Patient/<patient_id_here>. The downside to this is that the reference field cannot be used in simple equality-based joins, since the relative prefix (like "Patient/" or "Encounter/" is present in the reference string.

Therefore, the we should consider additional fields in the Reference structure -- perhaps "reference_id" and "reference_type" -- where the former can be used for equality-based joins and the later defines the type of resource being referenced.

@niquola
Copy link
Member

niquola commented Sep 10, 2018

We use following reference structure:

{id: "pt-1", resourceType: "Patient"}

There was idea unified with union type:

{ Patient: 'pt-id' [, resourceType: "Patient" ] / * optional */ }

See discussion here fhir-fuel/fhir-fuel.github.io#4

@niquola
Copy link
Member

niquola commented Sep 10, 2018

What nice about {id: .., resourceType:... } - that you can replace ref with resource and have same id and rt attrs (actual for graphql like results)

@rbrush
Copy link
Collaborator Author

rbrush commented Sep 11, 2018

Something like {id: .., resourceType:.. } makes sense to me. I think we might need to make it {resourceId: .., resourceType:.. }, since the "id" field is reserved for the ancestor Element. [1]

If {resourceId: .., resourceType:.. } seems okay, I'll create a PR with that change.

[1]
https://www.hl7.org/fhir/element.html#Element

@rbrush
Copy link
Collaborator Author

rbrush commented Sep 30, 2018

This is incorporated into PR #9

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants