Thank you for joining the CodeX team on June 3 2021 to explore current state problems being faced in provider-payer oncology data exchange. This call was a great start to brainstorming where FHIR standardization can add the most value within the oncology ecosystem.


Session Recording 

Session Slides

Attendees Joined from:

  • Mayo Clinic
  • University of Michigan
  • Pfizer
  • MHDC / NEHEN
  • NCCN
  • DeepThink Health
  • Karkinos Healthcare
  • Sigmoid Health
  • eviCore


  • BCBSA
  • United HealthCare
  • Independent Health
  • Independence Blue Cross
  • EverNorth / CIGNA
  • Optum
  • ASCO CancerLinQ
  • FEHRM
  • CMS
  • FDA


  • Oncology Nursing Society
  • Mathematica
  • NextGen Healthcare
  • Trinity Health
  • SavantSolutions4HIT
  • Mettle Solutions
  • Massive Bio
  • Varian
  • MITRE
  • Point of Care Partners

Discovery Session Summary

Themes


  1. Multi-stakeholders sharing interests and understandings about data, workflows, and technology with payer-provider workflows shows need for collaboration and education.
  2. Quality, completeness and structure of oncology data at rest (in EHRs) lacks consistency
  3. Need for structured clinical data interoperability was heard across multiple stakeholders 
  4. Implementation of electronic Prior Authorization (PA) via Da Vinci standards has the potential to reduce burden by incorporating coverage discovery and payer clinical data requirements presented in the provider workflow.
  5. Meeting providers and payers where they are today in their existing workflows and building for the future is a first step 

Barriers/Obstacles


  1. Clinical information that is not documented in an EHR (e.g secondary metastasis) impacts patient care and downstream stakeholders/systems
  2. High level of effort when developing, using, and maintaining proprietary information exchanges 
  3. Lack of structured and high quality oncology clinical data in EHRs. "when you deal with oncology patients, what is in the EHRs is not enough"
  4. Until there is a clear purpose for data, physicians cannot allocate the time to collect the data - understanding the value is key
  5. Structured data elements (mCode) need to be available to the payers in order to automate the PA conversation
  6. Data used for quality measures - e.g. symptom documentation, is still sparse in discrete data to be able to leverage for eCQMs
  7. Pursuit of perfection may be the enemy of progress - need parallel improvements across technology, process, workflow, standard data structure capture, automation of transactions
  8. Challenge with other IT and regulatory priorities competing for resources to transition to FHIR
  9. Education on technologies available, what's working and what's not, what's proposed for the future, e.g. what's an "app" in the context of Prior Authorization. 
  10. Complexities of medical benefit PAs and/or pharmacy benefit PAs
  11. Providers (office staff) need to learn many separate payer portal workflows continues to increase burden (beginning with "where is the right site for this patient's coverage?)
  12. Providers cannot tolerate "yet another app" that may cause context shifting in the workflow

  13. Single payer solutions are still prevalent and don't solve the interoperability or burden reduction problem, not much better than the separate web/portal forms.

  14. Payer requirements for attachments in addition to structured data capture from patient's Medical Record/EHR

  15. Provider burden and workload.  Need education of existence of the standard (CRD/DTR) that supports option to submit PA's that can be executed by staff outside of the physician workflow. Many oncology practices have optimized the staff in helping to fill in information, and the oncologist reviews everything to make sure of accuracy.  It still is burdensome to oncologists and staff when there is no auto-approval for straightforward treatments. 

Potential Use Case Starting Points


  1. Oncology Prior Authorization -
    1. Improve the collection and sharing of oncology data in standardized way i.e., CodeX to bring it into existing workflows (attachments, portals, OCR)
    2. Continue building upon Da Vinci CRD/DTR/PAS and others that exist outside of cancer and add the features needed to make them work better for cancer
  2. Define data profiles and element documentation for cancer care (mCODE) broken out by stakeholder - (Payer, Patient, Provider, Care Team, Registries, Clinical Trials) - CodeX wide goal. 
    1. Create a comprehensive oncology data set standard for PAs to meet all Payers' needs and can be incorporated into cancer documentation within EHRs.
    2. Define data profiles and elements 
  3. CodeX additional use case opportunity: "Oncology Requirements Discovery"
    1. Providers need to understand what to document and why it's important. In addition to needing to document for PA, there are other purposes for structured, standard oncology data.
    2. Provider can discover what needs to be recorded for PA through Da Vinci CRD/DTR, it's unknown if there is a discovery process for other purposes/use cases (e.g. public health/registries, clinical trials, adverse event reporting, research level data for EHR end points for cancer clinical trials)


Next Steps


  1. Continue discussion with community (providers, vendors, EHRs, payers) to think and build, leveraging the FHIR universe that is USCORE/Da Vinci and mCODE.
    1. Provide diagrams to visualize the intersection work/workflows/data
    2. Identify initial use cases for simple data exchange with mCode plus USCORE (Da Vinci Payer/Provider IGs - CDex, PDex with oncology payload) 
  2. Provide education to drive awareness of opportunities for improvements or shared learnings:
    1. Da Vinci CRD/DTR/PAS,  share recorded demo(s)
    2. Explore ability to benefit from common workflows, share all payer apps, and common formats/data sets to pre-populated questionnaires from EHR. 
  3. Explore how to leverage above work to refine / define the clinical data profiles and elements required for PA decision making and other needs beyond Payers as part of other CodeX use cases. Expose gaps in data elements and continue to expand those in the mCODE data set.



  • No labels