1 HIT Policy & Standards Committee Enrollment Workgroup Update Aneesh Chopra, Chair Chief Technology Officer, OSTP Sam Karp, Co-Chair California Healthcare.

1

HIT Policy & Standards CommitteeHIT Policy & Standards CommitteeEnrollment Workgroup UpdateEnrollment Workgroup Update

Aneesh Chopra, ChairAneesh Chopra, ChairChief Technology Officer, OSTPChief Technology Officer, OSTP

Sam Karp, Co-ChairSam Karp, Co-ChairCalifornia Healthcare FoundationCalifornia Healthcare Foundation

July 21, 2010

2

Workgroup Members• Chair: Aneesh Chopra, Federal CTO

• Co-Chair: Sam Karp, California Healthcare Foundation

Members: Ex Officio/Federal:• Cris Ross SureScripts Sharon Parrott, O/S, HHS• James Borland Social Security Administration Nancy DeLew, HHS• Jessica Shahin U.S. Department of Agriculture Penny Thompson, CMS/HHS• Stacy Dean Center on Budget & Policy Priorities Henry Chao, CMS/HHS• Steve Fletcher CIO, Utah Gary Glickman, OMB• Reed V. Tuckson UnitedHealth Group John Galloway, OMB• Ronan Rooney Curam David Hale, NIH• Rob Restuccia Community Catalyst Paul Swanenberg, SSA• Ruth Kennedy Louisiana Medicaid Department David Hansell, Administration for• Ray Baxter Kaiser Permanente Children & Families, HHS• Deborah Bachrach Consultant Julie Rushin, IRS• Paul Egerman Businessman Farzad Mostashari,

ONC• Gopal Khanna CIO, Minnesota Doug Fridsma, ONC• Bill Oates CIO, City of Boston Claudia Williams, ONC• Anne Castro Blue Cross/Blue Shield South Carolina• Oren MichelsMashery• Wilfried Schobeiri InTake1• Bryan Sivak CTO, Washington, DC• Terri Shaw Children’s Partnership• Elizabeth Royal SEIU• Sallie Milam West Virginia, Chief Privacy Officer• Dave Molchany Deputy County Executive, Fairfax County

3

Keep Principles in Mind • Keep it simple - Think big, but start small. Recommend standards as minimal as

required to support necessary policy objective/business need, and then build as you go.– Don’t rip and replace existing interfaces that are working (e.g., with SSA etc.) – Advance adoption of common standards where proven through use (e.g., 270/271).

• Don’t let “perfect” be the enemy of “good enough” Go for the 80 percent that everyone can agree on. – Opportunity to standardize the core, shared data elements across programs.– Cannot represent every desired data element.

• Keep the implementation cost as low as possible – May be possible to designate a basic set of services and interfaces that can be built

once and used by or incorporated by states. – Opportunity to accelerate move to web services

• Do not try to create a one-size-fits-all standard that add burden or complexity to the simple use cases– Opportunity to describe data elements and messaging standards that would be

needed regardless of the architecture or precise business rules selected.

3

Enrollment Workgroup Update

• Three workgroup meetings held• Tiger Teams activated

– Verification Interfaces – Business Rules – Plan/Benefit Handoffs– Privacy and Security

• NIEM Data Harmonization Project underway• FACA Blog and other feedback received

5

Verification Interfaces Tiger Team Charge

• Provide “strawman” recommendations on:– Modernizing verification interfaces– Requirements for a possible verification interface

service

6

Verification Sources Required by ACA

• Section 1411 requires that individual eligibility for exchange coverage be verified through interfaces with various federal data sources:– IRS (income)– Homeland Security (legal residence)–Social Security Administration (citizenship)

7

Verification Interfaces Recommendations1. ACA required verifications are the base verifications 2. Verification interfaces should:

• Provide real-time verification • Use Web Services• Use NIEM compliant exchanges, where possible• Incorporate/utilize a read and write translation service to

