hitsp capabilities public review webinar hitsp communicate referral authorization capability public...

HITSP Capabilities Public Review Webinar

HITSP Communicate Referral Authorization Capability Public Review

Administration and Finance Domain Technical Committee

October 1, 2009

1


HITSP Communicate Referral Authorization Capability Requirements and Design Public Comment Introduction

Schedule

Review of Capabilities

Technical Approach

Public Comment

2


HITSP Communicate Referral Authorization Capability Requirements and Design Public Comment

Introduction

Schedule


Technical Approach

Public Comment

3


Introduction The purpose of this Webinar is to provide a high-level overview of

a HITSP proposed solution for exchanging prior-authorization information between a Pay Benefits Manager and a Provider or Pharmacy

Today we will be discussing the requirements section of the document. The capability and all associated HITSP constructs will be released for the traditional 4 week public comment period in early November

4


Introduction – Co-Chairs and Staff

Staff/Co-Chair Contact Information

Don Bechtel [email protected]

Durwin Day [email protected]

Manick Rajendran [email protected]

5

Providing specifications that integrate diverse standards to meet clinical and business needs for sharing information:

1. Develop specifications that address broad stakeholder perspectives

2. Support testing and validation of specifications

3. Catalyze efforts of standards organizations to realize changes to address gaps and overlaps

Enabling Interoperability between healthcare stakeholders

Healthcare Information Technology Standards Program (HITSP)

Specifying Standards needed to enhance care quality and contain costs

6HITSP Capabilities Public Review Webinar

Base or Composite Standards

Constructs(single purpose

or reusable)

Interoperability Specification (construct)

Type 1: Base or Composite StandardsHITSP Interoperability Specifications

A complete IS set provides a framework that defines□ A hierarchy of constructs□ The role of each construct □ The relationship of one

construct to another in the context of specific business and/or clinical requirements

Interoperability Specification (Complete Set)


Capabilities and Service Collaborations

HITSP Capabilities Public Review Webinar 8

Keys to Simpler Definition and Implementation of HITSP Specifications

Service Collaboration (SC)

□ Defines a standards-based secure infrastructure needed for interoperable information exchanges

□ Includes a secure transport mechanism with topology and other options

□ Uses HITSP Constructs to specify the secure infrastructure□ Does not specify the content of the information exchange but may

include information to support the exchange (e.g., authorization information)


Patient Identification

Email address/

distribution list

TopologySystem-to-SystemPortable MediaSystem-to-HIEHIE-to-HIE

ServiceCollaboration

Standards-based Secure Infrastructure Needed for Interoperable Information Exchanges


Delivery notification

Patient consent Management

Service Collaborations

□ SC108 - Access Control □ SC109 - Security Audit□ SC110 - Patient Identification Management□ SC111 - Knowledge and Vocabulary□ SC112 - Healthcare Document Management□ SC113 - Query for Existing Data □ SC114 - Administrative Transport to Health Plan □ SC115 - HL7 Messaging□ SC116 - Emergency Message Distribution Element


HITSP Capability

□ Enables systems to address a business need for interoperable information exchange

□ Bridges between business, policy and implementation views:– Defines a set of information exchanges at a level relevant to

policy and business decisions – Supports stakeholder requirements and business processes – Defines information content and secure infrastructure– Specifies use of HITSP constructs sufficiently for implementation – Includes constraints and identifies specific network topologies


What is an example of a capability?

Requirement: An organization wants to exchange a prescription with an ambulatory organization

The diagram on the right shows how Capability 117 was assembled to support this requirement

CAP117 – Communicate Ambulatory and Long Term Care Prescription

System Roles• Medication Order

Prescriber• Medication Order Filler• Health Plan• Health Information

Exchange (HIE)

I want to exchange a prescription with an Ambulatory or Long-Term Care (LTC) Organization


Existing HITSP Capabilities – Clinical Operations

Clinical OperationsCommunicate Ambulatory and Long Term Care Prescription - CAP117

Communicate Hospital Prescription - CAP118

Communicate Clinical Referral Request - CAP121

Retrieve Genomic Decision Support - CAP125

Communicate Lab Results Message - CAP126

Communicate Lab Results Document - CAP127

Communicate Imaging Information - CAP128

Retrieve and Populate Form - CAP135

Communicate Encounter Information Message - CAP137


Existing HITSP Capabilities – Public Health and Emergency Response; Administration and Finance

Administration and Finance

Communicate Benefits and Eligibility - CAP140

Communicate Referral Authorization - CAP141

