2022-11-30 CDex/HRex Meeting

The following CDex calls will be cancelled -- enjoy the holidays! 

• December 21st
• December 28th 

January Ballot Cycle 

• Take part in the formation of consensus groups for the HL7 January Ballot Cycle! 
• Da Vinci Member Attribution List Implementation Guide is included
• To participate in voting, you must join the consensus group by December 8, 2022
• Commenting and voting will take place December 9, 2022 – January 9, 2023

Need help navigating? Review the HL7 Balloting Resources for Da Vinci Newcomers

Save the Date! January Work Group Meeting & Connectathon

• Connectathon: January 14-15, 2023 (2023 - 01 Connectathon 32)
• Work Group Meeting: January 16-20, 2023

• Location: Hilton Lake Las Vegas Resort and Spa, Henderson, NV (In-Person)

• Registration now open! Early bird registration is available through Friday, December 16th.

• CDex Track page: 2023 - 01 Da Vinci Clinical Documentation Exchange/Attachments (CDex)
• Track kickoff call: December 14th from 2:00 - 3:00 PM ET

PLEASE consider testing CDex at the Connectathon!  It's very important that we test!

CDex Workflow Using Questionnaire: https://hackmd.io/2VIO8mEdSSO6h12ZLqgNeA?view 

• Most tickets have been resolved and voted on. Eric will be working on applying changes throughout the month of December. Probably won't get the updated guide published until after the first of the year. 

Enhancements to task-based queries: 

• In a task based query, can ask for a code, FHIR search query, or free text. Now, adding the ability by using DTR - fill out a DTR form and send back. 
• Eric reviewed a summary of the steps for a CDex task-based query using DTR
• Discussion
  • SN: Are there standard questionnaires that are available or can it be any set of questions?
  • EH: Could be standard or may be a repository of standard questionnaires. It could be anything but need to consider what's reasonable to ask.
  • BD: Goal is to obtain information that is missing, not to standardize information that is missing. Would expect there to be situation-specific questionnaires (e.g., questionnaires specific to oncology, etc.). 
  • SN: It's not a question of missing information. The attachment was always additional information. For a relatively unique situation, I need additional pieces of information that are not on the standard auth/claim.
  • BD: Standard auth/claim do not include info for medical necessity - what do you need for claim review or for prior authorization. Not already embedded in 837 or 278. It's information that is outside the standard transaction.
  • EH: This is showing a task-based query. Would hesitate to say that any questionnaire is fair game.
  • LM: The questionnaires will be infinite. They could be customized for this particular instance. If a payer sends a form today, you have choice to fill it out or not - the consequences will be the same. 
  • SN: Go back to solicited and unsolicited scenario - is there a situation where I have to send these pieces of information. Is there a way to send those without going through this request/response process? 
  • LM: That's sort of what CRD/DTR is about. Here are things you will need to do, fill it out now if you would like. Depends on whether standardized form - may be possible to send as attachment alongside the claim. If it's custom stuff, probably not as easy.
  • SN: Would like for data consumer to set up whatever question they would want from the data source - would be valuable functionality to have. Is this possible? And ahead of time, the data consumer could send questionnaire ahead of time and say fill this out?
  • LM: We have general ability (before this was introduced), I would like more information (either with LOINC codes or free text). This is more of an instrument-based way of requesting additional information - so there should be some "standardized form" to obtains information of interest. May be specific to the payer, service, etc. It may be trimmed down, but would still be dealing with some sort of standardized information collection process. 
  • EH: This is a CDex Task-based query. CDex started out with how to request clinical data. This is one other way to gather data. Another way is to get free text, LOINC codes, etc. This is an additional way to retrieve information.
  •  SN: Is there guidance for users - there are four ways to accomplish something. Is there guidance on the best method to use for various situations?
  • LM: The ways that we have are 1) specify a particular code - will use when looking for a document; 2) please execute this query - do this when you believe data exists but it may need to be filtered before you see results; 3) ad hoc question - which is something that doesn't fit the other two; and this new, fourth mechanism 4) instrument - you have an instrument that can be used to capture by answering specific questions. 
  • BD: Are you focused primarily on concept of attachments or any broader exchange between payer/provider? 
  • SN: Focused on attachments.
  • BD: Only two methods 1) provide a LOINC code and get back documents that those codes represent; 2) specify a questionnaire which can collect discrete information from MR or interaction with individual. 
  • SN: Why can't you use FHIR query syntax?
  • BD: The pre-population is a FHIR query. 
  • EH: This proposal is specific to task-based queries. 
  • SN: Not arguing against it - just trying to understand it so it can be explained/shared with other folks. 
  • CT: Between all methods of requesting clinical data, the hierarchy and when you would use one or another. How would a data consumer know that they can ask in a particular way?
  • EH: Capability statement is one way to articulate this. 
  • BD: Ultimately, this will go in National Directory. I have an endpoint that supports CDex and these are all the CDex components that are supported. We have a complex environments. Unfortunately, these solutions are complex as well. 
  • KJ: When talking about task-based questionnaire generically. Does it have the context of the claim? Does the task have reference to claim that was created? 
  • EH: There is a reason code/reason reference to the claim. 
  • KJ: If we have that, I can see how to make this work. If there wasn't a linkage, would be difficult.

POU Tracker:

• FHIR-39339: CDex Purpose of use value set is not consistent with requirements for 45 CFR 164.506 (Rob_McClure) Persuasive

CDex Use Case Examples:

• FHIR-38585: CDex Use Case Examples (Celine Lefebvre)

13:00:58 From Davinci CDex To Everyone:
    Today's Agenda: https://confluence.hl7.org/pages/viewpage.action?pageId=144974887
13:33:39 From Eric Haas To Everyone:
    https://hackmd.io/2VIO8mEdSSO6h12ZLqgNeA?view
13:33:45 From Eric Haas To Everyone:
    Hack md page
13:36:12 From Crystal Kallem (POCP / Da Vinci PMO) To Everyone:
    https://jira.hl7.org/browse/FHIR-39339

Adjourned at 2:43 PM ET