HIT Policy Standards Committee Enrollment Workgroup Aneesh

HIT Policy & Standards Committee Enrollment Workgroup Aneesh Chopra, Chair Chief Technology Officer, OSTP Sam Karp, Co-Chair California Healthcare Foundation August 12, 2010 1

Workgroup Members Chair: Aneesh Chopra, Federal CTO Co-Chair: Sam Karp, California Healthcare Foundation Members: • Cris Ross • James Borland • Jessica Shahin • Stacy Dean • Steve Fletcher • Reed V. Tuckson • Ronan Rooney • Rob Restuccia • Ruth Kennedy • Ray Baxter • Deborah Bachrach • Paul Egerman • Gopal Khanna • Bill Oates • Anne Castro • Oren Michels • Wilfried Schobeiri • Bryan Sivak • Terri Shaw • Elizabeth Royal • Sallie Milam • Dave Molchany Ex Officio/Federal: Sharon Parrott, O/S, HHS Nancy De. Lew, HHS Penny Thompson, CMS/HHS Henry Chao, CMS/HHS Gary Glickman, OMB John Galloway, OMB David Hale, NIH Paul Swanenberg, SSA David Hansell, Administration for Children & Families, HHS Julie Rushin, IRS Farzad Mostashari, ONC Doug Fridsma, ONC Kristen Ratcliff, ONC Lab Hub Initiative Social Security Administration U. S. Department of Agriculture Center on Budget & Policy Priorities CIO, Utah United. Health Group Curam Community Catalyst Louisiana Medicaid Department Kaiser Permanente Consultant Businessman CIO, Minnesota CIO, City of Boston Blue Cross/Blue Shield South Carolina Mashery In. Take 1 CTO, Washington, DC Children’s Partnership SEIU West Virginia, Chief Privacy Officer Deputy County Executive, Fairfax County 2

Agenda • Welcome and Overview • Tiger Team Updates and Recommendations - Privacy & Security Verification Interfaces NIEM Process and Data Harmonization Business Rules Health Plan/Benefit • Discussion on Intersection of Tiger Team Recommendations (e. g. , cross-cutting issues) • Next Steps • Demonstration of Curam Software • Public Comment 3

Overview of ACA Section 1561 and Workgroup Charge

Section 1561 of Affordable Care Act • § 1561. HIT Enrollment, Standards and Protocols. Not later than 180 days after the enactment, the Secretary, in consultation with the HIT Policy and Standards Committees, shall develop interoperable and secure standards and protocols that facilitate enrollment in Federal and State health and human services programs through methods that include providing individuals and authorized 3 rd parties notification of eligibility and verification of eligibility.

A Summary of 1561 Requirements. . .

Workgroup Charge • Inventory of standards in use, identification of gaps, recommendations for candidate standards for federal and state health and human service programs in following areas: – Electronic matching across state and Federal data – Retrieval and submission of electronic documentation for verification – Reuse of eligibility information – Capability for individuals to maintain eligibility information online – Notification of eligibility

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. 8

Privacy and Security Tiger Team 9

Privacy & Security Tiger Team • • • Sallie Milam, Lead, Chief Privacy Officer, WV Joy Pritts, HHS/ONC Paul Egerman Ruth Kennedy, CHIP Director, LA Elizabeth Royal, SEIU 10

Privacy and Security Charge • Provide strawman recommendations on: – Application of fair information practices, including purpose limitation/re-use – Security safeguards (authentication, secure transport, audit logs) 11

Privacy & Security Principles • States should address Fair Information Practices (FIPs) in new and existing eligibility and enrollment systems to safeguard consumer information. The following are best practices states can implement to address FIPs in their state systems: – Collection Limitation: State systems should be designed to collect the minimum data necessary for an eligibility and enrollment determination. This should be balanced with the desire to reuse information for multiple eligibility decisions. – Data Integrity & Quality: States should establishing a minimum threshold level for data matches, adopting a glidepath toward achieving advanced probabilistic matching. – Openness & Transparency: Clear, transparent policies about authorizing access and use of data should be provided to the applicant in the Privacy Notice.

Draft Recommendation Accountability & Oversight • Automated eligibility systems should have the capability to: – Record actions related to the PII provided for determining eligibility. The date, time, client identification, and user identification must be recorded when electronic eligibility information is created, modified, deleted, or printed; and an indication of which action(s) occurred must also be recorded. – Generate audit log. Enable a user to generate an audit log for a specific time period and to sort entries in the audit log.

