Problem statement #75
Replies: 2 comments 7 replies
-
@johngrimes thanks a lot for this summary. Would you be open to elaborating a bit more on the "transform definitions into queries that are capable of being executed by a wide variety of different query engines"? Like where does the initial FHIR data live? Does it get transformed into SQL tables, or are you suggesting there could be other stores that would be able to use the same "transform definitions"? Or do you mean these should work on a variety of different SQL engines? Maybe it would make sense to elaborate a few different stack options explicitly? For instance.
Is this the type of process you are thinking? What are the variable possible types of input resources provided to the "doTransform" function? I imagine a TS object or a HAPI/Firely Condition class depending on language, is there anything else? |
Beta Was this translation helpful? Give feedback.
-
I just wanted to point to this marvelous piece of engineering: https://voltrondata.com/codex The solution patterns and approach taken in the so-called Composable Data Stack looks very similar to ours. Perhaps we can re-use parts of the documentation/concepts. |
Beta Was this translation helpful? Give feedback.
-
I had a go at writing a succinct, high-level statement of the problem, let me know what you think:
Problem
As the availability of FHIR data increases, there is a growing interest in utilising it for analytic purposes. However, to use FHIR effectively analysts require a thorough understanding of the specification, including its conventions, semantics, and data types.
FHIR is represented as a graph of resources, each of which includes nested data elements. There are semantics defined for references between resources, data types, terminology, extensions, and many other aspects of the specification.
Most analytic and machine learning use cases require the preparation of FHIR data using some sort of projection or transformation from its original form. The task of authoring these transformations is not trivial, and there is currently no standard mechanism for reuse.
Solution
A standard format can be provided for defining use case-specific views of FHIR data. Tools can be developed that transform these definitions into queries that are capable of being executed by a wide variety of different query engines.
These views can be made available to users as an easier way to consume FHIR data - simpler to understand and easier to process with generic analytic query tools.
FHIR implementation guides could include definitions of simple, flattened views that comprise essential data elements. The availability of these view definitions will greatly reduce the need for analysts to perform repetitive and redundant transformation tasks for common use cases.
Beta Was this translation helpful? Give feedback.
All reactions