Prior-Authorization Support

Prior-Authorization Support
April 12, 2019

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

Agenda for April 12, 2019 New support for this use case
Milestone Dates Request for information (Next week ) Detailed dive on DME use case (end-to-end for next week) Drawings (workflow) Actors Information requirements Happy path (all information is in the medical record and payer provides approval in real-time) Exception processing “Information” required for processing the PA (start actual gap analysis) Review part of X (overall and patient event detail) Introduce the Claim and Coverage resources as the foundation Gaps with X and 275 information requirements Connectathons (Montreal and Jacksonville) Scenarios

Based on a July 1 start for the Ballot period and approval by TSC
Estimated Schedule for Prior-Authorization Support Based on a July 1 start for the Ballot period and approval by TSC Connectathon at May WG meeting in Montreal May 4-5 Notice of Intent to Ballot Due (-6 weeks) May 20 Connectathon in Jacksonville, FL May 29-30 Sign-up for Ballot opens (-30 days) June 1 Initial Content Due (-4 weeks) June 3 Final Content Due (-1 week) June 24 Ballot Opens July 1 Ballot Closes July 30 PA Calls March 29 April 5 April 12 April 19 April 26 May 3 May 10 (travel to Montreal) May 17 May 24 May 31 (in Jacksonville) June 7 June 14 June 21 Deliverables Implementation Guide for Ballot Reference Implementation Test Scripts

Information Needed for PA (e.g. 278)
Category Detail Value Sets Comments Payer Information Provider Information Patient Information Subscriber /Dependent Patient Event Detail Service Detail Documentation (for 275?)

Patient Event Detail Patient Event Level Used Yes
Patient Event Tracking Number (provider) Health Care Services Review Information Previous Review Authorization Number (assigned by Payer/UMO) Previous Review Administrative Reference Number (assigned by payer/umo) Use ID Accident Date Last Menstrual Period Date Estimated Date of Birth (condition?) Onset of Current Symptoms or Illness Date Event Date Admission Date Discharge Date Patient Diagnosis Patient Event Level Used Health Care Services Delivery (rate/frequency) (e.g. PT/OT) (may need addl detail) Yes Ambulance Certification Information (patient condition) Yes ? Chiropractic Certification Information Durable Medical Equipment Information Oxygen Therapy Certification Information Functional Limitations Information Activities Permitted Information Mental Status Information Ambulance Transport Information Spinal Manipulation Service Information Home Oxygen Therapy Information Home Health Care Information Additional Patient Information Message Text

Provider EHR Payer PA Service CDS/DTR based Prior-Authorization
1) CDS Hooks Provider Action Pre Fetch Payer CDS 1) Evaluates request 2) Gets additional information 3) Issues cards (result or links) 4) If PA required , sends SMART on FHIR link and context Context with Access Token 2) Access Patient Record optional 3) Return CARD(s) Provider Initiates App Optional link to SMART App SMART on FHIR Application 1) Get Payer PA Rules (CQL) 2) Retrieve information 3) Query missing information (SDC) 4) Send PA request with info 5) Receive and display result 4) Get Payer PA Rules 5) Send documentation rules 5) PA Request with MR* 6) Evaluate PA request 7) Reply with PA result 6) PA Result* *Conversion to/from ASC X12N required to meet HIPAA regulations

Agenda for April 5, 2019 New support for this use case Milestone Dates
Request for information (status) Detailed dive on DME use case (end-to-end) Drawings (workflow) Actors Information requirements Happy path (all information is in the medical record and payer provides approval in real-time) Exception processing “Information” required for processing the PA (start actual gap analysis) Introduce the Claim and Coverage resources as the foundation Gaps with X and 275 information requirements Connectathons (Montreal and Jacksonville) Scenarios

Request for Information
Note: pharma benefit PA is out of scope Top volume by category (see WG list, and any additional) (volume and %) Top PA services for top categories by total volume (include actual volume) (% of all PAs for category) Please include referrals that need specific authorizations For each indicate if specific documentation is required including any difference between initial request and subsequent requests If documentation is required, complexity and expectation for structured data Top PA services by priority (include reason other than volume) Specific issues with PA that you hope to resolve Are each of these PA determinations performed in-house or via a contracted service (which service) Standards use for the PA determination (e.g. Milliman, custom/proprietary , unknown) Are criteria in a computable format now, if so what format Can determinations be performed in real-time? Can determinations be performed in real-time via the X12 278/275 What specific considerations do you need this workgroup to consider in defining the requirements and creating the IG