Draft Recommendation Individual Control and Participation • Recognizing that consumers increasingly desire access to and control over their own personal information, we recommend that Federal and State programs adopt a consumer-mediated approach toward data sharing, where possible. Under this approach, the consumer should be able to: – Determine appropriate uses for personal information, including, but not limited to, sharing data across programs to facilitate additional enrollments; – Correct/update personal information upon request to the program.

Draft Recommendation Individual Control & Participation • To facilitate a consumer mediated approach to data sharing, programs should: – Provide consumer information to the consumer in a human-readable form (view/print/save); – Enable data to be exported into commonly used software formats, such as spreadsheets, text files, etc. ; and – Develop separate pathways for download requests from the individual and download requests via automated processes acting on the individual’s behalf. – Limit data use to that specified in the Privacy Notice unless consumer consents to additional uses.

Draft Recommendation Purpose Specification/Use Limitation • Consistent with the Privacy Act, the Privacy Notice provided to the consumer during the application process will govern the consumer’s rights to confidentiality and privacy. The Privacy Notice should be provided to the consumer prior to or at the time of disclosure of PII in a method the consumer can understand. The Privacy Notice should also clearly indicate all Federal, State and community organizations (e. g. , public health plans, social service agencies, private health plans, clinics, etc. ) that will be permitted to use an applicant’s eligibility data, as well as specify the permissible uses of such data.

Draft Recommendation Purpose Specification/Use Limitation • The consumer’s ability to designate proxy (e. g. , third party) access should be as specific as feasible regarding: – Authorization to data (e. g. , read-only, write-only, read/write, or read/write/edit) – Access to data types – Access to functions – Role permissions – Ability to further designate proxies • In addition, proxy access should be: – Subject to the granting of separate authentication and/or login processes for proxies; – Tracked in immutable audit logs designating each specific proxy access and major activities; – Time-limited and easily revocable.

Draft Recommendation Security Safeguards – Secure Transport • We recommend that data in motion be encrypted. Valid encryption processes for data in motion are those which comply, as appropriate, with NIST SP 800 -52, 800 -77, or 800 -113, or others which are Federal Information Processing Standards (FIPS) 140 -2 validated.

Discussion

Verification Interfaces Tiger Team

Verification Interfaces Tiger Team • • • Steve Fletcher, Lead, CIO Utah Henry Chao, Lead, HHS Cris Ross, Lab Hub Initiative Ronan Rooney, Curam Oren Michels, Mashery Bryan Sivak, CIO, DC David Molchany, Fairfax CO, VA Stacy Dean, Center on Budget & Policy Priorities Wilfried Schobeiri, In. Take 1 Gina Garza, IRS Paul Swanenberg, SSA 21

Verification Interfaces Tiger Team Charge • Provide “strawman” recommendations on: – Modernizing verification interfaces – Requirements for a possible verification interface “hub” 22

What Verification Sources Does the ACA require? • 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) 23

What Do Current National Systems Verify? National Systems IRS DHS SSA EVVES PARIS IEVS n n n Data Elements Age n n Citizenship Immigration status Family Size/Dependents n n n Residency Income Incarceration n All data elements but incarceration required for exchange, Medicaid CHIP, SNAP, TANF, EITC 24

Key Characteristics National Systems IRS DHS SSA EVVES PARIS n n IEVS Verification Method On-Line, with staff transferring data or indicating they have reviewed the data for verification purposes Batch interface with electronic or paper reports produced to review for matches State Customizations to Integrate Data n n n n Data Used to Match Records Name n n n Date of Birth n n Social Security or Equivalent n n n 25

Draft Recommendation • The interfaces or web services used by the Social Security Administration (SSA), the Department of Homeland Security (DHS), and the Treasury to verify an individual’s eligibility for Exchange participation should be available to other State health and human services programs, including State Medicaid programs, CHIP, TANF, and SNAP.

Draft Recommendation • To ensure that States are able to verify an individual’s eligibility information with the most current information available, we recommend that the Department of Health and Human Services, Administration of Children and Families, Federal Office of Child Support Enforcement develop the technical infrastructure necessary to support and encourage queries into the National Directory of New Hires. This infrastructure should support the verification of New Hire (W-4) information, Quarterly Wage data, and Unemployment Insurance information.

