Da Vinci Project Risk Based Contract Member Identification

Da Vinci Project Risk Based Contract Member Identification Disclaimer 1

ANSI Antitrust Policy • ANSI neither develops standards nor conducts certification programs but instead accredits standards developers and certification bodies under programs requiring adherence to principles of openness, voluntariness, due process and non-discrimination. ANSI, therefore, brings significant, procompetitive benefits to the standards and conformity assessment community. • ANSI nevertheless recognizes that it must not be a vehicle for individuals or organizations to reach unlawful agreements regarding prices, terms of sale, customers, or markets or engage in other aspects of anti-competitive behavior. ANSI’s policy, therefore, is to take all appropriate measures to comply with U. S. antitrust laws and foreign competition laws and ANSI expects the same from its members and volunteers when acting on behalf of ANSI. • Approved by the ANSI Board of Directors May 22, 2014 2

Team • Business SME/ Co-Lead – Dave De. Gandi, Cambia • Business SME/ Co-Lead – Anna Taylor, Multicare • Da Vinci PMO Co-Lead – Dana Marcelonis • IG Author – Dragon, Drajer • RI Developer – Dragon, Drajer team Disclaimer 3

January Ballot Timeline • Nov 17 - NIB • Nov 25 - Ballot Signup Starts • Dec 1 - Initial Content • Dec 8 - QA Period Starts • Dec 22 - Final content • Dec 25 - Ballot Signup Ends • Dec 27 - Ballot Voting Starts • Jan 27 - Ballot Voting Ends Disclaimer 4

Risk Based Contract Member Identification Overview • Project Scope Statement: https: //confluence. hl 7. org/pages/viewpage. action? page. Id=58657072 • Sponsoring HL 7 Workgroup: Financial Management • Goal: Enable Payers and Providers to exchange information that identifies members of a patient population associated with a particular risk-based contract ‒ Method for payers and providers to synchronize data from practice management and EHRs, and to enable providers and payer organization to validate enrollment in Value-Based Care (VBC) programs at the point of care and for population level program management ‒ Information to be exchanged should be sufficient to identify a specific existing patient for inclusion in a risk-based contract or create such a patient in the PM/EHR if the patient does not already exist and the PM/EHR has the capability • PSS was modified to include FHIR Bulk Data option • To Do’s ‒ HL 7 request to change IG name under this PSS (e. g. , Value-Based Contract Member Identification & Bulk Data Exchange) Disclaimer 5

Use Case Resources • Da Vinci Confluence Space: ‒ Member Identification Project Page: https: //confluence. hl 7. org/display/DVP/Risk+Based+Contract+Member+Identification ‒ Supporting Materials: https: //confluence. hl 7. org/display/DVP/Member+Identification+Supporting+Materials ‒ Meetings: https: //confluence. hl 7. org/display/DVP/Member+Identification+Meetings Disclaimer 6

Scope • Scenarios ‒ Share member attribution list • Out of Scope ‒ Update member attribution list ‒ Initial 36 months of claims to support ‒ Opportunities to use the list in order to share data membership list is not included in this use for the identified members case • Need to find appropriate scenario to share data via ‒ How the list is generated is not in scope Bulk FHIR (PDex, CDex, DEQM use cases) ‒ The various systems and algorithms used • In Scope to generate the list is out of scope ‒ Request, Notification and Delivery of Member ‒ For what purposes and how the list gets Rosters in support of but not limited to risk-based used in the provider organization is out of programs. Care Management ‘extra care’ programs scope for example – no financial implications for payer/provider • Not everybody is on risk-based contracts ‒ Provide guidance/examples re: how to use the member identification list and bulk data access to exchange information on a population (defined by member list) using data standards defined in other Da Vinci IGs (data content defined by other guides) • Bulk data transfer from payer to provider (PDex), provider to payer (CDex), and/or DEQM Disclaimer 7

Provider Business Drivers & Scenarios • Quality • Financial ‒ Provider works the list to close care gaps for members that ‘count’ in financial reconciliation ‒ Provider performance reporting ‒ End of year reconciliation to ensure getting ‘credit’ for the right patients • Attribution varies per plan/contract, for example: ‒ Membership at point in time • Performance, rank ‒ Number of months with health plan • % targets/measures achieved ‒ Total number of claims with health plan • List of patients they can work to improve their performance on specific measures ‒ Monthly membership tracking to see trends/confirm accountable care PMPM payments ‒ Prospective list at end/beginning of year to project membership for upcoming year • Care Management ‒ Keep historical months for continuity of care since members fall off/on the list Disclaimer 8