Public Health and Emergency Response

Communicate Quality Measure Data - CAP129

Communicate Quality Measure Specification - CAP130

Update Immunization Registry - CAP131

Retrieve Immunization Registry Information - CAP132

Communicate Immunization Summary - CAP133

Communicate Emergency Alert - CAP136

Communicate Resource Utilization - CAP139


Existing HITSP Capabilities - Security, Privacy, and Infrastructure

Security, Privacy, and InfrastructureCommunicate Structured Document - CAP119

Communicate Unstructured Document - CAP120

Retrieve Medical Knowledge - CAP122

Retrieve Existing Data - CAP123

Establish Secure Web Access - CAP124

Retrieve Pseudonym - CAP138

Retrieve Communications Recipient - CAP142

Manage Consumer Preference and Consents - CAP143


Patient Identification

Email address/ distribution list

TopologySystem-to-SystemPortable MediaSystem-to-HIEHIE-to-HIE

Patient consent Management

Marrying Content Definition with Secure Infrastructure for a set of Interoperable information exchanges

Delivery notification

Capability

ServiceCollaboration

Defining ContentComponent Service

Collaboration




Introduction

Schedule


Technical Approach

Public Comment

18


Schedule Requirements for Prior-Authorization introduced to the Public via

Webinar October 1st

Comment feedback on the Requirements for this work item closes October 8th – The process for submitting comments is included on slide 46 of

this presentation The Capability with all supporting constructs will be released for a 4

week Public Comment period in early November

19



Introduction

Schedule


Technical Approach

Public Comment

20


Definition of Capabilities Capabilities provide the ability for two or more systems to address a

business need for interoperable information exchange The objective is to provide the bridge between the business, policy

and implementation disciplines by:– Defining a set of information exchanges at a level relevant to

policy and business decisions – Supporting stakeholder requirements and business processes

by including information content, infrastructure, Security, Privacy– Specifying the use of HITSP constructs sufficiently for

implementation– Including constraints and operating on specific network

topologies (contexts) Capabilities have topology and other options (e.g., point-to-point,

portable media, system-to-HIE, HIE-to-HIE)

21


What is a capability? Capabilities are specified using

HITSP Constructs As part of the HITSP Tiger Team

effort addressing ARRA, Capabilities are meant to clearly state what types of data HITSP can and cannot “exchange”

During the ARRA Tiger Team effort, no new standards were selected, and no new constructs were specified to build capabilities

Requirements

Capability

SystemRoles

HITSPConstructs

Orchestration of HITSP Constructs and System Roles

22



Introduction

Schedule


Technical Approach

Public Comment

23


Technical Approach of Capability 141

High level review of the purpose of this capability Review of the requirements that have been defined

24

Purpose of Capability 141□ Addresses interoperability requirements that support electronic

inquiry and response for authorizing a health plan member to be referred for service by another provider or to receive a type of service or medication under the patient’s health insurance benefits.

□ The Capability supports: – Transmittal of a patient and insurance identification information– Identification of the type of service or medication requested for

benefit coverage– Communication of authorization number from the Payer System

□ It provides clinicians and pharmacists with information about each patient’s medical insurance coverage and benefits. It may include information on referral or authorization permission


Why The Capability Was Developed

□ Capability 141 was developed to enable: – Consumers and Providers to request prior-authorization for

medical related encounters and medications– Payors to respond to such requests– Payors to provide:

• Non-patient specific guidelines for prior-authorization• Patient specific guidelines for prior-authorization


Capability 141 Information Exchanges

Information Exchange Identifier

Exchange Action

Exchange Content ConstraintsInitiating Interface

Responding Interface

A Request & Response

HITSP/SC114 – Administrative Transport to Health Plan, andHITSP/EC68A – Health Plan Request

None 1, 3 2, 4

B Request & Response

HITSP/SC114 – Administrative Transport to Health Plan, and HITSP/EC68B – Health Plan Response

None 2, 4 1, 3

C Request & Response

HITSP/SC114 – Administrative Transport to Health Plan, and HITSP/EC79A – Health Plan Request

None 1, 3 2, 4

D Request & Response

HITSP/SC114 – Administrative Transport to Health Plan, and HITSP/EC79B – Health Plan Response

None 2, 4 1, 3


Service Collaborations Included in Capability 114

Manage Consent

Directives

Access Control

Secured Communic

ation Channel

Security Audit

Entity Identity

Assertion

Document Integrity

Non-Repudiation of Origin

De-identificati

on

Integrated Integrated Integrated Integrated Integrated NA NA Option


