Download presentation
Presentation is loading. Please wait.
1
Prior-Authorization Support
March 22, 2019
2
Interim Antitrust Policy
ANSI Antitrust Policy ANSI neither develops standards nor conducts certification programs but instead accredits standards developers and certification bodies under programs requiring adherence to principles of openness, voluntariness, due process and non-discrimination. ANSI, therefore, brings significant, procompetitive benefits to the standards and conformity assessment community. ANSI nevertheless recognizes that it must not be a vehicle for individuals or organizations to reach unlawful agreements regarding prices, terms of sale, customers, or markets or engage in other aspects of anti-competitive behavior. ANSI’s policy, therefore, is to take all appropriate measures to comply with U.S. antitrust laws and foreign competition laws and ANSI expects the same from its members and volunteers when acting on behalf of ANSI. Approved by the ANSI Board of Directors May 22, 2014
3
Agenda for March 22, 2019 HITAC Presentation overview
“Classes” of Services/Device/Treatments that require prior-Authorization Who can request a PA for each Information required for processing the PA
4
“classes” of PA Class Ordered by PA Requested by Performed by Examples
Documentation Medications Physician DME Referral Consults Imaging Lab Testing Surgical Procedures Hospital Admission Home Health Physical Therapy
5
Information Needed for PA (e.g. 278)
Category Detail Value Sets Comments Payer Demographics Provider Demographics Patient Demographics Ordered “service” Date(s) Quantity …. Documentation
6
Virtual (within same CH)
Future FHIR Enabled Solution Must be ASC X12N 278 (PA request) / 275 (attachment with CDA) May be any method (including ASC X12N) HL7 FHIR Virtual (within same CH) FHIR FHIR ASC X12N 278/275 ASC X12N 278/275 Any Method 1a 1b Any Method Payer 1 ASC X12N 278/275 FHIR 2 Any Method FHIR ASC X12N 278/275 FHIR Payer 2
7
Use Case Alignment Use Case Status Chronic Illness Documentation for
In HL7 ballot reconciliation as draft standard Under active development Active development (use case support) 2019 use cases Use cases in discovery Chronic Illness Documentation for Risk Adjustment Patient Cost Transparency Performing Laboratory Reporting Risk Based Contract Member Identification Prior-Authorization Support Gaps in Care & Information Documentation Templates and Coverage Rules (DTR) Health Record Exchange: Clinical Data Exchange (CDex) Health Record Exchange: Payer Data Exchange (PDex) Additional Quality Measures Coverage Requirements Discovery (CRD) Health Record Exchange: Framework (HRex) Data Exchange for Quality Measures Framework (DEQM) 7
8
Clinical Scenario 1 Mrs. Jones is a 35 y.o., previously healthy female who is seen by Dr. Good for a new onset headache that began abruptly 2 weeks prior to her visit. They are severe at times, last several hours and have been occurring with increasing frequency. Now they are occurring daily. Her physical including neurologic exam is normal. Dr. Good is concerned about an intracranial process. Dr. Good wants to order a head CT to check for any masses, but is unsure whether Mrs. Jones requires insurance authorization or documentation. Using an application within his EHR, he sends a CRD request to her insurer. Within a few seconds, the application informs Dr. Good that Mrs. Jones does need a prior-authorization along with a copy of the applicable clinical documentation (Progress Note, prior studies, etc.). DTR – the request may return a “template” and rules that: Gathers prior-authorization information from the medical record Determines gaps in the record that represent information necessary for prior-authorization approval Prompts the provider for the additional information (where appropriate) Triggers a prior-authorization submission and waits for a return message
9
CRD + DTR + Prior-Authorization Support
10
CRD + DTR + Prior-Authorization Support
Provider does not have the necessary information to answer the PA documentation request
11
Topic for 3/1 What to do when provider does not have the necessary information? Suspend session until information is available Put task in queue Move session to another individual Level of specificity of information (general authorization (e.g. Head CT) vs authorization for a specific procedure (e.g. Head CT with contrast)) Test ordered by one provider and the services is delivered by another provider – both may need to interact with the payer Artifact that can be forwarded to servicing provider and may be the basis for an additional PA interaction – take into account the need for AU evaluation by third party Issue regarding benefit managers working on behalf of the payer Radiology – total dose accumulation for radiology Need to look at specialty care issues Comments regarding formulary (out of scope for this effort) unless part of medical benefit
12
CRD + DTR + Prior-Authorization Support
Payer is unable to make a PA determination in real-time
13
Topic for 3/1 What to do when payer cannot make an immediate decision ? Respond with pended notification Answer PA with Entry in Provider queue Out of band response (e.g. call / Fax / …) Other Current problem with 278 is no defined response method Ability to push the decision back to provider without the provider needing to initiate a query Into their clinical workflow – predictability of the timing Flagged as what it is, priority, ability to move to another person in the practice
14
Provider interactions
Ask if want to initiate SMART on FHIR PA app Option: Queue as task for someone else in “practice” (configurable by practice/practitioner/ type of service) Option: what to do if need to submit information to servicing provider to submit PA (interesting workflow considerations) Web Service, HIE, EHR to EHR, patient cloud Need to provide guidance for each workflow (Ordering, Servicing, either /or) If all information is available – 1) Need to review, since attesting to information -- option to “sign” Option to submit Option to cancel Option to queue for someone else to submit Request “missing” information Considerations: Multiple reviewers Updated (e.g. add contrast) Time frame (e.g. every 60 days) Counts Change in servicing provider Addl services Addl information required
15
Workflow / Interaction Paths
A) CRD query 1) Not enough information to make a decision a) Query record for additional information i) 2) Not require PA or no PA rules (end) a) Respond with no PA or unknown 3) PA Required a) Payer reasons to not allow (e.g. provider not in network) i)Respond with reason no covered b) Allowed but no
16
Next Steps Determine if we are using Claim resource as the bases for the PA Support Pro – contains information to request PA and manage response Con – information required that may not be EHR and vendors may not support the resource Complete description of use case for inclusion in IG Create IG based on FHIR R4 and work that has been done on Coverage Requirements Discovery (CRD) Documentation Templates and Rules (DTR) Healthcare Record Exchange Framework (HRex) Clinical Data exchange (CDex)
17
Agenda for February 22, 2019 HIPAA requirements for Prior-Authorization (PA) Orientation to Da Vinci use cases Relationship between use cases and implementation guides Approach for PA Support Discussion regarding use of Claim resource and next steps
18
Current Prior-Authorization Environment
Fax PA Request Telephone Payers Portals Providers Medical Records Electronic Transactions Currently providers and payer exchange prior authorization requests and supporting medical records using a number of methods: telephone, fax, portals, and electronic transactions
19
ASC X12N 278/275 (or portal for DDE)
Current HIPAA / Anticipated Attachment Approach Must be ASC X12N 278 (PA request) / 275 (attachment with CDA) (Portal is allowed under the direct data entry exception) May be any method (including ASC X12N) Any Method 1 ASC X12N 278/275 Payer 1 Any Method 2 ASC X12N 278/275 (or portal for DDE) Payer 2 Regardless of transaction path, covered transactions must be in the “standard” format at some point between covered entities
20
Current HIPAA / Anticipated Attachment Approach
Must be ASC X12N 278 (PA request) / 275 (attachment with CDA) May be any method (including ASC X12N) Any Method 1 ASC X12N 278/275 Payer 1 Any Method 2 BA ASC X12N 278/275 Payer 2 Covered entity may use a Business Associate (BA) to satisfy HIPAA requirements HIPAA requirements pass to the BA
21
Virtual (within same CH)
Current HIPAA / Anticipated Attachment Approach Must be ASC X12N 278 (PA request) / 275 (attachment with CDA) May be any method (including ASC X12N) Virtual (within same CH) Any Method ASC X12N 278/275 Any Method 1a 1b Payer 1 ASC X12N 278/275 Any Method 2 BA ASC X12N 278/275 Payer 2 Per the reqs (i.e. § Requirements for covered entities), if the Clearinghouse services both payer and provider, they must act as two virtual clearinghouses and must provide the transaction as a HIPAA compliant standard transaction internally – not currently enforced by CMS
22
X Challenge EHR Payer 1 Payer 2
Must be ASC X12N 278 (PA request) / 275 (attachment with CDA) May be any method (including ASC X12N) X Any Method 1 EHR Any Method ASC X12N 278/275 Payer 1 2 Any Method Payer 2 Most EHRs do not directly support ASC X12N 278 / 275
23
X N N Challenge EHR N Pat Adm/ Pat Adm/ Practice Practice Mgmt./ BA
Must be ASC X12N 278 (PA request) / 275 (attachment with CDA) May be any method (including ASC X12N) X Any Method 1 EHR Any Method ASC X12N 278/275 Payer 1 ASC X12N 278/275 N N Any Method 2 Any Method N Pat Adm/ Practice Mgmt./ BA Usually not Real-time for PA / attachments Payer 2 Pat Adm/ Practice Mgmt./ Payer 2 Only 8% of PA and < 6% of attachments are electronic end to end (based on 2017 CAQH INDEX Report)
24
FHIR Supported Prior-Authorization Environment
Must be ASC X12N 278 (PA request) / 275 (attachment with CDA) May be any method (including ASC X12N) HL7 FHIR Payer 1 FHIR API ASC X12N 278/275 FHIR API FHIR FHIR Any Method Any Method FHIR API FHIR API Any Method Any Method Payer 2 FHIR FHIR FHIR API FHIR API
25
Virtual (within same CH)
Future FHIR Enabled Solution Must be ASC X12N 278 (PA request) / 275 (attachment with CDA) May be any method (including ASC X12N) HL7 FHIR Virtual (within same CH) FHIR FHIR ASC X12N 278/275 Any Method 1a 1b Any Method Payer 1 ASC X12N 278/275 FHIR 2 Any Method FHIR ASC X12N 278/275 FHIR Payer 2
26
2019 Use Case Status Project Outputs
Data Exchange for Quality Measures Coverage Requirements Discovery Documentation Templates and Coverage Rules Project Outputs Define requirements (technical, business and testing) Create Implementation Guide Create and test Reference Implementation (prove the guide works) Pilot the solution Deploy the solution Health Record Exchange: Clinical Data Exchange Health Record Exchange: Payer Data Exchange Prior-Authorization Support Gaps in Care & Information Risk Based Contract Member Identification Alerts: Notification (ADT), Transitions in Care, ER admit/discharge Use Case Status In HL7 ballot reconciliation as draft standard Under active development 2019 use cases Use cases in discovery Performing Laboratory Reporting Chronic Illness Documentation for Risk Adjustment Patient Cost Transparency 26
27
Use Case Alignment Use Case Status Chronic Illness Documentation for
In HL7 ballot reconciliation as draft standard Under active development Active development (use case support) 2019 use cases Use cases in discovery Chronic Illness Documentation for Risk Adjustment Patient Cost Transparency Performing Laboratory Reporting Risk Based Contract Member Identification Prior-Authorization Support Gaps in Care & Information Documentation Templates and Coverage Rules (DTR) Health Record Exchange: Clinical Data Exchange (CDex) Health Record Exchange: Payer Data Exchange (PDex) Additional Quality Measures Coverage Requirements Discovery (CRD) Health Record Exchange: Framework (HRex) Data Exchange for Quality Measures Framework (DEQM) 27
28
2. Coverage Requirements Discovery (CRD)
SUMMARY Providers need to easily discover which payer covered services or devices have Specific documentation requirements, Rules for determining need for specific treatments/services Requirement for Prior Authorization (PA) or other approvals Specific guidance. With a FHIR based API, providers can discover in real-time specific payer requirements that may affect the ability to have certain services or devices covered by the responsible payer. The discovery may be based on Plan conditions only (e.g. no need for PHI) Member identification (PHI) in the event the specific plan is not known at the time of request Response may be The answer to the discover request A list of services, templates, documents, rules URI to retrive specific items (e.g. template) Low Complexity Category Level of Effort Effort Medium Complexity Time to Ref Imp 3-6 mo Source/HL7 WG Finance CDS-Hooks FHIR Fitness Good Standards Dev Scope (including IG) Easy Implementation Challenges 28
29
Order Procedure, Lab or Referral
Coverage Requirements Discovery Provider Order Procedure, Lab or Referral Discover Any Requirements Payer Providers need to easily discover which payer covered services or devices have Specific documentation requirements, Rules for determining need for specific treatments/services Requirement for Prior Authorization (PA) or other approvals Specific guidance. With a FHIR based API, providers can discover in real-time specific payer requirements that may affect the ability to have certain services or devices covered by the responsible payer. Response may be The answer to the discovery request A list of services, templates, documents, rules URL to retrieve specific items (e.g. template)
30
Cross Functional Drawing
31
Documentation Requirements Look-up Service (DRLS)
Based on a specific clinical workflow event: scheduling start of encounter ordering or planning treatment discharge API Payer 1 PROVIDERS API Is there a requirement for PA or specific documentation Payer 2 YES OR NO FHIR**-BASED EXCHANGE API * EHR ELECTRONIC HEALTH RECORD API GIVE ME THE TEMPLATES / RULES PAYER 3 HERE ARE THE TEMPLATES / RULES DRLS is the CMS instantiation of the Da Vinci Coverage Requirements Discovery (CRD) use case Graphic taken from the CMS Special Open Door Forum (SODF) presentation 31
32
3. Documentation Templates and Coverage Rules (DTR)
SUMMARY Providers are challenged to deal with the diversity of administrative and clinical requirements that impact documenting the need for treatment and selecting the appropriate best path for care. The current environment is made more complex by the large number of payer based requirements that must be met to document that covered services and devices are medically necessary and appropriate. The goal of this use case is to reduce provider burden and simplify process by establishing electronic versions of administrative and clinical requirements that can become part of the providers daily workflow. An exemplar for this use case is to follow the approach taken to incorporate formulary requirements interactively into the medication selection process. Proposal includes the ability to inject payer coverage criteria into provider workflows akin to clinical decision support (CDS Hooks), to expose rules prospectively while providers are making care decisions. A limited reference implementation on a limited use case (e.g. Home Oxygen Therapy) Address coverage requirements, documentation compliance, and detect misuse/ abuse Provide value based care requirements at point of service Collect, in real-time, patient information to alert provider or care team Medium-High Complexity Category Level of Effort Effort Medium - High Complexity High Time to Ref Imp 9-12 limited RI, for all aspects Source/HL7 WG CQL, SDC, CDS-Hooks FHIR Fitness Good-Excellent Standards Dev Scope (including IG) Medium-Complex Implementation Challenges 32
33
Documentation Templates and Payer Rules (DTR)
Providers need to easily incorporate payer requirements into their clinical workflow Specific documentation requirements, Rules for determining need for specific treatments/services Requirement for Prior Authorization (PA) or other approvals Specific guidance. Use a FHIR based standard for representing payer “rules” to communicate, in real-time, payer medical necessity and best clinical practice requirements that may affect the ability to have certain services or devices covered by the responsible payer. The template/rules may (examples, not complete list) Specify provider documentation requirements for coverage, medical necessity Provide guidance / documentation requirements regarding social determinates that are antecedents for specific care Collect information for some purpose (e.g. authorizations) Indicate clinical requirements including appropriate use Collect specific documentation for Quality Measures Respond with specific information as requested/documented in the template/rules
34
DTR / Order Flow
35
Concept for Documentation Templates and Rules (DTR)
5.Requests missing information 6. Provider supplies missing information 3a.SMART on FHIR App is initiated by the Provider/EHR 4. Rules determine missing information in patient record 3b. SMART on FHIR App retrieves appropriate template and rules 1. Provider Places Order 7. Stores information in EHR System 8. Optionally, returns information to payer 2a. EHR send CRD request, order, and clinical context to DRLS Payer N 2b. CARDs return link to SMART on FHIR App and context Payer’s CDS Note: The SMART standard was created by Boston Children’s Hospital Computational Health Informatics Program and the Harvard Medical School Department for Biomedical Informatics.
36
eHealth Record Exchange
HRex Health Record exchange Framework Interactions and Profiles DEQM Data Exchange for Quality Measures Framework CDex Clinical Data exchange PDex Payer Data exchange MRP Medication Reconciliation Post-discharge Additional Measures for DEQM IG
37
HRex Framework Implementation Guide
Health Record exchange Interactions FHIR Profiles (1) Push DSTU 2 Argonaut Other Artifacts Pull Bundles STU 3 US Core and QI Core Request R4 US Core and QI Core Value Sets Subscribe Non-US Core Mappings Bulk Data Provenance STU 2, STU 3, R4 C-CDA on FHIR CDS Hooks Conformance HEDIS Operations Authentication/ Authorization Da Vinci (Payer) Specific Rational Combinations CIMI Access Control/Audit Validation Extensions Examples Notes: 1) Existing work is adopted by reference
38
Relationship of HRex Implementation Guides
HRex Framework Implementation Guide Clinical Data exchange Exchange between Provider and Provider or Payer CDex Implementation Guide Payer Data exchange PDex Implementation Guide Define payer data sources (exemplary of a type) Claims/EOB (using intermediate structure) PBM/Meds Laboratory / Alerts Med record (e.g. CDA) based For each scenario (and FHIR version) Identify appropriate interaction(s) Query parameters (if appropriate) Identify appropriate profiles Define appropriate bundles Define constraints Define clinical exchange scenarios (exemplary of a type) Order and supporting documentation Lab results (clinician to clinician) b) Hospital discharge For each scenario (and FHIR version) Identify appropriate interaction(s) Query parameters (if appropriate) Identify appropriate profiles Define appropriate bundles Define constraints Notes: 1) Adopt interactions by reference 2) Adopt profiles by reference 3) Define only artifacts / constraints unique to the scenario(s) 4) Focus on examples
39
CRD + DTR + Prior-Authorization Support
40
Clinical Scenario 1 Mrs. Jones is a 35 y.o., previously healthy female who is seen by Dr. Good for a new onset headache that began abruptly 2 weeks prior to her visit. They are severe at times, last several hours and have been occurring with increasing frequency. Now they are occurring daily. Her physical including neurologic exam is normal. Dr. Good is concerned about an intracranial process. Dr. Good wants to order a head CT to check for any masses, but is unsure whether Mrs. Jones requires insurance authorization or documentation. Using an application within his EHR, he sends a CRD request to her insurer. Within a few seconds, the application informs Dr. Good that Mrs. Jones does need a prior-authorization along with a copy of the applicable clinical documentation (Progress Note, prior studies, etc.). DTR – the request may return a “template” and rules that: Gathers prior-authorization information from the medical record Determines gaps in the record that represent information necessary for prior-authorization approval Prompts the provider for the additional information (where appropriate) Triggers a prior-authorization submission and waits for a return message
41
Next Steps Determine if we are using Claim resource as the bases for the PA Support Pro – contains information to request PA and manage response Con – information required that may not be EHR and vendors may not support the resource Complete description of use case for inclusion in IG Create IG based on FHIR R4 and work that has been done on Coverage Requirements Discovery (CRD) Documentation Templates and Rules (DTR) Healthcare Record Exchange Framework (HRex) Clinical Data exchange (CDex)
Similar presentations