Draft Recommendation • To the extent practicable, State health and human services programs should use Federal or national data sources to verify key pieces of an applicant’s eligibility information. These sources include [National DMV database, ] the Electronic Verification of Vital Events Record (EVVE) system, PARIS, and the U. S. Postal Service Address Standardization API.

Draft Recommendation • Federal, State, and commonly used national verification interfaces should use web services conforming to WC 3 WSI standards and NIEM exchange guidelines to provide real-time automated verification. These systems should incorporate or utilize a read and write translation service to support data exchange with legacy systems and in different formats (e. g. , HL 7, XML, etc). If State eligibility and enrollment systems are not integrated, we recommend that States use the same standards to support real-time, automated queries between programs to determine if an applicant is known to the system prior to completing eligibility verifications.

Draft Recommendation • We recommend that Federal and State data retention and reuse policy allow for the reuse of an applicant’s eligibility and enrollment information for eligibility/enrollment determinations across programs. Consistent with the “no wrong door” approach, data sharing agreements should be modified to allow for such use. Additionally, where possible, States should provide for “express lane” determinations across programs (i. e. , an eligibility determination for one program is a de facto determination for a second program with no additional eligibility verification necessary).

Draft Recommendation • Streamlined enrollment in a modern, interoperable eligibility and enrollment system will require the seamless transmission of data between State programs. We recommend that State and Federal data suppliers (e. g. SSA, IRS, DHS, various State entities) disaggregate data by individual rather than household to ensure that data can be collected once, but reused for multiple eligibility determinations.

Draft Recommendation • Verification protocols should support both automated and point-in-time verifications. We recommend that Federal and State agencies implement the following best practices for both automated and point-in-time verifications to preserve data quality and integrity: – Consistent method for transmitting necessary metadata (e. g. , source, time stamp, date last modified, etc. ) with eligibility and enrollment information when exchanging information between programs; – Storing raw data with derived data when using a formulaic calculation for any data element upon which an eligibility determination will be made (e. g. , income); – Use of Dublin Core or other library standards to support cataloging and classifying of verification data; and – Algorithmic approach to eliminating duplicate matches and identifying or “ranking” the most reliable information (e. g. , identifying that an applicant’s home address is more likely to be accurate than an address at the non-profit or clinic where applicant applied for benefits).

Draft Recommendation • We recommend that consumer communication tools (e. g. , email, text, online dashboards, chat, and others) include: – Timely, clear information to the applicant on process and next steps, if any, in a format the consumer has designated as his or her preferred communication modality; and – Mechanism for the transport and storage of metadata associated with the message (e. g. , source, time stamp, etc. );

Draft Recommendation • A coordinated, consistent approach to obtaining essential Federal or national verifications requires the development of an automated verifications web service or “engine. ” This engine should be built around a number of base services that are updated and expanded upon over time. We recommend that this service: – Be implemented at the Federal level to catalog translators, tools and/or web services (using UDDI or other contemporary cataloging standards) that can be used by States to interface with Federal and/or national data sources; – Leverage tools and services currently used by State systems while supporting and encouraging new, innovative tools, modules and services; and – Use e-forums to promote information sharing between State and Federal partners (including information on best practices) and notify State and community partners of updated services and tools.

Discussion

Enrollment Data Element Harmonization DRAFT 8/10/2010

Task Objectives • Survey core enrollment data elements from selected health and human service programs across states • Collect details for core enrollment data elements • Map data elements to existing standards such as HL 7, X 12, and NIEM in order to foster interoperability • Provide recommendations for achieving data element harmonization 37

Enrollment Data Harmonization Process 38

Standards Committee Slide Data Analysis Approach Overview Data Analysis Approach Data element analysis conducted across 34 health and human service programs across 10 states • Data Analysis Criteria Data Element Name – Label for each core data enrollment element e. g. , Address Data Definition – How the source system describes the data element or data element variation Data Value – Underlying data attributes of a data element or data element variation as well as the indicating how the applicant would enter the required value for a specific data element. E. g. , SSN - 000 -00 -0000, Yes/No, Male/Female Data Source – The source or how the information provided by the applicant is verified. E. g. , Birth certificate, driver’s license, interfaces with SSA/ United States Citizenship and Immigration Services (USCIS) • • Health and Human Services Programs • • Medicaid CHIP SNAP TANF Core Data Elements • Name • Date of Birth • Social Security Number • Address • Gender • Citizenship • Legal Status • Incarceration • Income • Household Composition • Race/Ethnicity • Primary Care Provider Existing Data Standards • NIEM (version 2. 1) • HL 7 (RIM version 2. 31) • X 12 (version 5010) 39