Uses HITSP/Service Collaboration 114 SC 114 contains the Security, Privacy, and Infrastructure

functionality depicted in the table below Also includes HITSP/T85 – Administrative Transport to Health

Plan T85 uses CAQH Phase II CORE #270 Connectivity Rule v2.0.0,

which addresses the message envelope metadata and envelope standards, submitter authentication standards , and communications-level errors, and acknowledgements

28

INFORMATION EXCHANGE OPTIONS

Topology Available or Not Option

Point-to-Point Available Direct

Point-to-Point* NA e-mail

Portable Media NA Portable Media

System-to-HIE Available System-to-HIE

HIE-to-HIE NA HIE-to-HIE


*NOTE: As the gaps are evaluated email will be reconsidered

29

Capability 141 Requirements

□ Detailed definition of the requirements, recommended solutions and identified gaps in the solutions may be found in Section 6 of the document

□ The following slides provide a high-level overview of the requirements


Consumer RequirementsFunctional Requirements IER Data

RequirementsAnalysis

A. The ability for consumers to participate in prior-authorization processes and information exchange

i. Consumers may need the ability to receive certain standardized payer or provider information related to prior-authorization within their PHR or similar systems. Examples include provider lists or eligibility coverage information for various services and frequency limitations

Gap

Gap

Gap

Provider List

Eligibility Information

Formulary and Benefits Information

ASC X12 does not currently support consumers as receiver

ASC X12 270/271 does not support consumer as receiver

Formulary and benefits information – Gap, not currently designed to interact with a consumer


Consumer Requirements

Functional Requirements IER Data Requirements

Analysis

A. The ability for consumers to participate in prior-authorization processes and information exchange

ii. Consumers may need the ability to use their PHR or similar systems to communicate prior-authorization information to provider and/or payer systems. Examples include supplying medical history or prior coverage information

Gap

A, B

Gap

Prior -AuthInformation

Medical History

Prior coverage information

There are no current standards available today that include the consumer business actor function

ASC X12 278 transaction may need additional functionality to support all medical history

Prior coverage is NOT part of prior-authorization. We are wondering if this really means Prior Coverage, which would be supported today by 278


Provider Requirements


Analysis

B. The ability for providers to access standardized prior-authorization information and to incorporate and/or use the information within an EHR or related system

i. The ability to receive non patient-specific prior-authorization information such as eligibility and reimbursement guidelines. Providers may receive more detailed information than the consumer for treatment, payment, and operations

A, B (Gap )

C, D (Partial Gap)

X12 does not support this function. Gap solution: Ask X12 to change 278 to allow health plan to send attachment of administrative guidelines. Alternative: Ask HL7 to develop a discrete CDA dataset for this purpose

T79 Pharmacy to Health Plan Authorization uses the NCPDP Telecommunication Standard for real-time PA requests, PA billings, PA inquiries for pharmacies. Gap solution: NCPDP Formulary and Benefit standard exchange might be enhanced




Analysis


ii. The ability to query for patient-specific prior-authorization criteria. The ability to review such information without actually submitting a prior-authorization request may reduce workflow disruption and help providers aid consumers in evaluating their treatment options

A, B (Partial Gap) C, D

T68 provides ASC X12 270/271 for eligibility/benefit inquiries. The eligibility transaction today cannot provide information about the P.A. criteria. It also does not provide alternative treatments.

T79 Pharmacy to Health Plan Authorization uses the NCPDP Telecommunication Standard for real-time PA requests, PA billings, PA inquiries for pharmacies




Analysis


iii. The ability to electronically submit patient-specific prior-authorization requests and related information to payers

A, B

C, D

CAP141 refers to T68 for provider obtaining prior authorization from the Payer. (no changes needed)

CAP141 refers to T79 for prescriber obtaining prior authorization from the PBM. (no changes needed)




Analysis


iv. The ability to request a modification or extension of a previously approved prior-authorization

A, B

C, D

CAP141 refers to T68 for provider obtaining prior authorization from the Payer. (no changes needed) CAP141 refers to T79 for prescriber obtaining prior authorization from the PBM. (no changes needed)




Analysis


v. Providers may need the ability to communicate prior-authorization information to another provider

A, B C, D

Supported by CAP141 with T68 transaction

Supported by CAP141 with T79 transaction

Need to determine the business need for a pharmacy-to-pharmacy exchange of PA information


Payor Requirements Functional Requirements IER Data

RequirementsAnalysis

C. The ability for payors to electronically communicate standardized prior-authorization information to provider and/or consumer systems