Use Cases • Member List Creation ‒ Payer Initiated ‒ Provider Initiated • Data at Point of Care (CMS) • Provider to HIE ‒ Population Health Initiated ‒ Vendor on behalf of organization ‒ Patient Initiated – OUT OF SCOPE • Member List Updates ‒ Payer Initiated ‒ Provider Initiated – request update (add, modify, delete) Disclaimer 9

Attribution List Example Scenarios Initial List Creation Scenario List Updates Provider Initiated • Producer continues to add/update the list as often as they want (daily, weekly) Data at Point of Care Provider to HIE Payer Initiated Population Health Initiated Vendor on behalf of organization Patient specifies a list of individuals – OUT OF SCOPE ‒ Support incremental changes Example: ADT notifications – patient gets roster of providers that need to be notified Reconciliation process initiated by consumer of list Mutual process – there might be information that’s needed to verify (appointment or claims) • Producer can request from the consumer – give me active list, inactive list ‒ Roster expires after a specified time period (e. g. , 90 days) ‒ Active within 90 day time period ‒ Inactive outside of 90 day time period unless appointment or claim exists ‒ “Active” vs. “inactive” will be use case specific Final Agreed to list Consumer receives and stores list with an expiration date Disclaimer • Consumer can request changes to list from producer 10

Attribution List Considerations for Technical Approach • Attribution can be at payer/provider organization level or payer/individual provider level • Attribution method/algorithm varies by plan/contract • Data received in attribution list differs per payer/use case • Providers need a method for communicating back to payer that a member on the list should not be included and a member that isn’t on the list should be included • Member shows up in provider office with a specific health plan, but wasn’t on the attribution list - member not attributed (FFS/Commercial member) ‒ There are some attributions where provider does not have a choice – e. g. , Select Network • Members fall off/on files - helpful to know membership start/end dates • Patients may be on the list but not seen by the provider, so not populated in HER • PCP designation is sometimes included in files if member is required to select PCP (varies per contract) • Member lists can expire ‒ Inactive/ active status will be use case specific ‒ If PCP is selected via provider organization, should be able to send this information back to payer Disclaimer 11

Attribution List Definitions Attribution List: • Enumeration of patients who are attributed to payers, providers, medical homes or groups. • The Attribution list contains the patient information along with information such as Attributed Provider, Health Plan information, Validity Period for the list, Risk Information etc. Attributed Provider: • Provider responsible for the health of the Patient per the contract and will receive the payments and credits based on performance. Producer: • Entity creating the attribution list • Owns the master copy of the list • Allows for changes to be made to the list • Can receive an initial list from consumer and owns the list after that and publishes the list from that point Consumer: • Entity consuming the attribution list • May contribute to the creation of the list of the Producer • May request changes to be made to the list published by the Producer • Can receive an initial list from producer and can request changes after that point in time Disclaimer 12

Attribution List Definitions Cont’d Attribution List Data: • Data contained within the attribution list. Data includes • Patient Demographics Data • Attributed Provider Data (First Name, Last Name, Id, NPI, TIN, Address) • Health Plan Data (Subscriber Id, Member Id, Medicare Id, Medicaid Id, Plan Name, Plan Type, Enrollment Start and End Dates) • Attribution Data (Effective Start and End Date for Attribution, Attribution Method, Risk score) • Miscellaneous Data (ACO Information, Conditions) Attribution List Changes: • Addition of patients to the attribution list • Deletion of patients to the attribution list • Changes in attribution list data Disclaimer 13

Attribution List Definitions Cont’d Attribution List Owner • Definition and activities have been merged into Producer and Consumer • Hence we will not add a new actor into the interactions. Attribution: • Results of Algorithmic process that assigns patients to providers or payers or Groups. • Assignment process where patients are just assigned to the group manually. • A Patient could declare to be part of a Group by providing or selecting their PCP information or ACO information. • Add examples for each of the above - For example when patients belong to a HMO plan there is an Attribution List created with all the patients who are on the HMO plan. Disclaimer 14

