Prior-Authorization Support March 8, 2019 Interim Antitrust Policy

Prior-Authorization Support March 8, 2019 Interim Antitrust Policy

Prior-Authorization Support March 8, 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. ANSIs 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 March 8, 2019 Discussion of impact of CMS and ONC NPRM Scope of Interaction with Provider Overall work flow options Discussion of information required for Payer processing Use of Claim resource and next steps 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 ASC X Any Method

Payer 1 12N 278 /27 5 FHIR 2 FHIR ASC X12N 278/275 ASC X12N 278/275 Any Method FHIR Payer 2 Use Case Alignment Chronic Illness Documentation for Risk Adjustment Use Case Status In HL7 ballot reconciliation as draft standard Under active development Active development (use case support) Patient Cost Transparency Performing Laboratory Reporting Prior-Authorization Support Documentation Templates and Coverage Rules (DTR) Coverage Requirements Discovery (CRD)

Risk Based Contract Member Identification 2019 use cases Use cases in discovery Gaps in Care & Information Health Record Exchange: Clinical Data Exchange (CDex) Health Record Exchange: Payer Data Exchange (PDex) Health Record Exchange: Framework (HRex) Additional Quality Measures Data Exchange for Quality Measures Framework (DEQM) 5 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: 1) Gathers prior-authorization information from the medical record 2) Determines gaps in the record that represent information necessary for priorauthorization approval 3) Prompts the provider for the additional information (where appropriate) 4) Triggers a prior-authorization submission and waits for a return message CRD + DTR + Prior-Authorization Support Cross Functional Flow Chart (PA Version with X12 transaction receipt by payer)

(Alternative is conversion back to FHIR prior to receipt by payer) Clearinghouse or BA Offi ce/Hospital EHR (2) Invokes service & sends pre-fetch FHIR data including order information (1) DME Ordered order-reviewhook triggers query Payer / Contractor / Benefit Manager (3) CDS Service searches repository leveraging FHIR data, evaluates coverage criteria CDS Hooks FHIR/Supported Txn Payer/Plan Supplier (4b) Eligibility, Provider/ Supplier Enrolmment, Claims Part of CRD (4a)

Library of Coverage rules / templates (7) Display gaps/template/ rule and collect missing data and store as part of the medical record (6) Retrieve rules if necessary, Parse rule from CQL, identify gaps in data available in EHR, populates template(s) CDS CARDS CDS Integration into Internal Sysems (5) Send CDS Hooks Response with PA requirement and link to smart template Required for Prior Authorization CQL / FHIR / SMART (8) Gathers all information for PA and sends it directly or via intermediary to payer -- returns PAN, Pend, Deny (9) Optional Intermediary to convert to ASC X12N 278/275

FHIR ASC X12N (10) Computer Assisted Prior Authorization Engine Conversion to meet HIPAA (11) PA Record Required for DME eRx ASC X12N PA Complete PAN Issued (12) Optional action a) order Service b)Provide PAN with order (15) Order placed to supplier PA Complete PAN Issued * PAN Prior Authorization Number Existing EMR Order Process (13) Places order to supplier Direct, FHIR, HL7 V2, eHealth Exchange, Fax Direct, FHIR, HL7 V2, eHealth Exchange, Fax

(14) End (16) End CRD + DTR + Prior-Authorization Support Cross Functional Flow Chart (PA Version with X12 transaction receipt by payer) (Alternative is conversion back to FHIR prior to receipt by payer) Clearinghouse or BA Offi ce/Hospital EHR (2) Invokes service & sends pre-fetch FHIR data including order information (1) DME Ordered order-reviewhook triggers query Provider does not have the necessary information to answer the PA documentation request Payer / Contractor / Benefit Manager (3) CDS Service searches repository leveraging FHIR data, evaluates coverage criteria CDS Hooks FHIR/Supported Txn Payer/Plan

