Closed niquola closed 1 year ago
For example:
Transformation should be straightforward and require less context (aka profiles, valuesets etc), it should be possible to implement it inside database
One thing we could consider is constructing the spec in levels, each of which would build on the transforms in the previous level. E.g.,
Level 0 - base level transforms
Level 1 - transforms to standardize elements
Level 2 - transforms to flatten resources into common representations
Level 3 - analytic aggregates, quality calculations, standard reports?
I like it!
I'm wary of using levels like this because I suspect it would be difficult to have a conversation about the standard then and folks will be getting confused. Does anyone else see the same?
I suggest having 4 named levels:
Give each Transformation it's name:
Yep, that would work!
And I'm still not sure about optional transformations. Looks like, for simplicity and portability, we have to choose only the required transformations!
We need a few design principles for SQL on FHIR!