Attribution List Creation Workflow – Current State Producer/Consumer enter relationship and agree on attribution method and need for a list 1 Producer creates initial attribution list Producer adjusts algorithm/ list Producer starts sending list on agreed upon cadence 2 3 Request Changes needed No changes needed 4 Disclaimer Consumer receives list & historical information Consumer reconciles list via their own attribution algorithm 3 Consumer loads data to various systems to support various use cases 15

Attribution List Update Workflow Attribution List exchanged between Producer and Consumers • • • Full Attribution list per the contract (SHALL) Incremental updates to one or more patients in the list (SHOULD) Query for a content of an attribution list which can be just be a single member (SHOULD) • (For e. g I want to check if a member is on the list or if 5 members are on the list) Frequency of updates Scheduled: • Yearly, Quarterly, Monthly, Daily On Demand/Real Time: • As updated (Push) • As requested (Pull) Disclaimer 16

Attribution List Data Exchange Interactions 1 Request Attribution List changes Push Attribution List Producer Consumer 4 Notify Attribution List changes Producer Request Attribution List 2 Receive Attribution List changes Consumer Producer Receive Attribution List Provide Initial Attribution List 5 Notify Attribution List changes 3 Producer Request Attribution List changes Consumer Notify Attribution List changes Producer Request Attribution List changes Consumer Receive Attribution List changes Disclaimer 17

Attribution List Data Exchange Interactions Cont’d Provide Initial Attribution List Notify Initial Attribution List Readiness Request Initial Attribution List 5 Receive Initial Attribution List Consumer Producer Request Attribution List changes Notify Attribution List changes Request Attribution List changes Receive Attribution List changes Disclaimer 18

Attribution List Data • Core Data Set Conceptual View Attribution List has 1. . * Members 0. . * Attributed related Based on 0. . 1 1 0. . * has 0. . * Provider Organization / ACO Subscriber 0. . * have Contract/Plan Individual Provider Subscribes to Insurance Plan 1. . * Coverages 0. . * Clinical/Financial Data Disclaimer 19

Attribution List Data • Core Data Set Conceptual View has Group 0. . * 1. . * Attributed Patient related Based on 0. . 1 1 Practitioner. Role/Practitioner Organization Patient (Subscriber) Subscribes to has 0. . * Contract/Insurance. Plan 1. . * has Insurance. Plan 0. . * Disclaimer Coverage Any Resource 20

Attribution List Data • Core Data Set Categories • Attribution List and Dates • Patient Information • Individual Provider Information • Provider Organization Information • Member/Subscriber/Plan Information • Patient’s clinical/financial information (Will not be shared as part of the Attribution List) Disclaimer 21

Attribution List Data • Core Data Set to be exchanged Cont’d • Attribution List / Dates - Group Resource • Identifier • Could use the Consumers TIN / NPI to indicate whom the group is for • Name • Attribution List Name • Owner of the List • Number of Members • Reference to Insurance Plan / Contract - Characteristic • Validity Period • Members • Member Information (Patient) • Member Period (Attribution Start / End Date) • Active / Inactive Disclaimer 22

Attribution List Data • Core Data Set to be exchanged • Patient Information – Patient Resource • Name (First, Last, Middle, Suffix, Prefix) • Gender • Date of Birth • Address (Street Address line 1, 2, 3, City, State, county/district, Country) • Telecom • Home Phone Number, Mobile Phone Number, Office Phone Number, Email • Identifiers • Member Id, Member SSN • Medicare. Id, Medicaid. Id • Patient Identifier Disclaimer 23

Attribution List Data • Core Data Set to be exchanged Cont’d • Attributed Individual Provider – Practitioner. Role Resource • Period during which the provider is the attributed provider • Specialty • Location Details (Location Resource) • Identifier • Address (State, City, Street Address) • Name • Telecom (Phone, Email) • Provider Details - (Practitioner Resource) • Name • Identifiers • TIN, NPI, • Home Address (Street Address line 1, 2, 3, City, State, county/district, Country) • Telecom (Common to all Roles) • Home Phone Number, Mobile Phone Number, Email • Language Disclaimer 24

Attribution List Data • Core Data Set to be exchanged Cont’d • Organization Provider - Organization Resource • Name • Provider Group Name • Identifiers • Provider Group NPI, Provider Group TIN • Address (Street Address line 1, 2, 3, City, State, county/district, Country) • Telecom • Home Phone Number, Mobile Phone Number, Office Phone Number, Email Disclaimer 25