Supplier (4b) Eligibility, Provider/ Supplier Enrolmment, Claims Part of CRD (4a) Library of Coverage rules / templates (7) Display gaps/template/ rule and collect missing data and store as part of the medical record (6) Retrieve rules if necessary, Parse rule from CQL, identify gaps in data available in EHR, populates template(s) CDS CARDS CDS Integration into Internal Sysems (5) Send CDS Hooks Response with PA requirement and link to smart template Required for Prior Authorization CQL / FHIR / SMART (8)

Gathers all information for PA and sends it directly or via intermediary to payer -- returns PAN, Pend, Deny (9) Optional Intermediary to convert to ASC X12N 278/275 FHIR ASC X12N (10) Computer Assisted Prior Authorization Engine Conversion to meet HIPAA (11) PA Record Required for DME eRx ASC X12N PA Complete PAN Issued (12) Optional action a) order Service b)Provide PAN with order (15) Order placed to supplier PA Complete PAN Issued

* PAN Prior Authorization Number Existing EMR Order Process (13) Places order to supplier Direct, FHIR, HL7 V2, eHealth Exchange, Fax Direct, FHIR, HL7 V2, eHealth Exchange, Fax (14) End (16) End 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 CRD + DTR + Prior-Authorization Support Cross Functional Flow Chart (PA Version with X12 transaction receipt by payer) (Alternative is conversion back to FHIR prior to receipt by payer) Clearinghouse

or BA Offi ce/Hospital EHR (2) Invokes service & sends pre-fetch FHIR data including order information (1) DME Ordered order-reviewhook triggers query Payer / Contractor / Benefit Manager (3) CDS Service searches repository leveraging FHIR data, evaluates coverage criteria CDS Hooks FHIR/Supported Txn Payer/Plan Supplier (4b) Eligibility, Provider/ Supplier Enrolmment, Claims Part of CRD (4a) Library of Coverage rules /

templates (7) Display gaps/template/ rule and collect missing data and store as part of the medical record (6) Retrieve rules if necessary, Parse rule from CQL, identify gaps in data available in EHR, populates template(s) CDS CARDS CDS Integration into Internal Sysems (5) Send CDS Hooks Response with PA requirement and link to smart template Required for Prior Authorization CQL / FHIR / SMART (8) Gathers all information for PA and sends it directly or via intermediary to payer -- returns PAN, Pend, Deny (9) Optional Intermediary to convert to ASC X12N 278/275 FHIR

ASC X12N (10) Computer Assisted Prior Authorization Engine Conversion to meet HIPAA (11) PA Record Required for DME eRx ASC X12N PA Complete PAN Issued (12) Optional action a) order Service b)Provide PAN with order (15) Order placed to supplier PA Complete PAN Issued * PAN Prior Authorization Number Existing EMR Order Process (13) Places order to supplier Direct, FHIR, HL7 V2, eHealth Exchange, Fax Direct, FHIR, HL7 V2, eHealth Exchange, Fax (14) End

(16) End 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 A) Ask if want to initiate SMART on FHIR PA app 1) Option: Queue as task for someone else in practice (configurable by practice/practitioner/ type of service) 2) Option: what to do if need to submit information to servicing provider to submit PA (interesting workflow considerations) 1) Web Service, HIE, EHR to EHR, patient cloud 2) Need to provide guidance for each workflow (Ordering, Servicing, either /or) B) If all information is available 1) 2) 3) 4) Need to review, since attesting to information -- option to sign Option to submit Option to cancel Option to queue for someone else to submit C) 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

Providers Medical Records Telephone Portals Payers 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 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 X 12N 278 /27 5 Payer 1 2 Any Method 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 X

12N 278 /27 5 Payer 1 2 B A Any Method 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 ASC X Payer 1 12N 278 /27 5 2 B A Any Method