Data Analysis Summary Considerations for determining complexity of data element harmonization: • • Range of data variations across state programs Prevalence of similar data variations across state programs Similarity and range of data values across states programs Available mapping to existing data standards (HL 7, NIEM, and/or X 12) Rating Legend • • • Low – minimal data variations and similar data values across state programs, as well as potential mapping to existing standards Medium –may have an unclear definition, prevalent sub-concepts, significant data variations and/or data values across state programs High – significant data variations, wide-range of potential data values, interconnected with underlying business rules Core Data Element Complexity of Harmonization Name Low Date of Birth Low Social Security Number Low Gender Low Address Medium Citizenship Medium Legal Status Medium Incarceration Medium Race/Ethnicity High Household Composition High Income High Primary Care Provider N/A 40

Key Findings Name – low harmonization complexity • Consistent terminology and similarity in foundational data values will enable creation of a harmonized data element definition and mapping to existing standards – – – Range of data variations: Name was consistently requested and referred to across the state programs Similarity and range of data values: Variations were found in the name values requested. For example, some states asked for additional name attributes suffix, maiden name, and/or former name Mapping to existing data standards (HL 7, NIEM, & X 12): Both HL 7 and NIEM have person’s family name, given name and suffix. NIEM however, has surname, maiden name and middle name, which are not in HL 7. X 12 provides means to aggregated name from data element “name first, name middle, name last or organization name, name suffix as well as hundreds of qualifiers paired to the data element depending upon business need Date of Birth – low harmonization complexity • Consistent data values and semantics will facilitate creation of a harmonized data element definition and mapping to existing standards – – – Range of data labels: Semantically the same concept can be represented in different ways (e. g. birth date vs. date of birth) Similarity and range of data values: Value of birth date was consistent across state programs (e. g. , date represented as mm/dd/yyyy) Mapping to existing data standards (HL 7, NIEM, & X 12): HL 7 has “Birth. Time” of a living subject’s (e. g. person). The definition, for “Birth Time” however, is not exclusive to human beings. NIEM has “Person. Birth. Date” which is defined as the date a person was born and X 12 has “Date Time Period” which is defined as a person’s date of birth 41

Key Findings Social Security Number – low harmonization complexity • Consistent terminology and similarity in foundational data values will enable creation of a harmonized data element definition and mapping to existing standards – – Range of data variations: Minimal data variations encountered across program sample Similarity and range of data values: State programs consistently requested full 9 -digit social security number Mapping to existing data standards (HL 7, NIEM & X 12) : NIEM has a person SSN identification method and HL 7 has a person identifier of which SSN can be included however HL 7 policy discourages use SSN for personal identifier. X 12 has an “Identification Code” with an available Social Security Number qualifier From a verification interface perspective, several state programs currently verify SSN through an interface with SSA, while some states request a copy of Social Security Card to verify SSN Gender – low harmonization complexity • Consistent data values and semantics will facilitate creation of a harmonized data element definition and mapping to existing standards – – – Range of data variations: Two common terms used for this data element including gender and sex Similarity and range of data values: State programs consistently requested either m ale or female as the data values Mapping to existing data standards (HL 7, NIEM & X 12) : All three standards have defined data elements that can be used to increase interoperability although HL 7 and NIEM support more data values than encountered in program enrollment applications 42

Key Findings Address – medium harmonization complexity • Creation of a harmonized data element definition and mapping to existing standards must consider subconcepts of address (e. g. , mailing address, home address etc. ) – – – Range of data variations: Multiple types of address were found across state programs’ applications including home address, mailing address, and past address Similarity and range of data values: Most states requested the same set of information for each address type such as street address, city, state, zip code, etc Mapping to existing data standards (HL 7, NIEM & X 12): HL 7 and NIEM also define multiple address types (e. g. , home address, postal address, mailing address) that can be leveraged in order to increase interoperability. X 12 contains “Address Information” used to capture address, but more discussion is required to understand the available types of address 43

