Transformations - general discussion

[niquola]

We need a few design principles for SQL on FHIR!

[niquola]

For example:

Transformation should be straightforward and require less context (aka profiles, valuesets etc), it should be possible to implement it inside database

[gotdan]

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

• Externalize contained resources for queryability
• Split ids from references and store as separate element for join performance
• Make ids from multiple sources unique to avoid conflicts (optional if only a single source is represented in the db)

Level 1 - transforms to standardize elements

• Between vendors (e.g., onsetPeriod vs. onsetDateTime)
• Between resource types (e.g., category in observation vs. category in allergyintolerance)
• Quantity units?

Level 2 - transforms to flatten resources into common representations

• Maybe some kind of namespacing approach for these so can have e.g., multiple patient representations depending on use case?
• Commonly used extensions could be renamed and incorporated here (e.g., omb race codes for a US Core patient can be concatenated into a race_codes field for one of the patient representations)

Level 3 - analytic aggregates, quality calculations, standard reports?

[niquola]

I like it!

[vadi2]

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?

[niquola]

I suggest having 4 named levels:

• Schema
• Terminology
• Transformation
• Views

Give each Transformation it's name:

• Reference
• Quantity
• Extensions

[vadi2]

Yep, that would work!

[niquola]

And I'm still not sure about optional transformations. Looks like, for simplicity and portability, we have to choose only the required transformations!

[niquola]

• Transformation should be in two directions, so people can use SQL on FHIR format as a primary storage format.
• Transformation algorithm should be "easy to implement" - ideally context-free (no prior knowledge of StructureDefinitions etc) or minimize context to simple lookup object.