search

cqframework / cqf-us

Common Assets for use in US-based CQFramework content implementation guides
Apache License 2.0
3 stars 2 forks source link

We need a component-level diagram to illustrate the Prior Authorization Questionnaire Use Case #25

Closed dmuylwyk closed 3 days ago

dmuylwyk commented 3 weeks ago

We need a component-level diagram to illustrate the Prior Authorization Questionnaire Use Case. This diagram should include:

This diagram should appear under section 1.2.1 Prior Authorization Questionnaire Use Case, and it should be accompanied by narrative as necessary.

dmuylwyk commented 2 weeks ago

Hi, @brynrhodes. Are you able to weigh in on the questions below?

This diagram could be as simple as the draft below but I'm not sure it's of any value. Note the draft is informed by expected systems defined here:

20240824-Draft-Prior-Authorization-Questionnaire-Use-Case

When considering the sequence diagram available here (also reproduced below), the only thing that seems to be missing is more detail w.r.t. how the DTR App executes CQL and retrieves data from the EHR. SDC's $populate appears to be the answer but it's not explicitly named, and includes some limitations.

Additionally, SDC doesn't appear to mention the CQF Library extension at all, which CQF-US requires.

Bottom Line

I'm not sure how the proposed diagram and narrative should appear. DTR describes form population using Library-based CQL expressions via the CQF Library extension; however, SDC does not. I need to plug this gap in my knowledge.

Questions/Concerns

Question 1

Is the DTR App expected to invoke $populate on the Provider EHR?

If the answer to No.1 is yes, I'm concerned because I cannot find any mention of the CQF Library extension in SDC. The question becomes: Does or will $populate support Library-based CQL expressions via the CQF Library extension?

Additionally, the expression language of text/cql-identifier was introduced in FHIR R4B, which may be a consideration for Prior Authorization Questionnaire Use Case implementations using FHIR R4.

Question 2

Alternatively, is the DTR App expected to implement behaviour similar to $populate; being solely responsible for interpreting the Questionnaire, executing the CQL, and retrieving data from the Provider EHR?

If the answer to No.2 is yes, I'm concerned about having to do CQL execution in the app. This could theoretically be delegated to an intermediary component that exists between the DTR App and the Provider EHR; unfortunately, $populate as defined does not support such delegation (i.e. there's no "get your data from this FHIR endpoint" input parameter). This would require enhancing $populate, overloading $populate, or defining a new operation.

Knowledge Dump

This initially looked like a relatively simply task. There are lots of related resources at the following links:

I've reproduced the sequence diagram available here, and I've added numbers for reference purposes:

sequenceDiagram
    participant pro as Provider EHR / Authorization Server
    participant dtr as DTR App
    participant pay as Payer
    pro-->dtr: 1. Configure EHR to App connectivity
    pro-->pay: 2. Configure EHR / App to Payer Connectivity
    note over pro: 3. SMART / Native App Launch
    pro->>dtr: 
    note over dtr: 4. DTR App leverages<br/>pre-defined Payer information
    dtr->>pay: 5. DTR's $questionnaire-package operation
    pay-->>dtr: 6. Returns "Questionnaire Package"
    note over dtr: 7. DTR App uses "Questionnaire Package"<br/>to pre-populate QuestionnaireResponse
    dtr->>pro: 8. Execute CQL / Retrieve data from EHR
    note over dtr: 9. User verifies data and<br/>QuestionnaireResponse
    dtr->>pro: 10. Store completed QuestionnaireResponse

In steps 4-6, we determine the needed Questionnaire in one of at least two ways:

Unfortunately, I'm a little confused by steps 7-8. The DTR App should use data from both the Provider EHR and the Questionnaire Package returned by the Payer to populate a QuestionnaireResponse, which it stores with the Provider EHR. It seems this should happen using one of SDC's population operations ($populate).

DTR describes use of the CQF Library extension here:

DTR uses the SDC Expression-based Population mechanism as the mechanism for populating, and specifically the use of CQL as the expression language. CQL SHALL be used when pre-populating elements using data gathered from the EHR. This will mean using the launchContext, variable and the initialExpression, contextExpression or calculatedExpression extensions together with logic in Libraries referenced by the cqf-library extension to help populate the QuestionnaireResponse.

Expression-based population means using one of the population operations defined in SDC. For example, $populate:

brynrhodes commented 2 weeks ago

Thank you for the detailed comments and questions, the short answer is that the DTR specification is not prescriptive about the use of the $populate operation, since the DTR application is effectively responsible for the population. It could choose to use a $populate operation, but it may not, choosing to run the CQL itself directly. I've provided a simple diagram in this branch and identified the main points of the data flow from the perspective of CQL evaluation. I've also identified the contexts in which CQL expressions may be run throughout the DTR process, and documented how that CQL will be parameterized from the various DTR contexts. We will review on the community call tomorrow.

dmuylwyk commented 2 weeks ago

the DTR specification is not prescriptive about the use of the $populate operation, since the DTR application is effectively responsible for the population.

Thank you for this clarification!

I believe I misinterpreted the following to mean DTR uses the population operations:

DTR uses the SDC Expression-based Population mechanism as the mechanism for populating

However, it quite literally means it uses the mechanism of expression-based population but not necessarily the population operations this mechanism supports.