Key Findings Citizenship – medium harmonization complexity • Need to understand the meaning of citizenship as it pertains to an eligibility determination in order to harmonize data element and accurately map to existing standards – Range of data variations: In general, applicants were asked to confirm whether they are U. S. citizens. In – some case, if applicant indicates that they are non-U. S. citizen, they were requested to answer some questions about their legal status. Applicants also had to show proof of their confirmation of U. S. Citizenship or derived citizenship determination by requesting identification of a person’s specific legal status such as U. S. Citizen, Permanent Alien etc. Mapping to existing data standards (HL 7, NIEM & X 12) : NIEM has “Yes/No” indicator for citizenship. HL 7 has “Passport” as an indicator of citizenship. X 12 has “Citizenship Status Code” which may be an available mapping Legal Status – medium harmonization complexity • Need to understand the meaning of legal status as it pertains to an eligibility determination in order to harmonize data element and accurately map to existing standards – – – Range of data variations: Term was not directly used in any of the applications surveyed. In some cases, the collection of information for this data element was based on how the system’s rules engine processed the response of whether a person was confirmed as a U. S. citizen or a non-U. S. citizen. If a person select noncitizen, they were asked to indicate their alien status from a possible set of values such as, legal resident, permanent resident, refugee, etc. Similarity and range of data values: Variations occurred in the extent of available values that were considered related to legal status (e. g. , U. S. Citizen, Permanent Alien etc. ) Mapping to existing data standards (HL 7, NIEM, & X 12) : NIEM allows capturing legal status as “immigration status” or “alien citizenship” with “True/False” indicators. The difference is the context in they are used. HL 7 allows capturing legal status with valid values such, asylum seeker, national, permit card applicant, etc. X 12 has “Citizenship Status Code” which may be an available mapping

Key Findings Incarceration – medium harmonization complexity • Need to understand consistent definition for incarceration and underlying eligibility business rules in order to evaluate incarceration at the data element level – Range of data variations: Applications asked peripheral questions around criminal history or jail begin/end dates, but none of the surveyed applications asked if a user was currently incarcerated – Mapping to existing data standards (HL 7, NIEM & X 12): NIEM defines incarceration as mandatory confined supervision of a person. Such definition may not be applicable to enrollment and eligibility and may need to be extended to suit the needs of the HHS. HL 7 does not have any definition for incarceration. X 12 does have codes for incarceration - need more definition to this item to determine correct mapping Race/Ethnicity – high harmonization complexity • Need to address variability occurring in the nomenclature of race/ethnicity values in order to enable harmonization of data definitions and mapping to existing standards – Range of data variations: Instances of data variations related to race/ethnicity terminology in enrollment applications – Similarity and range of data values: Divergence identified in exact nomenclature of race/ethnicity designations as well as the number of race/ethnicity designations provided – Mapping to existing data standards (HL 7, NIEM & X 12): NIEM, HL 7, and X 12 have definitions for both race and ethnicity that may be leveraged, although valid values are not equivalent 45

Key Findings Household Composition – high harmonization complexity • Need to understand consistent definition for household composition (e. g. , number of people in a household or number of people sharing food in a household, etc. ), as well as underlying business rules per program and per state used to derive household composition – Ambiguity of applicable concepts: Data variations generally fall into three categories 1) number of people in the household 2) number of people in household sharing food and 3) characteristics of the household (e. g. , the head of household and the relationship of household members) – Mapping to existing data standards (HL 7, NIEM &X 12): NIEM allows capturing household composition to indicate that a person is a member of a household. Currently, this definition is owned by Family Services. HL 7’s defines Household Composition as an observation of a person’s living situation in a household including the household composition. HL 7’s definition may not be applicable to enrollment and eligibility. X 12 has the concept of family history but will need more details to determine an applicable mapping 46