ASC X12N 278/275 Per the reqs (i.e. 162.923 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 Payer 2 Challenge Must be ASC X12N 278 (PA request) / 275 (attachment with CDA) May be any method (including ASC X12N) X Any Method EHR 1 ASC X12 N y An 278 /27 5 2 d tho e M Payer 1 Any Method Payer 2 Most EHRs do not directly support ASC X12N 278 / 275 Challenge Must be ASC X12N 278 (PA request) / 275 (attachment with CDA)

May be any method (including ASC X12N) X Any Method Pat Adm/ Pat Adm/ Practice Practice Mgmt./ BA Mgmt./ d tho e M Payer 1 d N y An 278 /27 5 ho N C AS 2N X1 5 27 / 8 27 ASC X12

N 2 An yM et EHR 1 N Usually not Real-time for PA / attachments Any Method Payer 2 Only 8% of PA and < 6% of attachments are electronic end to end (based on 2017 CAQH INDEX Report) Payer 2 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 FHIR API FHIR Any Met ho d d t ho e yM An FHIR API

FHIR API ASC X12N 278/275 R FHI R FHI FHIR API FHIR API y An th Me od Any Met ho FHIR Payer 1 d FHIR API Payer 2 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 ASC X Payer 1 12N 278 /27 5 FHIR 2 FHIR ASC X12N 278/275 Any Method Any Method FHIR Payer 2 2019 Use Case Status Data Exchange for Quality Measures Coverage Requirements Discovery Health Record Exchange: Clinical Data Exchange Health Record Exchange: Payer Data

Exchange Gaps in Care & Information Risk Based Contract Member Identification Documentation Templates and Coverage Rules Prior-Authorization Support Alerts: Notification (ADT), Transitions in Care, ER admit/discharge 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 Use Case Status In HL7 ballot reconciliation as draft standard Under active development Performing Laboratory Reporting Chronic Illness Documentation for Risk Adjustment Patient Cost Transparency 2019 use cases Use cases in discovery 24 Use Case Alignment

Chronic Illness Documentation for Risk Adjustment Use Case Status In HL7 ballot reconciliation as draft standard Under active development Active development (use case support) Patient Cost Transparency Performing Laboratory Reporting Prior-Authorization Support Documentation Templates and Coverage Rules (DTR) Coverage Requirements Discovery (CRD) Risk Based Contract Member Identification 2019 use cases Use cases in discovery Gaps in Care & Information Health Record Exchange: Clinical Data Exchange (CDex) Health Record Exchange: Payer Data Exchange (PDex) Health Record Exchange: Framework (HRex) Additional Quality Measures

Data Exchange for Quality Measures Framework (DEQM) 25 2. Coverage Requirements Discovery (CRD) SUMMARY Low Complexity 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 Category Effort Medium Complexity Medium Time to Ref Imp 3-6 mo Source/HL7 WG Finance CDS-Hooks 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)

Level of Effort FHIR Fitness Good Standards Dev Scope (including IG) Easy Implementation Challenges Medium 26 Coverage Requirements Discovery Provider 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) Order Procedure, Lab or Referral Discover Any Requirements Payer Cross Functional Drawing Cross Functional Flow Chart (Coverage Requirements Discovery Shared Library) Provider EHR

(1) Provider places order (2) Invokes service & sends pre-fetch FHIR data including order information and OAuth token to appropriate payer endpoint Hook Invocation (6) Patient EHR record as allowed by provider/patient Payer CDS Payer(s) (3) CDS Service searches repository leveraging FHIR data CDS Hooks Yes REST GET of additional FHIR resources using OAuth Token (5) Is more information required? (4) Library of coverage rules / templates (Multi-tenant library based on ARQHs

CDS Connect Repository) No (9) Provider interaction with CARD CARDS (8) Receives CARDS, Action depends on Card type and content (A) Payer provides specific rules and artifacts for pilot services Provider Interaction (An) Payer n provides specific rules and artifacts for pilot services CDS Hooks EHR workflow Additional patient record queries using the Oauth token CARDS (7) Send CARDS with text, links or FHIR resources Provider / EHR retrieves the suggested

