-
Notifications
You must be signed in to change notification settings - Fork 31
Prioritized Features
The following is my (Chris Moesel's) DRAFT prioritization of potential features to implement in cql-execution. This list still needs to be discussed with the team. This list, and the prioritization of the items, should not be interpreted as any sort of guarantee regarding what will actually be implemented. Future steps will depend on availability of resources and level of need.
ValueSet type (#226)
Difficulty: Low
Rationale: This type was introduced to better support the needs of eCQM developers. As some developers have already inquired about support for this in cql-execution, it makes send to prioritize it.
Support QI Core negation w/ notDoneValueSet extension (#296)
Difficulty: Medium
Rationale: Measure authors will need to use QICore classes representing things not done. The primary difficulty in implementing this feature might be determining how exactly how it should work. There is also possibility that although it is FHIR-specific, it may need to leak into the main cql-execution code due to our current architecture.
The following items should be easy to get done quickly and represent real gaps in our implementation that might come up in normal use.
A. Implies (#158)
Difficulty: Very Low
Difficulty: Very Low
C. Support Retrieve:codeComparator (#293)
Difficulty: Very Low
D. Point From (#163)
Difficulty: Very Low
E. High Boundary / Low Boundary (#159)
Difficulty: Low
CQL's representation of numbers suffers from limitations in JavaScript's Number class. These limitations are primarily around range, precision, and floating point arithmetic. While there are two separate issues listed below, it may make sense to tackle them at the same time.
A. Improved Support for Decimal (#280)
Difficulty: High
Rationale: Since Decimals are used in many operations, switching the current representation to a new representation will ripple across the code base and test suites. There are several operations that don't work correctly due to the current implementation (e.g., successor / predecessor), so fixing this will also address those limitations. This should also help pave the way for the Long representation.
B. Long (#207)
Difficulty: High
Rationale: Since Longs can be used in many operations, implementation of Long will affect code across the implementation. That said, it's unclear how much Long will be needed in eCQMs and CDS, so it is lower priority than fixing decimals.
Support Advanced Terminology API (#299)
Difficulty: Medium
Rationale: A new terminology API allows for more efficient and flexible implementations, as well as support for additional terminology operations. The most difficult part of supporting a new terminology provider API is designing it correctly. Once that is done, implementation of it in cql-execution should be fairly straight-forward. To reduce complexity, we can (and probably should) build a wrapper class that can wrap a code service using the old API and expose it using the new API. In addition, we will likely want to build a very simple implementation, similar to the code service implemented in cql-execution today.
As of now, it seems that the following data types and operations around code systems have limited value. That said, once #299 is implemented, support for these operations should be rather simple.
A. CodeSystem type (#259)
Difficulty: Low
B. Vocabulary type (#281)
Difficulty: Low
C. InCodeSystem / AnyInCode System (#289)
Difficulty: Low (assuming #299)
D. Subsumes / SubsumedBy (#290)
Difficulty: Low (assuming #299)
Support Advanced Data Provider API (#300)
Difficulty: Medium-High
Rationale: An advanced data provider API allows for more efficient and flexible implementations, as well as support for new retrieve capabilities (e.g., related context retrieves). A big part of this task is ensuring that the API is designed well, allowing for meaningful and efficient interaction between the engine and the provider. This may require some refactoring of how contexts work in the engine, hence the potential for high difficulty. To reduce complexity, we can (and probably should) build a wrapper class that can wrap a patient source using the old API and expose it using the new API. In addition, we will likely want to build a very simple implementation that exercises at least some of the common capabilities for the made up Simple data model in cql-execution test code.
RelatedContext Retrieves (#209)
Difficulty: Medium-High (assuming #300)
Rationale: The mechanics of how related context retrieves should work still seem a bit fuzzy, and there may be gaps in the data that require assumptions to be made. It's possible that implementation may not be too difficult (assuming #300), but there is some risk here.
The current engine's support for the Unfiltered Context is minimal. This has not been a problem thus far because measures have not used this context (nor has CDS). That said, it would be good to improve support for this context.
A. Support Retrieve in Unfiltered context (#156)
Difficulty: Low (assuming #300)
B. Support Included Library References in Unfiltered context (#157)
Difficulty: Medium
As far as I can tell, these operators are not typically used for eCQM or CDS; but rather, exist to support FHIRPath.
A. Children (#287)
Difficulty: Low
B. Descendents (#288)
Difficulty: Low
External Functions (#286)
Difficulty: Medium
Rationale: External functions are discouraged, and thus, seldom used. The primary difficulty in supporting external functions is determining how they should be registered and invoked.