Key Findings Income – high harmonization complexity • Need to understand how discrete data elements (e. g. , employment income, selfemployment income, unearned income, utilities, medical expenses etc. ) are used to calculate income as well as how states apply business rules to derive income – Range of data variations: Encountered many possible income data variations or potentially independent data elements related to income. Applications generally requested some form of net income and expenses, although there were differences in terminology – Similarity and range of data values: It is difficult to qualify data values with such a variety of possible data variations – Mapping to existing data standards (HL 7, NIEM & X 12): NIEM defines income as the amount of money made by an organization. Such definition is at the organizational level rather than at the individual level and may not necessarily be applicable to enrollment and eligibility. HL 7 has two variations (income and financial eligibility). Definition for both has to do with determining eligibility for a program. Primary Care Provider • Data element was only found in 1 of 34 state program enrollment applications – Mapping to existing standards (HL 7, NIEM & X 12): All three standards have potential mappings including HL 7 – “PCP (primary care physician)“, NIEM - “Treatment. Provider”, and X 12 – an entity identifier code of “Primary Care Provider” 47

What we know and don’t know? • Know – – – • Complexity of harmonization varies based on concept and data element Concepts and data elements are driven by business rules (e. g. , income and household composition) Business rules vary between programs and states HL 7 , X 12, and other data standards provide opportunities to reuse information and increase interoperability between health and human service program enrollment systems NIEM provides method to incorporate other standard’s concepts/data type via mapping to existing NIEM data, extending NIEM data, and/or incorporating other standard’s concepts/data types into NIEM Don’t Know – Depth of anticipated harmonization (e. g. , is it at the data name, data definition, and/or data value level) – Principles to capture, catalogue, and manage business rules that drive the derivation of some concepts or data elements (e. g. , household composition, income etc. ) – If an enrollment data element may potentially map to multiple standards, which standard should be leveraged to facilitate harmonization? (e. g. , should data element definitions be merged from both standards, should one standard be preferred etc. ) 48

Draft Recommendation • We recommend that the HIT Standards FACA facilitate the harmonization process by creating a Harmonization Workgroup to review and/or harmonize selected data element components. Objectives would include: – Identify depth of data harmonization necessary – Identifying business scenarios (e. g. , high level scope and goals of the information exchanges needed for enrollment) – Defining business processes pertaining to identified information exchanges; – Leveraging program subject matter experts to translate how business rules impact derivation of a data element; – Establishing consensus on harmonized data definition for each enrollment data elements; – Mapping data elements to existing standards and identifying gaps where existing standards may be extended, new standards can be created in standards source; and – Providing harmonized definition, type, valid values, etc. that are derived from existing standards when possible for enrollment data elements.

Draft Recommendation • Federal stakeholders should collaborate with State and community partners in defining exchange content to facilitate ease of adoption and implementation of harmonized data elements. This includes ensuring harmonized core data elements can flow through multiple enrollment information exchanges by: – Developing the UML model for content and/or information exchanges; and – Representing the structure of the information involved in the exchange.

Logical Data Model • • Standards Committee Slide A Logical Data Model would be an output of recommendation # 3 provided in the previous slide The logical data model is intended to show an initial grouping of core data elements, but may require further refinement to account for business rules and standardized data definitions 51

Discussion

Business Rules Tiger Team

Business Rules Tiger Team • • Cris Ross, Lead, Lab Hub Initiative Ronan Rooney, Curam Oren Michels, Mashery James Borland, SSA Gopal Khanna, CIO, MN Bill Oates, CIO, City of Boston Rob Restuccia, Community Catalyst Lisa Pino, USDA 54

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

Business Rules • “A business rule is anything that captures and implements business, policies and practices. A rule can: – Enforce policy (e. g. , program hierarchy, exception handling) – Make a decision (e. g. , eligibility determination, point in time verification rules) – Infer new data from existing data” (e. g. , persons with the same address live in the same household)” • • Eligibility and/or enrollment systems may use all three types of rules. Business rules also serve as the link of interpretation between legislation, regulation, policy, and the consumer – Business rules should be expressed in a manner to be consistently implemented across states and so that the rules and results are easily understandable by the consumer – Technology will be used for common expression of business rules (based on legislation, regulation and policy) and should be technology neutral 1 Certain parts of this business rules definition were adapted from BM: http: //publib. boulder. ibm. com/infocenter/dmndhelp/v 6 rxmx/index. jsp? topic=/com. ibm. wbit. help. br. ui. doc/topics/cundbus. ht ml 56