Attribution List Data • Core Data Set to be exchanged • Coverage Details – Coverage Resource • Coverage Identifier (Member Id) • Subscriber Information • Subscriber Id, Link to Subscriber details – Person/Related Person (Name, SSN etc) • Relationship between Subscriber and Member/beneficiary • Dependent Number • Period • Validity period for the coverage • Coverage Class (Group or plan) information • Payor Issuing the coverage Disclaimer 26

Interactions – SHALL / SHOULD DISCUSSION for Identifying Minimum Capabilities for Release 1 of IG • Ability for a Consumer to identify their Attribution List created by the Producer – SHALL • Exchange of Full Attribution list from Producer to Consumer – SHALL ‒ Request / Response – SHALL • Consumer providing an initial Attribution List to Producer –SHOULD • Producers Notifying Consumers of Changes in Attribution List – SHALL / Next Release ? • Exchanging Partial Attribution List or only changes – SHOULD / Next Release ? • Consumers requesting changes to the Attribution List – MAY / Next Release ? Disclaimer 27

FHIR Mechanisms to exchange Complete Attribution List • Basic RESTful API on Group Resource ‒ GET /Group? _identifier=1234 (GET GROUP using Search) ‒ Returns just the Group information shell, which contains the patient references. ‒ Consumer will have to make a call for each patient to retrieve the appropriate information using Patient/$everything ‒ Usage of Include, Rev. Include on the GET Group Search API can be specified to return more information, however for Rev. Include to include Coverages should be based on a Patient Reference which you will not have until you get the initial Group. ‒ Additional ways could be investigated if required to use iteration, criteria, query mechanisms. ‒ Also the size of the payload could be very large based on initial feedback from providers and payors • Bulk API Request on Group Resource ‒ GET /Group? _identifier=1234 • Returns only the group information shell which may not even contain Patient references. • Primary purpose is to search and get the GROUP ID on which we can invoke $export. ‒ GET /Group/[id]/$export&_type=Patient, Practitioner, Organization, Coverage Disclaimer 28

FHIR Mechanisms Trade Offs for exchanging complete attribution list • Group – READ (GET ) Search operation • Group/$export – Bulk Data API ‒ Simple to implement on the Producer side ‒ More complex to implement on the Producer side ‒ Group could just return the group resource and not any of the other referenced resources like Patients, Clients will be expected to make calls to retrieve other data. This becomes unwieldy as an average size of the list is 20 K members, Making 20 K HTTP calls to retrieve the data may not be appropriate. ‒ Will allow for retrieving all the data in one shot with fewer operations. ‒ Will allow for requesting changes since some date/time using _since parameter. ‒ Will allow for limiting the data returned through resource types using _type parameter. ‒ Usage of _include, rev. Include, query mechanisms to retrieve all relevant data in fewer calls still does not address the payload size issue for average and large groups. ‒ Retrieving data for large groups may be cumbersome due to the payload size ‒ Will work for Large/Small groups Disclaimer 29

FHIR Mechanisms to exchange Changes to Attribution List • FHIR Subscriptions ‒ Using REST Hook ‒ Since FHIR Subscriptions is changing we could specify the direction in which we will head but not specify the details until the second release. ‒ Consumers Register for notifications of changes to Group Resources of interest ‒ Producers will notify the Consumers of changes in the list by invoking the supplied REST hook. ‒ Consumers can use the attribution retrieval mechanisms to retrieve the list as defined earlier Disclaimer 30

Appendix Disclaimer 31

Use Case Focus Areas Prior-Authorization Support Payer Data Exchange: Formulary Payer Data Exchange: Provider Network Payer Coverage Decision Exchange Patient Cost Transparency Risk Based Contract Member Identification Chronic Illness Documentation for Risk Adjustment Payer Data Exchange Clinical Data Exchange Alerts/Notifications: Transitions in Care, ER admit/discharge Health Record Exchange: Patient Data Exchange Clinical Data Exchange Documentation Templates and Coverage Rules Coverage / Burden Reduction Coverage Requirements Discovery Clinical Data Exchange Member Access Gaps in Care & Information Quality Improvement Data Exchange for Quality Measures Framework: Process Improvement Balloted Planned for September Ballot Use Case Status Performing Laboratory Reporting In Discovery, Planned for January Ballot Use cases in discovery (some may be balloted in January 2020) 32

Risk Based Contract Member Identification (aka Member Attribution) 33