artifact CDS Setup (11) Provider interaction with retrieved artifact (10) Retrieves template, rules, application as appropriate CQL / FHIR / SMART Documentation Requirements Look-up Service (DRLS) Based on a specific clinical workflow event: scheduling start of encounter ordering or planning treatment discharge A P I PROVIDERS Is there a requirement for PA or specific documentation YES OR NO EHR ELECTRONIC HEALTH RECORD A P I GIVE ME THE TEMPLATES / RULES ** Payer 1 A

P I Payer 2 A P I PAYER 3 FHIR**-BASED EXCHANGE HERE ARE THE TEMPLATES / RULES DRLS is the CMS instantiation of the Da Vinci Coverage Requirements Discovery (CRD) use case 29 Graphic taken from the CMS Special Open Door Forum (SODF) presentation 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. Medium-High Complexity Category Level of Effort Effort Medium - High Complexity 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 High Time to Ref Imp 9-12 limited RI, 12-24 for all aspects Source/HL7 WG CQL, SDC, CDS-Hooks FHIR Fitness Good-Excellent Standards Dev Scope (including IG) Medium-Complex Implementation Challenges Medium-Complex Collect, in real-time, patient information to alert provider or care team 30 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 4. Rules determine missing information in patient record 1. Provider Places Order 7. Stores information in EHR System 2a. EHR send CRD request, order, and clinical context to DRLS 2b. CARDs return link to SMART on FHIR App and context 3a.SMART on FHIR App is initiated by the Provider/EHR 3b. SMART on FHIR App retrieves appropriate template and rules 8. Optionally, returns information to payer

Payer N Payers CDS Note: The SMART standard was created by Boston Childrens 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 MRP Medication Reconciliation Post-discharge Additional Measures for DEQM IG CDex Clinical Data exchange PDex Payer Data exchange HRex Framework Implementation Guide Interactions Push HRex Health Record exchange Other Artifacts FHIR Profiles (1) DSTU 2 Argonaut Pull Bundles STU 3 US Core and QI Core Request

Value Sets R4 US Core and QI Core Subscribe Mappings Non-US Core 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 Validation Access Control/Audit Examples CIMI Extensions Notes: 1) Existing work is adopted by reference Relationship of HRex Implementation Guides HRex Framework Implementation Guide CDex Implementation Guide Clinical Data exchange

PDex Implementation Guide Payer Data exchange Exchange between Provider and Provider or Payer 1) 2) Define clinical exchange scenarios (exemplary of a type) a) Order and supporting documentation b) Lab results (clinician to clinician) b) Hospital discharge For each scenario (and FHIR version) a) Identify appropriate interaction(s) i. Query parameters (if appropriate) b) Identify appropriate profiles c) Define appropriate bundles d) Define constraints 1) 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 2) Define payer data sources (exemplary of a type) a) Claims/EOB (using intermediate structure) b) PBM/Meds c) Laboratory / Alerts d) Med record (e.g. CDA) based For each scenario (and FHIR version) a) Identify appropriate interaction(s) i. Query parameters (if appropriate) b) Identify appropriate profiles c) Define appropriate bundles d) Define constraints CRD + DTR + Prior-Authorization Support Cross Functional Flow Chart (PA Version with X12 transaction receipt by payer) (Alternative is conversion back to FHIR prior to receipt by payer) Clearinghouse

or BA Offi ce/Hospital EHR (2) Invokes service & sends pre-fetch FHIR data including order information (1) DME Ordered order-reviewhook triggers query Payer / Contractor / Benefit Manager (3) CDS Service searches repository leveraging FHIR data, evaluates coverage criteria CDS Hooks FHIR/Supported Txn Payer/Plan Supplier (4b) Eligibility, Provider/ Supplier Enrolmment, Claims Part of CRD (4a) Library of Coverage rules /