CAQH Core Prior-Authorization Categories
General Outpatient Inpatient Surgery Oncology Cardiology Imaging Laboratory Physical Therapy Occupational Therapy Speech-Language Pathology Not include in CAQH DME Home Health Other from WG list (post acute care) Top volume May not require addl documentation New born Some DME Hemophilia Established pattern (not initial) Or continuation of services Step therapy advancing (doc req) Need to support both 278 only 278 and documentation (e.g. 275 or alterative) Need to be able to determine if Initial PA or subsequent (may determine the need for supplemental documentation) Conversation with Anupam Primary Care – e.g. Diabetes PA for meds, supplies, and referrals

See/incorporate list of PA from CAQH Core Operating Rules
Look at list of UM codes in 278 (universe of possibilities??) Look at LTC IG (in ballot) “classes” of PA Class Ordered by PA Requested by Performed by Examples Documentation Meds (Pharmacy Bene) Physician *** out of scope *** see NCPDP Meds (medical benefit) e.g. (infusion) DME Referral Consults Imaging Lab Testing Surgical Procedures Hospital Admission Home Health Physical Therapy Mental / Behavioral LTC / SNF / Rehab Hospice

Issues to Discuss Content for the 278 Alternative 1: Claim resource
Alternative 2: Patient, Practitioner, Practitioner Role, Organization, Location, … “request” resources (e.g. servicerequest) Coverage Content for supporting documentation Content defined by HRex and CDex (e.g. output from DTR) Limit to ordered by (MD, NPP) and performing (MD, NPP, Service (e.g. DME)) Limit to top PA services (assume 50-70% of volume for initial specification) to/from participants to clarify Viet and Bob to consolidate and blind as to source Do we describe three workflows or just one? Payer side only Exchange via 278 (/275) Provider side only Request for who uses standard clinical guidelines (e.g. Milliman) – part of Issues related to where the PA is done (tied to PM or EMR)

Notes Non-Emergency Scheduled Ambulance Transport
One-time authorization vs recurring (e.g. Home Health, O2, PT, DTS, MAT (medication assisted therapy) (e.g. Methadone) Who can ask for PA Medicare FFS – Service Provider (except PMD) Commercial -- Typically the Ordering Provider (Primary Care) If no PC, then ordering or prescribing physician Lab Community – who does PA? (

For 4/5 Run scenario end-end (e.g. referral or DME)
content to members for feedback on Top volume/priority for PA services Issues and considerations Standard Clinical “Rules” e.g. Milliman Start gap analysis with X12N 278/275

Agenda for March 29, 2019 Milestone Dates
“Classes” of Services/Device/Treatments that require prior-Authorization Who can request a PA for each Information required for processing the PA Scope of the work effort

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 For next week Milestone dates

Provider EHR Payer PA Service
Payer Focused CDS/DTR based Prior-Authorization Provider EHR Payer PA Service 1) CDS Hooks Provider Action Pre Fetch Payer CDS 1) Evaluates request 2) Gets required information 3) If PA required, evaluate documentation (may need to retrieve more information) 4) Reply with PA result via card If information is incomplete, then revert to prior method Context with Access Token 2) Access Patient Record optional 3) Return CARD with result Provider receives PA result Optional link to SMART App if missing information 18

Provider EHR Payer PA Service Provider Focused Prior-Authorization
1) CDS Hooks Provider Action Pre Fetch Payer CDS 1) Evaluates request 2) Gets additional information 3) Issues cards (result or links) 4) If PA required , sends SMART on FHIR link and context Context with Access Token 2) Access Patient Record Provider Initiates App optional 3) Return CARD(s) SMART on FHIR Application 1) Get Payer PA Rules (CQL) 2) Retrieve information 3) Query missing information (SDC) 4) Evaluate PA requirements 5) If pass, issue PAN and return to payer 6) Return results of PA to payer Optional link to SMART App 5) Send documentation and PA rules 4) Get Payer PA Rules 5) Return result of PA 6) Receive result of PA 19

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

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) 21

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

CRD + DTR + Prior-Authorization Support

Provider does not have the necessary information to answer the PA documentation request

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

Payer is unable to make a PA determination in real-time

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

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

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

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)

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

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

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

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

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

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

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)

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

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

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 40

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) 41

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 retrieve 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 42

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)

Cross Functional Drawing

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 45

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 46

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

DTR / Order Flow

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.

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

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

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

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

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)

Prior-Authorization Support

Similar presentations

Presentation on theme: "Prior-Authorization Support"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Prior-Authorization Support

Similar presentations

Presentation on theme: "Prior-Authorization Support"— Presentation transcript:

Similar presentations

About project

Feedback