support data exchange with legacy systems and in different formats (e.g., HL7, XML, etc.)

3. Data associated with verification interfaces should be: • Disaggregated by individual rather than household• Re-usable for other eligibility decisions: • “Cleansed” and “ranked” using an algorithmic approach to

eliminate duplicate matches and identify most reliable information

8

Verification Interfaces Recommendations (cont.)

4. Develop verification service construct– Allow for an open development concept to promote continuous innovation.

• Start with base services, which are updated and improved• Provide web service constructs and boundaries to the development

community• Notify states of updated services, service constructs and boundaries

– Can be used as a service by Federal and State Exchanges, Medicaid and other programs

– The GOAL: Build it once, not 50+ times

9

Business Rules Tiger Team Charge

• Provide “strawman” recommendations to ensure easier development and modernization of new and existing systems:– Standard formats and/or tools that can be used to

consistently express eligibility processes and rules across states

– Taking into consideration the interrelationship of the security, verifications and data standards groups (including NIEM data mapping work)

10

Business Rules Recommendations

1. The goal of adopting consistent expression of business rules is to:– Provide for more efficient updates and modifications, and

adding additional programs– Minimize maintenance– Allow for scalability, which must also address performance

considerations2. Rules and resulting eligibility decisions must be

understandable , clear and, to the extent possible, standardized in expression so that eligibility decisions can be communicated to participants (consumers), and so that developers can rapidly and efficiently develop systems

10

11

Business Rules Recommendations

3. Business rules standards for the Enrollment Workgroup should: – Support the augmentation of current state systems (i.e.,

no “ripping and replacing” or forced march to “standard rules”)

– Provide standards and constructs that accelerate states’ ability to support ACA

– “Buffer” the impact of imperfect information and data, where possible

– Serve as an initial step, approach and guidance for the modernization of state eligibility and enrollment systems

11

Business Rules Recommendations (cont.)

1212

13

Plan/Benefit Handoff Tiger Team Charge

• Identify key data elements needed for data exchange between health plans, Medicaid and State/Federal Exchanges

• Explore approaches for streamlined bi-directional data exchange and recommend standards where appropriate

13

14

Assumptions

• Information transfers to the plan AFTER eligibility is determined

• Coverage periods / effective dates are contingent upon certain policy decisions not in the purview of HIT Work Group

• Consumer plan choice will be sent to the plan

14

15

Plan/Benefits Recommendations

1. Existing HIPAA standards 834, 270, 271 will provide necessary framework to conduct effective operations

2. These standards handle common identified data elements 3. Race/ethnicity and primary care provider are handled by

8344. Need to address consumer communication re: changes in

eligibility / coverage status

15

16

Privacy and Security Tiger Team Charge

• Provide strawman recommendations on: – Application of fair information practices, including purpose

limitation/re-use– Security safeguards (authentication, secure transport,

audit logs)

17

Privacy and Security Recommendations

Address fair information practices in new and existing eligibility and enrollment systems to safeguard consumer information

Collection Limitation– Collect the minimum data necessary for enrollment and eligibility,

taking into consideration desire to collect information once and reuse information

Data Integrity & Quality– Access to real-time data/mechanisms to maintain data accuracy– Explore alternatives to using SSN as applicant/enrollee identifier and

data matching field– Establish threshold level for matches, use advanced probabilistic

matchingAccountability and Oversight

– Clear, transparent policies about authorizing access, use of data provided to the enrollee

18

Privacy and Security Recommendations

Purpose Specification/Use Limitation - Purpose for which information will be used should be specified

and communicated to consumer- Notice must be made prior to sending data or at least

simultaneous with the sending of data in a method consumers can understand

- The privacy Notice will indicate all organizations permitted to use data and specify purpose – public health plans, public social service agencies, private health plans

• Organizations listed in privacy notice can also reuse data for purpose specified

• Not appropriate to list employers in Notice• Data sharing agreements govern requirements for re-use and

secure transport. Easiest to negotiate in a consumer mediated model. More challenging with other organizations not recognized in data sharing agreements.

