HIT Policy & Standards Committee Enrollment Workgroup Update

1. HIT Policy & Standards CommitteeEnrollment Workgroup Update Aneesh Chopra, Chair Chief Technology Officer, OSTP Sam Karp, Co-Chair California 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 Michels Mashery 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

4. 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 Recommendations • ACA required verifications are the base verifications • 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.) • 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 • 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 considerations • 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

12. Business Rules Recommendations (cont.) • 4. The standards must support a consistent expression of rules along a continuum of implementation modalities, including: • Modifying or enhancing existing (Legacy) systems • Developing new systems • Adapting an approach of leveraging the assets of a legacy system while providing a user- friendly web-based interface for consumers

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 • Existing HIPAA standards 834, 270, 271 will provide necessary framework to conduct effective operations • These standards handle common identified data elements • Race/ethnicity and primary care provider are handled by 834 • 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 matching Accountability 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 • Health Insurance Exchange • Medicaid • CHIP • SNAP • TANF • EITC Core Data Elements • Date of Birth • Social Security • Gender • Income • Citizenship • Legal Status • Address • Incarceration • Household Composition Existing Data Standards • NIEM • HL7

21. Enrollment Data Harmonization Process Step 1: Define Scope Step 2: Data Analysis Step 3: Harmonize Identify Data Elements Identify Data Analysis Criteria Review Findings Identify Programs Survey Existing Data Models Refine Data Analysis Identify Sample States Collect Data Details Harmonize Data Definitions Consolidate and Analyze Results

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 zip Step 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