i. The ability to broadly disseminate certain types of non patient-specific information such as a list of eligible providers or different therapies. Medications may need prior-authorization and what types of accompanying information are typically needed for approval

A, B (Partial Gap)

A, B (Partial Gap)

A, B (Gap)

C, D

Provider List

Procedures or therapies

non patient-specific eligibility request by a consumer or provider

Medications P-A

T68 (ASC X12 274) supports a list of providers within a health plan

There is an X12 gap for showing alternate therapies, treatment

No standards available that include the consumer business actor function

T79 depends on HITSP/TP46-Medication Formulary and Benefits Information to provide formulary and benefit information


Payor Requirements


Analysis


ii. The ability to communicate patient-specific prior-authorization or eligibility information in response to consumer and/or provider queries

B, A (Partial Gap)

D, C (Partial Gap)

Eligibility Information

CAP141 refers to T68 for provider obtaining prior authorization from the Payer. The gap is support of the consumer

CAP141 refers to T79 for prescriber obtaining prior authorization from the PBM. The gap is support of the consumer


Payor Requirements


Analysis


iii. The ability to electronically receive prior-authorization request submissions from providers and/or consumers and to process these requests within payers or third party intermediary systems

B, A (Partial Gap) D, C (Partial Gap)

Prior-Authorization Information

CAP141 refers to T68 for provider obtaining prior authorization from the Payer. The gap is support of the consumer CAP141 refers to T79 for prescriber obtaining prior authorization from the PBM. The gap is support of the consumer


Payor Requirements


Analysis


iv. The ability to communicate a request for additional information such as clinical justification or treatment history in order to make a prior-authorization decision

B, A (Partial Gap) D, C (Partial Gap)

Diagnosis

Medical History

Medication History

CAP141 refers to T68 for provider which supports this function

CAP141 refers to T79 for prescriber which supports this function


Payor Requirements


Analysis


v. The ability to electronically communicate patient-specific prior-authorization decisions, co-payment, and co-insurance information to provider and/or consumer systems

B, A (Partial Gap)

D, C (Partial Gap)

CAP141 refers to T68 for provider obtaining prior authorization from the Payer. Co-payments and co-insurance information related to an approved P.A. request would not supported in X12 278

CAP141 refers to T79 for prescriber obtaining prior authorization from the PBM. The gap is support of the consumer. Can provide co-payment or co-insurance information at the patient level


Payor Requirements


Analysis


vi. Particularly in the event of a rejection, a payer may need the ability to communicate an explanation for a prior-authorization decision as well as to communicate information on alternative treatment options or an Advanced Beneficiary Notification (ABN)

B, A (Partial Gap)

D, C

T68 content would be an explanation of benefits or reason for denial. The gap is being able to communicate alternate treatment options for medical benefits

T79 for Pharmacy to Health Plan Authorization supports this


Payor Requirements


Analysis


vii. A payor may need the ability to communicate co-payment, co-insurance or other information related to patient responsibility for expenses

B, A

D, C

T68 supports this exchange. The Gap is for consumer

T79 - NCPDP Formulary and Benefit Standard supports the exchange of benefit information including PA information



HITSP Communicate Referral Authorization Capability Requirements and Design Public Comment Introduction

Schedule


Technical Approach

Public Comment

45


Comment Tracking System HITSP.org link: http://www.hitsp.org/public_review.aspx

Using the HITSP Comment Tracking System The HITSP Comment Tracking System allows registered authors to provide comments on documents that are undergoing public review or implementation testing. A unique user ID and password is required for each comment submitter

Please note that the Comment Tracking System closes at 5 PM Pacific Daylight Time on the final day of public review, October 8th

Current HITSP members:Submit comments by following the link above and entering your current user ID and password

New Users: Contact [email protected] for a user name and password to access the CTS

Add CommentRegister a NEW comment in the tracking system

View (My) CommentsView the status or disposition of a comment previously submitted

Please contact Hannah Zander ([email protected]) with any questions or problems with entering comments

46


Questions and Comments

Comments regarding the Requirements outlined to meet the needs of Communicate Referral Authorization are welcome during this portion of the Webinar

Comments regarding the complete Capabilities documents can be addressed via Comment Tracking System (see previous slide for instructions)

47

hitsp capabilities public review webinar hitsp communicate referral authorization capability public...

Documents

week public comment

optionsuses hitsp constructs

associated hitsp constructs

diverse standards

validation of specifications

secure infrastructuredoes

requirements section

secure transport mechanism