PSS: The scope of the CDex project is to defined combinations of exchange methods (push, pull, subscribe, …), specific payloads (Documents, Bundles, and Individual Resources), search criteria, conformance, provenance, and other relevant requirements to support specific exchanges of clinical information between provider and other providers and/or payers. The goal is to identify, document and constrain very specific patterns of exchange so that providers and payers can reliably exchange information for patient care (including coordination of care), risk adjustment, quality reporting, identifying that requested services are necessary and appropriate (e.g. should be covered by the payer) and other uses that may be documented as part of this effort. Clinical data payloads will include C-CDA, C-CDA on FHIR, compositions, bundles, specific resources, and bulk data exchange. This list is intended to be illustrative and not prescriptive. The project will address patient consent where appropriate. IG proposal: This IG provides detailed guidance that helps implementers use FHIR-based interactions and resources relevant to scenarios associated with Provider exchange of clinical information with Payers and other Providers. The IG covers six specific use cases that demonstrate how to exchange clinical data generated by Providers with Payers and other Providers to improve care coordination, support risk adjustment, ease quality management, facilitate claims auditing and confirm medical necessity, improve member experience, and support orders and referrals. It supplies guidance on how to reuse existing profiles fit for this type of exchange and provides additional profiles and guidance, where needed, to specifically address the requirements not covered by existing Implementation Guides and profiles. For these six use cases, the IG describes how to exchange required data as individual FHIR resources, data extracted together as a meaningful collection of information, or data shared in the form of a clinical document such as an encounter summary or patient summary. An encounter summary document includes a predefined collection of data that tells the story of an encounter where services were provided to a patient. A patient summary document includes a predefined collection of data that provides and overview of the provision of care services provided to a patient over a range of time. The IG clarifies exchange requirements for metadata that establishes the context (provenance) for documents, collections of resources, and individual informational resources as well. see https://confluence.hl7.org/pages/viewpage.action?pageId=40738757 https://confluence.hl7.org/display/DVP/CDex+Supporting+Materials?preview=/40741941/40742231/CDex%20DaVinci%20Meeting%20-current.pptx subscribe to Task queue and filter on task_id get ping with id and pull Task to get info or just async and get url to pull up info. Level Set... IG Strategy: focus of IG Support FHIR RESTFUL Query Task Based approach - mirrors PCDE outline of IG General Framework: Support FHIR RESTFUL Query Task Based approach - mirrors PCDE explain when and why Exemplar UseCases and Examples ... do we have a tool that create examples + subscribe to Task queue and filter on task_id +/-aysnc? call out bulk data review trackers next steps: create outline use hackmd for the markdown editing. try to create in sushi update sushi to latest ver. start with only hrex and US Core artifacts for now. create CapStatements in xcel create a branch for the old stuff and start from scratch in new branch Task profiles tighten down codes - Establish CapabilityStatements for different roles Describe and show hoe CommunicationRequest ServiceRequest for authorization Question these are scenarios in how might use this ig. = Background sections Decision base on Authorization, Access, knowledge of codes may need to protect user data/ filter it UM/CM systems? How do those systems receive clinical information? Use Case: A payer generates clinical data in their Utilization and Case Management systems. For example, a Payer could be coaching a member on a diabetes management. Another potential stream is data in support of a prior auth request. Please confirm Bulk data is not within scope. Capability statements – Payer side and EHR sides – how tight should we get to say they are conformant with this IG? Once Eric sends a summary, please review and let us know if this is aligned with scope expectations for an updated version to send to Ballot. From there, we can confirm (or not) if a January ballot cycle is still feasible. ß Add section WHERE does CDEX it fits into the DAVINCI Picture: cut and paste from confluence: add provider to provider section What is unique about this - above and beyond to USCore CDEX provides additional technical guidance. What is unique. What is the Reason for the Query REST: OAuth for reason for information Query (is this even necessary at this level either you have access or you don't) "If they're wanting to restrict auth based on a reason then that's a different way than we've thought of auth today" "So I would go back to "what level" they're wanting to know re:what data is being accessed/why, then to who is going to know that and when. That would help us figure out where in the process it would be available for input" Where do you stick PurposeOfUse in OAuth? Is there any guidance about how that can/should be computable? hack using X-Provenance header TASK: Task reason (coded vs text) Can we have a 'Background' and 'Spec' tab in the menu? (Use cases should appear under Background.) Also, can we change the name 'Framework' to 'Exchange approaches' or something like that that might be clearer to people? Finally, Artifacts should be pointing to the overall artifacts list rather than separate pages for each category, though you can have menu links that jump to the specific sections if you like.