Attribution List Data Cont’d • Data Element Discussions and Decisions • • Is there a need to attribute a patient to more than one provider? Decision: • Could be Attributed to more than one provider • Could be attributed to just an organization and not a provider. • Could be attributed to just an provider but no organization. • • For VBP it is typically a single individual provider For notification use cases it will be multiple individual providers. How will Subscriber information related to the attributed patient be linked and returned as part of the attribution list ? Decision: • The subscriber information can be obtained with a reverse search on Coverage Resource using patient reference and can be returned. So we will not add any extensions to Patient Resource to link Coverage information from Patient. Disclaimer 34

Attribution List Data Cont’d • Data Element Discussions and Decisions • • How will the insurance plan information related to the patient be extracted and returned as part of the attribution list ? Decision: • Should the Coverage Resource have a Reference to the Insurance. Plan, We will approach FM and see if we can get this added to the resource – Bob. • Currently we will use Coverage. class to represent the Plan Id information. Disclaimer 35

Attribution List Data Cont’d • Data Element Discussions and Decisions • Are organizations including clinical detail in their lists? • Decision: • Start with no clinical data in the attribution list but provide a way for this to happen in the future • Should member attribution list include only enough information to allow recipients of the list to retrieve further details if needed, or should the list include additional detail (e. g. , clinical, financial data)? • Decision: • Consider adding “Related Information” with reference to any resource under member within the Group Resource (for each member in the list) • This is a new data element that needs to be requested to be added in FHIR-I – Dragon • Have created a Gforge ticket. Disclaimer 36

Attribution List Data Exchange FHIR Mechanisms • Basic FHIR Restful API/Operations • Consumer invokes FHIR APIs/operations to get the list from Producer • Consumer invokes FHIR APIs/operations to request changes to the attribution list • Consumer invokes FHIR APIs/operations to submit initial list to the Producer • FHIR Subscriptions based data exchange • Producer publishes topics for notifications of attribution list creation and updates • Consumer subscribes to attribution list creation and update topics • Producer notifies Consumer about creation, updates to attribution list • Consumer retrieves the attribution list using FHIR Restful API/Operations Disclaimer 37

Attribution List Data Exchange Patterns Cont’d • Potential Use of FHIR Bulk APIs/Async patterns for Attribution List exchange • Attribution list creation/reconciliation typically takes long time and is normally not available real-time • When a Consumer requests for an attribution list without prior notification from the Producer that the list is ready, • the list may not be available • Should such requests use FHIR Bulk API/ Async pattern to keep track of the request/responses • Size of the lists ? • What is the average size of an existing attribution list ? • Is it conducive to exchange the list as part of regular FHIR APIs or do we need to use Bulk APIs ? Disclaimer 38

Attribution List Data Exchange Patterns Cont’d • Potential Use of Communication Request/Communication Response • Communication. Request • Consumer would send a request to the Producer requesting an attribution list • Producer would use the Communication resource to provide the data back Disclaimer 39

Member Roster Samples • Includes ~35 file structure samples: https: //confluence. hl 7. org/download/attachments/58654779/Sample%20 Member_Roster_20190 5. xlsx? version=1&modification. Date=1565277342827&api=v 2 • https: //confluence. hl 7. org/download/attachments/58654779/Member%20 Identification%20 File% 20 Formats%20 from%20 Payers. xlsx? version=1&modification. Date=1565277128843&api=v 2 Disclaimer 40

Attribution List Data Formats • 45 different file formats received from multiple Payers and Providers Most Common Data Elements based on Frequency Analysis • Member Information • Member Id, subscriber Id, First Name, Last Name, Middle Name, DOB, Gender, Address, Phone • Provider Information • Provider NPI, TIN, Name, Address, Organization • Plan Information • Plan name, type, • Attribution Information • Risk, Effective. Start. Date, Effective. End. Date, Attribution Method • Miscellaneous Information • Medicare. Id, Medicaid. Id, ACO, Conditions, Disclaimer 41

Sample Project Timeline Represents 4 weeks 2 - 4 sprints IG Development Specify profiles, … IG Framework Create Draft IG Revise and Finalize IG FHIR Gap Analysis Assemble Team Requirements Project start RI Development RI Tech Approach Build Initial RI Test RI Update Final RI Build Data Set Build Test Set Week 0 2 4 6 8 10 12 14 16 Work with appropriate HL 7 workgroup for IG sponsorship and input 42