Basis for Encouraging Consistency in Business Rule Expression • • As the pressures of ACA require agencies to act more quickly, across more channels, while enforcing more regulations and focusing more closely on individual consumers, the need for business rules to automate decisions is critical to speed of adoption and implementation. The more clearly rules are articulated, the more quickly states and others will be able to adopt and implement. Business rules are an organized way to document policy decisions in ACA, and are a common base for different technical paths that the States and the Federal government will take to implement ACA: – Business rule management permits participation and collaboration in implementing changes in a controlled manner without the need to know about syntax or code – Business rules are more understandable to business-level people when reviewing, updating, and testing – When implemented in a middleware approach, separation of rules and legacy code provides flexibility to make changes with minimal impact on basic systems [Note: Business rules will require a developer to code and integrate the rules into the system]

Business Rules Objectives • Business rules should (near-term to longer-term objectives): – Be consumer-centered – straight-forward and simple for consumer to understand the process – Support consistent expression of rules along a continuum of implementation modalities (i. e. , enhancing legacy systems to developing new systems) while being technology neutral – Support the augmentation of current state systems – Accelerate states’ ability to comply with ACA – Support integration across systems and across programs to support a seamless user experience by addressing program hierarchy and providing capaity for addition of other programs – Guide the adoption and utilization of federated core data – Where necessary and possible, “buffer” the impact of imperfect information and data whether from verification sources (automated and point-in-time) or others – Minimize maintenance and allow for scalability – Serve as an initial step, approach and guidance for the modernization of state eligibility and enrollment systems and development of HIE

Draft Recommendation • To allow for the open and collaborative exchange of information and innovation, we recommend that the Federal government develop an open source process with supporting resources for central business rules orchestration. This resource would use an e-forum (similar to www. hhs. gov/open or www. data. gov) to provide support for evaluation and use of tools to extract and document business rules from legacy code, respond to questions on Federal business rules, clarify and update guidance where necessary and communicate best practices to states. • Implementation of this recommendation may support the creation of a web services to be shared with State partners (e. g. , MAGI calculation). Once implemented, standard business rules description and enhanced web services based rules should be maintained and updated in a central repository or “library. ”

Draft Recommendation • We recommend Federal and State agencies express business rules in a standard, technology-neutral format (e. g. , SBVR, WC 3’s RIF, etc. ) to: – Make the rules easy to implement from the developers; and – Ensure that decisions are understandable, clear and effectively communicated to consumers and between State programs. A welldefined business rule includes the following elements: • • Business rule name; Identifier; Description; Priority; Example; Notes; Assumptions.

Plan / Benefits Tiger Team

Plan/Benefits Tiger Team • • • Reed Tuckson, Lead, United Health. Group Anne Castro, BCBS/South Carolina Terri Shaw, Children’s Partnership Henry Chao, HHS Deborah Bachrach Ray Baxter, Kaiser Permanente 62

Plan/Benefit 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 63

Principles • Maximize the opportunity for people to get needed coverage • Facilitate continuity in enrollment and coverage • Be mindful of driving up costs by over-engineering this process • Data required should be limited to that necessary for health plans to execute enrollment 64

Assumptions • Information transfers to the plan AFTER program eligibility (Medicaid, SCHIP, Exchange [subsidized or not] or any other relevant programs) is determined • Information transferred to the plan will include enrollment data such as: – Consumer plan (product) choice; and – Coverage periods / effective dates, contingent upon certain policy decisions not in the purview of the HIT Workgroup. 65

Draft Recommendation • Standards are needed to ensure that the transfer of applicant information between Federal/State programs and health plans is clear, orderly, and rational. Where possible, we recommend using existing HIPAA standards to facilitate continuity of coverage when an applicant or enrollee is transitioning between health plans. – The HIPAA 834 standard should be used to “handoff” and “handback” an applicant’s enrollment information – The HIPAA 270 and 271 standards should be used to respond to eligibility inquires and responses. • For bi-directional transactions, new standards are needed. • At minimum, we recommend creation of a confirmation standard to confirm enrollment following a health plan’s receipt of the 834.

Draft Recommendation • Disenrollment of an individual will be sent back to the Consumer On-Line system through a 834 transaction from the Health Plan, indicating the disenrollment date. – The Consumer On-Line system should be able to support and accommodate outreach to the consumer to facilitate continuous coverage – Changes in eligibility and/or coverage status should be clearly articulated to the consumer, in a manner he or she can understand, using email, text message, online dashboard, or other readily accessible communication tools. • Recommend that the enrollment related Health Plan communication processes recommended herein be managed similarly to the Eligibility Verification and Business Rules process, and that it is built at a federal level that can be adopted and retrofitted for state adoption.

