A JavaScript framework for executing CQL
Full Changelog: https://github.com/cqframework/cql-execution/compare/v3.0.0...v3.0.1
DataProvider (a.k.a. PatientSource) and TerminologyProvider (a.k.a. CodeService) can now happen asynchronously. This allows for these providers to more easily leverage web services and databases for their data.cql-execution now has some performance improvements, specifically when dealing with ValueSets that have a large amount of codes. See https://github.com/cqframework/cql-execution/pull/278 for a detailed description of these enhancements, and huge shoutout to @birick1 for the thoughtful implementation!The asynchronous migration is a breaking change. Implementers are required to make minor updates to their code to use this release. The code snippets below demonstrate the old way of invoking the v2.x.x engine and two ways to invoke the 3.x.x engine.
// v2.x.x usage
const result = executor.exec(patientSource);
// Do something with result
// v3.x.x usage
executor.exec(patientSource).then((result) => {
// Do something with result
})
// or
const result = await executor.exec(patientSource);
// Do something with result
Existing implementations of DataProvider (PatientSource) and TerminologyProvider (CodeService) will continue to work as-is. Implementers who maintain their own implementations of these services may want to consider updating them to return results asynchronously.
For more information, see the V2 to V3 Migration Guide.
In addition, when running cql-execution in a Node.js environment, you should use at least Node 16.
To install this release in your project, run the following command:
npm install --save cql-execution@3
Full Changelog: https://github.com/cqframework/cql-execution/compare/v2.4.6...v3.0.0
CQL Execution 3.0.0 Beta supports an asynchronous execution flow. Patients are still processed in a serial fashion, but calls to the DataProvider (a.k.a. PatientSource) and TerminologyProvider (a.k.a. CodeService) can now happen asynchronously. This allows for these providers to more easily leverage web services and databases for their data.
This is a breaking change. Implementers are required to make minor updates to their code to use this release. The code snippets below demonstrate the old way of invoking the v2.x.x engine and two ways to invoke the 3.x.x engine.
// v2.x.x usage
const result = executor.exec(patientSource);
// Do something with result
// v3.x.x usage
executor.exec(patientSource).then((result) => {
// Do something with result
})
// or
const result = await executor.exec(patientSource);
// Do something with result
Existing implementations of DataProvider (PatientSource) and TerminologyProvider (CodeService) will continue to work as-is. Implementers who maintain their own implementations of these services may want to consider updating them to return results asynchronously.
For more information, see the V2 to V3 Migration Guide.
In addition, when running cql-execution in a Node.js environment, you should use at least Node 16.
To install this beta release in your project, run the following command:
npm install --save [email protected]
This is a beta release and is subject to change. We welcome your feedback.
Full Changelog: https://github.com/cqframework/cql-execution/compare/v2.4.5...v2.4.6
When runtime errors are thrown from cql-execution during expression execution, the engine will attempt to extract more information about the expression that caused the error via the AnnotatedError object which is now exported from cql-execution. For example, an AnnotatedError could have the following message:
AnnotatedError: Encountered unexpected error during execution.
Error Message: Some error message
CQL Library: LibraryIdentifier|x.y.z
Expression: SomeELMExpressionType
ELM Local ID: 123
CQL Locator: 7:19-19:96
This information is also programatically accessible on the AnnotatedError object:
try {
// some execution that might throw an error
} catch(e) {
if (e instanceof AnnotatedError) {
e.message; // Error message shown above
e.libraryName; // Library identifier | Library version
e.expressionName; // Name of the expression class that threw the error
e.localId; // localId of the offending expression (must exist on the ELM)
e.locator; // locator of the offending clause (must exist on the ELM)
e.cause; // original stack trace of the error that was initially thrown
}
}
CQL Execution 3.0.0 Beta supports an asynchronous execution flow. Patients are still processed in a serial fashion, but calls to the DataProvider (a.k.a. PatientSource) and TerminologyProvider (a.k.a. CodeService) can now happen asynchronously. This allows for these providers to more easily leverage web services and databases for their data.
This is a breaking change. Implementers are required to make minor updates to their code to use this release. The code snippets below demonstrate the old way of invoking the v2.x.x engine and two ways to invoke the 3.x.x engine.
// v2.x.x usage
const result = executor.exec(patientSource);
// Do something with result
// v3.x.x usage
executor.exec(patientSource).then((result) => {
// Do something with result
})
// or
const result = await executor.exec(patientSource);
// Do something with result
Existing implementations of DataProvider (PatientSource) and TerminologyProvider (CodeService) will continue to work as-is. Implementers who maintain their own implementations of these services may want to consider updating them to return results asynchronously.
For more information, see the V2 to V3 Migration Guide.
In addition, when running cql-execution in a Node.js environment, you should use at least Node 16.
To install this beta release in your project, run the following command:
npm install --save [email protected]
This is a beta release and is subject to change. We welcome your feedback.
When runtime errors are thrown from cql-execution during expression execution, the engine will attempt to extract more information about the expression that caused the error via the AnnotatedError object which is now exported from cql-execution. For example, an AnnotatedError could have the following message:
AnnotatedError: Encountered unexpected error during execution.
Error Message: Some error message
CQL Library: LibraryIdentifier|x.y.z
Expression: SomeELMExpressionType
ELM Local ID: 123
CQL Locator: 7:19-19:96
This information is also programatically accessible on the AnnotatedError object:
try {
// some execution that might throw an error
} catch(e) {
if (e instanceof AnnotatedError) {
e.message; // Error message shown above
e.libraryName; // Library identifier | Library version
e.expressionName; // Name of the expression class that threw the error
e.localId; // localId of the offending expression (must exist on the ELM)
e.locator; // locator of the offending clause (must exist on the ELM)
e.cause; // original stack trace of the error that was initially thrown
}
}
Full Changelog: https://github.com/cqframework/cql-execution/compare/v2.4.4...v2.4.5
Fixes https://github.com/projecttacoma/fqm-execution/issues/172
CQL Execution 3.0.0 Beta supports an asynchronous execution flow. Patients are still processed in a serial fashion, but calls to the DataProvider (a.k.a. PatientSource) and TerminologyProvider (a.k.a. CodeService) can now happen asynchronously. This allows for these providers to more easily leverage web services and databases for their data.
This is a breaking change. Implementers are required to make minor updates to their code to use this release. The code snippets below demonstrate the old way of invoking the v2.x.x engine and two ways to invoke the 3.x.x engine.
// v2.x.x usage
const result = executor.exec(patientSource);
// Do something with result
// v3.x.x usage
executor.exec(patientSource).then((result) => {
// Do something with result
})
// or
const result = await executor.exec(patientSource);
// Do something with result
Existing implementations of DataProvider (PatientSource) and TerminologyProvider (CodeService) will continue to work as-is. Implementers who maintain their own implementations of these services may want to consider updating them to return results asynchronously.
For more information, see the V2 to V3 Migration Guide.
In addition, when running cql-execution in a Node.js environment, you should use at least Node 16.
To install this beta release in your project, run the following command:
npm install --save [email protected]
This is a beta release and is subject to change. We welcome your feedback.
Full Changelog: https://github.com/cqframework/cql-execution/compare/v2.4.3...v2.4.4
Fixes https://github.com/cqframework/cql-execution/issues/277
CQL Execution 3.0.0 Beta supports an asynchronous execution flow. Patients are still processed in a serial fashion, but calls to the DataProvider (a.k.a. PatientSource) and TerminologyProvider (a.k.a. CodeService) can now happen asynchronously. This allows for these providers to more easily leverage web services and databases for their data.
This is a breaking change. Implementers are required to make minor updates to their code to use this release. The code snippets below demonstrate the old way of invoking the v2.x.x engine and two ways to invoke the 3.x.x engine.
// v2.x.x usage
const result = executor.exec(patientSource);
// Do something with result
// v3.x.x usage
executor.exec(patientSource).then((result) => {
// Do something with result
})
// or
const result = await executor.exec(patientSource);
// Do something with result
Existing implementations of DataProvider (PatientSource) and TerminologyProvider (CodeService) will continue to work as-is. Implementers who maintain their own implementations of these services may want to consider updating them to return results asynchronously.
For more information, see the V2 to V3 Migration Guide.
To install this beta release in your project, run the following command:
npm install --save [email protected]
This is a beta release and is subject to change. We welcome your feedback.
Fixes #277
Full Changelog: https://github.com/cqframework/cql-execution/compare/v2.4.2...v2.4.3