Integration with Person Evidence

A lot of the data stored currently for a Person/Prospect Person meets our definitions of evidence; it is used in eligibility and entitlement, and often it is information retrieved from an individual or household as part of an application or intake process. The existing structure is limited as it prevents customers from making data deemed to be evidence maintainable on a case even though it may be used in eligibility and entitlement. This resulted in a poor usability experience because the user was forced to work outside of a case to maintain data for a person. It also did not provide a full audit trail of changes made over time. Maintained as static data, it was not configurable so if a customer wanted to change an attribute or add further attributes, this was a customization effort. Additionally, any data changes at the participant level could cause a reassessment on the case without the user ever being aware of it!

Solution to use Person Evidence

Evidence can only reside inside a case, therefore this participant evidence is modeled as a special case type to allow configuration of dynamic evidence at the Person/Prospect level - known as Person Evidence or Participant Manager Evidence. Updates to the existing platform code has created a number of 'out of the box' (OOTB) dynamic evidence types modeled on the existing legacy tables:

Names
Birth and Death Details
Gender
Identifications
Bank Accounts
Email Addresses
Addresses
Phone Numbers
Contact Preferences
Relationships

These dynamic evidence types that are provided OOTB will include a write back of the data to the corresponding Participant Manager legacy table, so for example when a user maintains name information in evidence, updates will be made to the 'AlternateName' table. This is necessary because system processing relies on the data being present in the legacy entity, for example, 'AlternateName' data is accessed in search processes.

Maintaining this data as evidence allows it to be used for eligibility and entitlement in a way that allows Users to choose when data changes should be applied and take effect. This evidence can remain 'in edit' until such time as a user decides to apply it to the case. Also, configuring these new dynamic evidence types onto other cases (such as an Integrated Case where other case evidence is maintained), allows Users to maintain the information along with their other case evidence. This provides a much more user-friendly way of managing all evidence for a Person/Prospect Person.

There are a number of other participant data tables that fall into the 'evidence' category however this data is not used in system processing and therefore is not converted to dynamic evidence. Items that fall into this category include:

Demographic data (such as race and ethnicity)
Citizenships
Foreign Residencies
Education
Employment/Employment Working Hours

The pages that allow users to maintain this data will be configured to be not visible in the application views we ship OOTB. However new customers can configure their own dynamic evidence types where they choose and with the attributes and validations that meet their own requirements.

It is worth noting that the 'Case' for a Participant is just an architecture – for the end user, they will still continue to see the evidence for a person inside the Participant Manager 'Person/Prospect Person' tab. Person Registration is the function which creates the case in the background and the necessary dynamic evidence records. Person evidence is automatically activated so some special logic is being implemented in order for the system to determine how information brokered from other cases is applied.

Configuration

Customers can choose to not use Person Evidence – there is a PDC 'off' mode which means the existing screens and updates can be made as they are today. This is turned on by default.

HCR Integration with Person Evidence

Customers have the option to configure person evidence at the case level, and updates need to be shared to other cases and vice versa. The evidence broker plays a central role because sharing needs to occur between the Intake Application, Ongoing Cases (IC/PD) and the Participant Manager Case. The HCR solution has implemented the following, and rules have been updated to reference these new evidence entities where applicable.

Email Address
Birth and Death Information
Phone Number
Gender
Contact Preferences
Identification - map from the PDC Identification evidence to the HCR SSNDetails evidence

Evidence Broker configurations

Evidence broker is fundamental to the use of person evidence. As it is necessary to transfer evidence from Person records in the Participant Manager to the Insurance Affordability application case configurations have been added so that the full configuration is now as follows for each of the evidence types shared by HCR cases and the Participant Manager:

From Application Case to Integrated Case: all types auto accepted and auto-activated
From Application Case to Participant Manager: all types implicitly auto accepted and auto-activated (standard behavior for Participant Manager evidence)
From Integrated Case to Participant Manager: all types implicitly auto accepted and auto-activated (standard behavior for Participant Manager evidence)
From Participant Manager to Application Case: no types auto accepted or auto-activated (will appear as incoming evidence)
From Participant Manager to Integrated Case: no types auto accepted or auto-activated (will appear as incoming evidence)

In addition, logic is included with the participant manager evidence types to ensure that logical duplicates are not brokered, for example, where a new Gender record is created on an application case and the gender is no different from what is already recorded against that person, the broker will discard the new record when brokering from the application case to the participant manager.