Draft Recommendation • Recommend that there is a national directory of health plans that includes health plan product options, coverage maps, and provider networks. • The national directory would be created and maintained by the Federal Government, and accessible through a web service exchange to ACA State and Federal Health Insurance Exchanges, Medicaid, SCHIP and other relevant health programs.

Discussion

Cross-Cutting Tiger Team Issues

Purpose • While many of the recommendations have been worked on in Tiger Teams, some of the recommendations are dependent on or will impact recommendations of other Tiger Teams • The purpose of this document is to identify those areas of intersection of all the recommendations

Intersection of Recommendations

At the Core. . . Web Service Architecture • • • Provides for platform independency Consistent with Federal standards for other programs and systems Serves as a foundation for privacy and security, verification and business rules recommendations Supports the overarching recommendation for “re-use” Supportive of state system augmentation (no ripping and replacing) Consistent with the recommended models for continuous innovation from the Business Rules and Verification Tiger Teams Core (e. g. , Federated) Data • Consumer, or helping third party, will enter data into the online application • Verification information will be used to validate the information • Business rules will use the data to: – Enforce policy – Make a decision – Route application or renewal data to appropriate programs – Infer new data from existing data – Support consumer communication – “Buffer” impact of imperfect information

At the Core. . . Consumer Mediated • This is another foundational concept for all the Tiger Teams – – – Security and Privacy – Drives the recommendations for authentication, individual control and participation, purpose specification and use limitations, and ID management Verification – Drives the recommendations for automated real-time verifications, as well as the ability of the consumer to provide point in time verifications when automated information is not consistent with current situation or wrong, as well as “re-use” of verification information for other programs Business Rules – Drives the need to provide program hierarchy and the consistent and clear communication to the consumer on the basis of decisions and outcomes Health Plan – Drives the need for Plan, Provider and other choices real time and automated updates of change of enrollment or other demographic data All Tiger Teams – Drives the need for clear, consistent and understandable consumer messaging through e. Mail, text messaging, online application and others Open Information and Continuous Innovation • • • This type of model is recommended by the Business Rules and Verification teams is to provide open information to the consumer, the states and the developer community The fundamental recommendation is designed to support continuous innovation and update to be shared with all so that states and developers do not have to “re-create” the process The recommendation also puts the federal policy makers at the center of insuring the information regarding policy is provided in a manner and approach that can be consumed by states and their developers and that the forums are kept current with updated policy decisions and interpretations

Consumer • Consumer information must be the least required to complete eligibility and enrollment process per the Privacy and Security Tiger Team • Consumer provided information must be clear and understandable – Verified through automated verifications against a number of federal and state systems – Provision for point in time verifications to clarify, correct and report new circumstances • Consumer messaging must understandable, driven by business rules, consistent with privacy and security recommendations and using the modalities of communication prevalent in 2014

Privacy and Security • Surrounds all other Tiger Team recommendations as the privacy and security recommendations deal with: – Purpose limitation (e. g. , consumer and limited third party use and reuse of data) – Security safeguards • • Authentication Secure transport Audit logs ID resolution

Verification • Verification Team is also recommending real-time interface to determine if the consumer is known to eligibility and enrollment systems in the state • Verifications are used to validate the data provided by the consumer – Automated verification should be real time from a number of federal systems – Point in time verifications are recommended for the consumer to update the data where there is a change in circumstance or discrepencies

Business Rules • Once data is input by Consumer, screened against eligibility and enrollment systems, verified through automated or point in time verifications, business rules will use the data to: – Enforce policy – Make a decision – Route application or renewal data to appropriate programs (program hierarchy) – Infer new data from existing data – Support consumer communication – “Buffer” impact of imperfect information

Health Plan • Once the person is determined eligible for a health program where a health plan is to provide services, the verified enrollment data is sent to the health plan through a secure transmission (Privacy and Security Team recommends HIPAA standards) and the Health Plan Tiger Team recommends use of HIPAA standard transactions such as the 834 and 270 and 271.

Next Steps • August 19: Draft recommendations presented to HIT Policy Committee • August 24: Workgroup meeting • August 30: Draft recommendations to HIT Standards Committee • August 31: Enrollment WG meeting • September: Recommendations to FACAs and ONC

Public Comment