Replies: 4 comments 2 replies
|
I like it! To make the definition more regular - can we rename "resource" on the top-level to "from"?! |
1 reply
|
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()"}]} |
1 reply
|
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. |
0 replies
|
Closing this discussion since it has been merged into the spec. We can reopen others for any follow up items. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
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:
varsstanza 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 keepingvarseven in this nested world.whenManyexpression, since the unrolling behavior is dictated by the use offoreachorfromin nested selects.foreaches 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
All reactions