Replies: 4 comments 2 replies
-
I like it! To make the definition more regular - can we rename "resource" on the top-level to "from"?! |
Beta Was this translation helpful? Give feedback.
-
Here is a version only using select (no columns): {name: "patient_address",
from: "Patient",
select: [{name: "pid", expr: "Patient.id"},
{from: "address"
select: [{name: "street", expr: "line.join('\n')"},
{name: "use", expr: "use"},
{name: "city", expr: "city"},
{name: "zip", expr: "postalCode"}]}]}
{name: "us_core_blood_pressure",
from: "Observation",
select: [{name: "id", expr: "id"},
{name: "patient_id", expr: "subject.getId()"} ,
{name: "effective_date_time", expr: "effective.ofType(dateTime)"}
{from: "component.where(code.coding.exists(system='http://loinc.org' and code='8480-6')).first()",
select: [{name: "sbp_quantity_system", expr: "value.ofType(Quantity).system"},
{name: "sbp_quantity_code", expr: "value.ofType(Quantity).code"},
{name: "sbp_quantity_display", expr: "value.ofType(Quantity).unit"},
{name: "sbp_quantity_value", expr: "value.ofType(Quantity).value"}]},
{from: "component.where(code.coding.exists(system='http://loinc.org' and code='8462-4')).first()",
select: [{name: "dbp_quantity_system", expr: "value.ofType(Quantity).system"},
{name: "dbp_quantity_code", expr: "value.ofType(Quantity).code"},
{name: "dbp_quantity_display", expr: "value.ofType(Quantity).unit"},
{name: "dbp_quantity_value", expr: "value.ofType(Quantity).value"}]}]
where: [{expr: "code.coding.exists(system='http://loinc.org' and code='85354-9')"},
{expr: "component.where(code.coding.exists(system='http://loinc.org' and code='8480-6')).first().dataAbsentReason.empty()"},
{expr: "component.where(code.coding.exists(system='http://loinc.org' and code='8462-4')).first().dataAbsentReason.empty()"}]} |
Beta Was this translation helpful? Give feedback.
-
An initial attempt at incorporating nested selects into the spec is at #78. There are definitely open questions in this space so we can continue discussing prior to merge, or we can merge and update as we sort out more details. |
Beta Was this translation helpful? Give feedback.
-
Closing this discussion since it has been merged into the spec. We can reopen others for any follow up items. |
Beta Was this translation helpful? Give feedback.
-
Here is an attempt at incorporating some of the FQL's approach into the view definitions. This is just a quick pass at what our current examples might look like in this model, with the following major changes:
vars
stanza in favor of nested expressions. I think this simplifies most cases, although there is some redundancy in the blood pressure example so we could consider whether it's worth keepingvars
even in this nested world.whenMany
expression, since the unrolling behavior is dictated by the use offoreach
orfrom
in nested selects.foreach
es in different trees will result in a cross join, similar to FQL and nested SQL behavior. However, I think that's easier to see and understand here than in our previous structure, so it is less likely to lead to surprising behavior for the user.Simple demographics
The simple demographics example is unchanged, although this adds a "select" stanza around columns to create a parent for nested
selects.
We could also consider just keeping a "columns" option at the root, but having all of them under "selects" is arguably
more consistent with the examples below.
Patient addresses
The nest example unnests patient addresses. Note that there is an "unnest", explicitly unrolling the address into separate rows.
We
Blood pressures
Beta Was this translation helpful? Give feedback.
All reactions