phema / cql-on-omop Goto Github PK

Using Strings in java causes truncation of large JSON cohort definitions. Currently a hard coded json statement is used in the application. Switch to using the generated once the truncation is fixed.

We should be able to process and incorporate externally referenced libraries containing CQL logic. This will allow us to support CQL files that include external CQL files that contain function/logic definitions within them.

More information

• https://ecqi.healthit.gov/cql/CQ-Qs%26As#LibrariesinCQL
• Shared Logic section at: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=400

From @psbrandt

Another idea is to accept the URL of a Composition resource as input, and then download the full Composition document using the $document operation. That can be a stretch goal though, and either way, we need to be able to evaluate one of these bundles.

Right now the correlated queries we support are pretty much hardcoded. For the Phenotype Workbench demo, we need to support a slightly more generic correlated queries.

For the Phenotype Workbench demo we need to support in Interval because the Thrombotic event phenotype uses this statement.

Translate from FHIR attribute constraints to appropriate OHDSI representation. For example, "BMI > 20", "LDL > 100". Multiple attribute types beyond values should be investigated.

Rather then using oid from within the elm file, read the codes from a spreadsheet. The authoring application is outputting the algorithm in a zip file. Look at examples from PhAT output

See https://github.com/PheMA/phema-workbench-repository/blob/700cab6d3d07c83d40526589ae9cbb6586f041e5/bundles/phema-phenotype.9.cataracts.bundle.json#L1493-L1509

Currently the demo is hard-coded for Condition types. We need to expand this to other types we expect to get from the FHIR data model.

Handle nested boolean expressions

In addition to valueset references, we could consider adding support for individual codes. That would allow us to support this COVID phenotype.

Some tables were left out during installation. Causes cohort generation to fail

http://52.162.236.199:8080/WebAPI/ddl/results?dialect=postgresql

When using the QUICK data model with the reference implementation, only resources that are explicitly associated with the QUICK profile are retrieved.

I think it would be better to use the base FHIR data model instead, since this would put fewer restrictions on implementations, as they wouldn't be required to associate the QUICK profile with all their FHIR resources.

We should implement the following interface for resolving value sets from a FHIR server:

We will need this in the Workbench API.

Translate counts of items (e.g., >=2 diagnoses) from ELM to OHDSI

Local builds are fine but fail in Travis. It appears to be an issue where one of the dependencies via the WebAPI JAR is trying to access an http:// address, but that address has permanently moved to require https://

We are currently on something like version 2.6.x of the WebAPI, which includes Circe 1.7.x. We should update to the latest version.

I misunderstood what counting distinct meant when I pushed d15218c. I thought it meant that duplicate conditions/procedures/etc wouldn't be double-counted. It actually means that only conditions/procedures with different concepts will be counted.

Ensure logging of execution progress provides sufficient detail for user to see progress, and to troubleshoot when/if errors occur.

Support temporal relationships between items

Account for patient age within CQL functions, and how that translates to OHDSI age representation in a query.

Embed this within the OHDSI WebAPI as an extension and invoke from translator

(Suggested by Guoqian Jiang)

The thrombotic event phenotype has a criterion that checks the value of a lab result. We need to implement support for this.

Need more complex conversions to be sure cover all possibilities.

The system should be able to execute phenotypes that are represented as a FHIR Bundle

Right now our correlated query implementation is pretty limited. We only support a single relationship, and we match on specific resource/attribute pairs.

I think the more correct way to do this is to push aliases onto a stack in the context, and then process the where clause as a normal expression. This would eliminate the need for special resource/attribute pair matching and would re-use all the code we already have for expression translation.

When processing the where expression, when we encounter an alias reference, we would able to resolve this by peeking into the stack in the context. Basically, aliases are noted and resolved like any other reference.