templates (7) Display gaps/template/ rule and collect missing data and store as part of the medical record (6) Retrieve rules if necessary, Parse rule from CQL, identify gaps in data available in EHR, populates template(s) CDS CARDS CDS Integration into Internal Sysems (5) Send CDS Hooks Response with PA requirement and link to smart template Required for Prior Authorization CQL / FHIR / SMART (8) Gathers all information for PA and sends it directly or via intermediary to payer -- returns PAN, Pend, Deny (9) Optional Intermediary to convert to ASC X12N 278/275 FHIR

ASC X12N (10) Computer Assisted Prior Authorization Engine Conversion to meet HIPAA (11) PA Record Required for DME eRx ASC X12N PA Complete PAN Issued (12) Optional action a) order Service b)Provide PAN with order (15) Order placed to supplier PA Complete PAN Issued * PAN Prior Authorization Number Existing EMR Order Process (13) Places order to supplier Direct, FHIR, HL7 V2, eHealth Exchange, Fax Direct, FHIR, HL7 V2, eHealth Exchange, Fax (14) End

(16) End 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: 1) Gathers prior-authorization information from the medical record 2) Determines gaps in the record that represent information necessary for priorauthorization approval 3) Prompts the provider for the additional information (where appropriate) 4) 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)

Recently Viewed Presentations

  • Lucky Seven Try your luck on this question

    Lucky Seven Try your luck on this question

    Lucky Seven Try your luck on this question Nine of the vertebrate classes are fish. List them. TWO MINUTES Subtitle Goes Here. Lucky Seven
  • School Improvement Planning and your Title I, Part

    School Improvement Planning and your Title I, Part

    Instructional staff will implement Lucy Calkins Writing Strategies. Instructional staff will be provided professional development on the implementation of Lucy Calkins Writing Strategies. Title I Instructional staff will provide an extra45 minutes/day of reading instruction to students scoring in the...
  • USC Brain Project Specific Aims

    USC Brain Project Specific Aims

    Computational Architectures in Biological Vision, USC, Spring 2001 Lecture 12. Visual Attention Reading Assignments: None Several Forms of Attention Attention and eye movements: - overt attention (with eye movements) - covert attention (without eye movements) Bottom-up and top-down control: -...
  • The Tomb is not empty! Easter Service st

    The Tomb is not empty! Easter Service st

    Forgiveness. Hope. Easter Service. April 21. st. 6pm. 20640 Chapel Dr, Chugiak, AK, 99567. What is the most important relational Word? Jesus went from Womb to Tomb. He was born to die for us. He lived so He could Atone....
  • LA 10 November 3, 2014 Upcoming events: 11.03.12

    LA 10 November 3, 2014 Upcoming events: 11.03.12

    Install Grammarly app. Type final copy of EA 1.2. Essay should be 6-7 paragraphs. Be sure to quote the stories as support and write (author, pg#) in parenthesis after quote. You'll also need a title page (name, title of document,...
  • Spelling: Doesn&#x27;t

    Spelling: Doesn't

    Ing " Words (Verbs). Example: Running, throwing, skirting etc. Words that end in 'ing' generally these indicate an action (verbs) C = Connectives. Example: Next to, However, Firstly, Secondly, Also, Comparatively. Connectives are words that link sentences, when used at...
  • Présentation PowerPoint

    Présentation PowerPoint

    Les Super Modèles au début des années 90, avec Linda Evangelista-Naomi Campbel et Christy Turlington. Reine des Podiums pour les. couturiers : Thierry Mugler. Dolce & Gabbana. Versace. Chanel. Raph Lauren. Ici en tenue choc en compagnie. de Naomi en...
  • WELCOME TO THE FACULTY OF BEHAVIOURAL, MANAGEMENT AND

    WELCOME TO THE FACULTY OF BEHAVIOURAL, MANAGEMENT AND

    Your studies at The Faculty of Behavioural, Management and Social Sciences (BMS) - Among a wide diversity of students, - in an international atmosphere, - with a focus on High Tech, Human Touch,