19

Privacy and Security Recommendations

Individual Control and Participation – Consumer able to reuse own information for additional

enrollments (Blue Button)– Consumer able to correct/update personal information– Consent to use for enrollment implied for program consumer

has applied for, including subsequent eligibility checks– Any additional use not specifically listed in Notice needs

additional consent by Consumer

20

Eligibility Enrollment Data Harmonization Overview

Task Objectives: Inventory core enrollment data elements across state health and human service

programs and existing data standards resources Identify commonalities among enrollment data elements in order to support the

long-term goal of facilitating electronic exchange of information across health and human service programs

Health and Human Services Programs

Core Data Elements Existing Data Standards

• Health Insurance Exchange • Medicaid• CHIP• SNAP• TANF• EITC

• Date of Birth • Social Security • Gender• Income • Citizenship • Legal Status • Address• Incarceration• Household Composition

• NIEM • HL7

21

Enrollment Data Harmonization Process

Identify ProgramsIdentify Programs

Identify Data Elements

Identify Data Elements

Step 1: Define Scope Step 1: Define Scope Step 3: HarmonizeStep 3: Harmonize

Review FindingsReview Findings

Harmonize Data Definitions

Harmonize Data Definitions

Refine Data AnalysisRefine Data Analysis

Step 2: Data AnalysisStep 2: Data Analysis

Identify Data Analysis Criteria

Identify Data Analysis Criteria

Collect Data DetailsCollect Data Details

Consolidate and Analyze Results

Consolidate and Analyze Results

Survey Existing Data Models

Survey Existing Data Models

22

Data Analysis Approach

Step 1: Identify and Define Data Analysis Criteria • Data Element Name – Label for each core data enrollment elements e.g., Address• Data Element Attribute – Concept or sub-concept(s) that make up the data element

e.g., Home Address and Mailing Address• Data Element Definition – Definition attributed by each data source e.g., Address

where you can be reached• Data Captured – Components of the address collected by the source e.g., street

address, city, state zipStep 2: Survey Existing Data Models

• Search for existing data standards in NIEM and HL7 that may help identify commonalities among enrollment data e.g., Address may be a potential map to Contact Mailing address, Location Address, Person Address, Postal Address, and/or Address Delivery Point

23

Data Analysis Approach cont.

Step 3: Collect Data Details• Start from the applicant’s

perspective by going through applications and documenting the information requested and the types of questions asked during the enrollment process to derive each data element detail

• See screen shot on right for example of Mailing Address collection

Step 4: Consolidate and Analyze Results

• Leverage SMEs to validate underlying business rules which aggregate details into a single core data element concept

• Identify commonalities among core data elements across state programs and against existing standards resources

24

Assumptions and Constraints• Current analysis includes six health and human service programs and nine

core enrollment data elements• Task goal is to standardize data concepts and definitions, not business rules

regarding how programs use these data elements • Anticipate variability in income and household composition definitions across

state programs – Require further insight from state program SMEs to understand how

income and household composition are derived from information collected during enrollment

• Anticipate further harmonization of income data element with MAGI standards once published

• Plan to collect data details from a sample set of state programs • Will leverage existing standards for electronic insurance enrollments to derive

concept details for Health Insurance Exchange • Limited information available regarding Earned Income Tax Credit (EITC) • Preliminary Data Analysis have a selection bias as sample states are using a

portal approach to determine eligibility across multiple programs

25

Overview of FACA Blog Responses

• 41 Blog Responses; 13 Responses via email• Lessons Learned from 11 States, including

– California, Oregon, New York, Arizona, Massachusetts, Michigan, Colorado, etc

• Voices from consumers, industry, associations• Feedback summary:

– Support for role standards play in simplification and use of multiple entry points

– View data standardization as better supporting enrollment across programs

– Support for use of electronic verifications; caution about currency and completeness of data and need for clarity about data use

– Encouragement for innovation, use of the Web, and shared business services