The purpose of this document is to give a detailed functional description of how the EMPI CRS interface operates.

The Enterprise Master Person Index (EMPI) replaces the legacy client index system CRS and acts as a central hub for person data from the different data source agencies – that will disseminate individual information to consuming applications and systems using a well-defined governance structure. EMPI maintains client information (including demographics), address and a person’s active program participation details and a unique common-identifier for each client served by other DHR systems. Systems including SUCCESS (TANF, Food Stamps, Medicaid) and $TARS (Child Support) maintain information leveraging this unique EMPI identifier referred to as IRNs in EMPI. In order to communicate with SUCCESS and $TARS, SACWIS also maintains the IRN for each Person identified in the case. The interface between SACWIS and EMPI facilitate obtaining the IRN from EMPI via the following process.

The Case Manager is provided the opportunity to obtain the IRN from EMPI via a real-time inquiry button on the Person Identifiers Detail page. The button is accessible by this navigation scenario:

The user selects the Person tab in the second level of navigation. That action directs the user to the Person List page where a list of all Persons in the case displays.

Next, the user selects a Person from the Person List by clicking the Name hyperlink. That action navigates the user to the respective person’s Person Detail page.

Finally, the user expands the Person Identifiers sub module and clicks the Add button. Clicking the Add button navigates the user to the Person Identifiers Detail page.

The Client Registration System (CRS) maintains client information (including demographics) and a unique #[.line-through]#common-identifier[.line-through]# for each client served by other DHR systems. Systems including SUCCESS (TANF, Food Stamps, Medicaid) and $TARS (Child Support) maintain information leveraging this unique CRS identifier referred to as IRNs in CRS. [.line-through]#In order to[.line-through]# communicate with SUCCESS and $TARS, SACWIS also maintains the IRN for each Person identified in the case. The interface between SACWIS and CRS facilitate obtaining the IRN from CRS via the following process. #

[.line-through]#Case Manager is provided the opportunity to obtain the IRN from CRS via a real-time inquiry button on the Person Identifiers Detail page. The button is accessible via the following navigation scenario. The user selects the Person tab in the second level of navigation. By clicking the Person tab, the user is initially directed to the Person List page where a list of all Persons in the case displays. The user must then select a Person from the Person List by clicking the Name hyperlink; this action navigates the user to the respective person’s Person Detail page. Next, the user expands the Person Identifiers sub module and clicks the Add button; clicking the Add button navigates the user to the Person Identifiers Detail page. #

On the Person Identifiers Detail page, the user selects the “CRS ID” in the Type drop down and clicks the “Get CRS ID” button to initiate the real-time inquiry to obtain the IRN from CRS.[.line-through]# #

New EMPI data alerts will be displayed on the Staff To Do List Page and Case To Do List Pages respectively.

On the Person Identifiers Detail page, the user selects the “EMPI ID” in the Type drop down and clicks the “EMPI Request” button to initiate the real-time inquiry to obtain the EMPI ID from EMPI. Once the user clicks the “EMPI Request” button on the Person Identifiers Detail page, the user is taken to the EMPI Inquiry page. For additional information about the EMPI Inquiry page including mock-ups, see the EMPI Inquiry detailed design.

Once the user clicks the “Get CRS ID” button on the Person Identifiers Detail page, the real-time inquiry to CRS is initiated by calling the HRRSSCRN request in CRS via the interface.[.line-through]# #

The following table describes the EMPI attributes either sent to or received from the EMPI system. For additional details of the interface please refer to the Appendix A: EMPI Source to Target Mapping document.

The following table describes the EMPI attributes either sent to or received from the EMPI system. For additional details of the interface please refer to the document.

After the Case Manager clicks the “EMPI Request” button on the Person Identifiers Detail page, the HRRSSCRN inquiry request initiates in EMPI via the interface and attempts to locate the Person/Client. If the result set contains no matching records, or the result set contains records with a matching percentage of less than 90%, the Registration button will be enabled. If the returned results do not contain the client the user is looking for the user can click the Registration button, which displays the EMPI Registration page. For additional information about the EMPI Registration page including mock-ups, see the EMPI Registration detailed design.

The following table describes the EMPI attributes either sent to or received from the EMPI system. For additional details of the interface please refer to the document.

The following table describes the EMPI attributes either sent to or received from the EMPI system. For additional details of the interface please refer to the document.

When the user selects one of the matching records from the returned list after screening, and successfully saves the EMPI ID in SHINES by clicking ‘Save’ button on the Person Identifiers Detail page, SHINEs will inform EMPI about our participation in regards to that individual.

Whenever an individual is selected from the screening process, the EMPI ID and update information will be stored in a new SHINES EMPI Update outbound table. Web Methods will implement a new web service to process the records in that table and send the stored data in an Update request to EMPI.

The following table describes the EMPI attributes either sent to or received from the EMPI system. For additional details of the interface please refer to the document.

As EMPI acts as a central hub for person data for different data source agencies, such as $TARS and SUCCESS, SHINES will receive alerts for any changes made to that Individual in EMPI from other participating systems through the Alert web service from EMPI. SHINES will need to develop a web service to consume the changes sent. EMPI will invoke the Alert web service to send the alerts to case managers within SHINES on update and merge events for the Individual that exists in SHINES on the request. Unmerge actions will not be performed within SHINES to prevent the altering of identifiers tied to different individuals in SHINES. Within the $TARS and SUCCESS systems, one or more identifiers may be linked to the same individual however, that may not be the case within the SHINES system.

Update Alert: For the Update event, the updated Individual record will be sent from EMPI to SHINES along with the Alert web message containing the Data elements that are changed and a message code indicating what Data elements have been changed. The Update record will contain a set of mandatory data elements (first name, last name, race, ethnicity, gender) and also other data elements (refer to the Alert Data Elements tab for a list of the data elements for which Alerts need to be sent). This information will be displayed on the Individual’s Person Detail page under EMPI Data Changes section where changes can be made if a user with appropriate rights is on the person’s related open case. Otherwise, the information will be displayed on the Individual’s Person Detail page with editing options disabled. An alert will be sent to the primary case manager and their case hierarchy informing them of this new demographic information.

A new section titled EMPI Data Changes has been added to the Person Detail page in a new submodule. If an individual currently has no Open cases, this section will not display. If a user is currently viewing the Individual’s Person Detail page on an Open case and Closed stage, this demographic information will display but will be unmodifiable. If a user is currently viewing an Individual’s Person Detail page on an Open case and Open stage, this demographic information will display and will be modifiable. In this section, two columns will appear with the SHINES versus EMPI information for the targeted individual. A case manager can make changes by selecting the checkboxes on each row of the desired change they would like to make. These changes can be applied to the targeted individual’s SHINES data by selecting the “Update” button. When no checkboxes have been selected, no changes are made and therefore, considered not accepted.

Merge Alert: For #[.line-through]#any #[.line-through]#person merges[.line-through]# done#, by participating systems $TARS and SUCCESS[.line-through]# on an Individual that SHINES has notified EMPI about#, #[.line-through]#EMPI When an EMPI merge is requested by any non-SHINES participating system to EMPI, EMPI informs all systems including SHINES of the merge request via the data steward process. Upon arrival approval from all participating systems, including SHINES, to perform the merge, EMPI will invoke the Alert web service to send a response that contains the Key Message block and Client ID block data elements. If the SHINES individual in the alert currently has an EMPI ID that does not match the non-SHINES active EMPI ID in the request, their the individual’s EMPI ID is inactive will be deactivated and end-dated. The active ID in the request will be made their active EMPI ID. If the SHINES individual in the alert currently has an active ID that matches the active ID in the request, no change will be made as their current ID is already the active EMPI ID in SHINES for the merged EMPI Individual. An alert will be sent to the primary case manager and their case hierarchy informing them of this new merge information related to the Individual on the request that exists in SHINES, regardless of whether they are active or inactive.

Unmerge Alert: For any person unmerge performed, by participating systems $TARS and SUCCESS[.line-through]# on an Individual that SHINES has notified EMPI about,# When an EMPI unmerge is requested by any participating systems to EMPI, EMPI informs all systems, including SHINES, of the request. EMPI will invoke the Alert web service to send a response that contains the Key Message block and Client ID block data elements corresponding to the newly created Client ID. SHINES will simply store this information in the inbound database table and no other action will be performed.

All EMPI data that is received through the interface will be saved in the SHINES database for audit purposes. The latest EMPI data in the Alert response will be programmatically compared to the current SHINES database data. If the values differ, a SHINES task/alert will be generated to the Case Manager or Supervisor to notify them of the changes and prompt them to either accept or reject the changes under the Staff to-do list.

Upon approval of the task, the #[.line-through]#selected #[.line-through]#changes will be #[.line-through]#systematically applied to the database and[.line-through]# the updated data and change history#[.line-through]# will [.line-through]#be displayed[.line-through]# in the [.line-through]#P[.line-through]erson #[.line-through]#Detail #[.line-through]#page and its sub-module pages. Upon reject[.line-through]ion[.line-through], no changes #[.line-through]#will be #[.line-through]#made to the SHINES application. #[.line-through]#T[.line-through]he #[.line-through]#database will be updated with either the #[.line-through]#approval or reject[.line-through]ion[.line-through]# information#. #[.line-through]#However, i[.line-through]f the current SHINES data and the #[.line-through]#EMPI data from the Alert response #[.line-through]#are the same, a task/alert will not be sent to the Case Manager or #[.line-through]#Supervisor[.line-through]# and the [.line-through]#change history[.line-through]# will not be displayed [.line-through]#in[.line-through]# the Person Detail page#[.line-through]# and its sub-module pages. #

The following table describes the EMPI attributes either sent to or received from the EMPI system. For additional details of the interface please refer to the document.

The SACWIS application invokes a web service through the WebMethods ServiceNet interface and the data is encrypted by SSL. WebMethods invokes the CICS transaction by parsing the XML fields in the SACWIS request payload and passing them on to the COBOL CICS transaction. The COBOL process then performs the search, and returns 250 rows. The WebMethods interface converts that data into XML, and returns the values in real-time to SACWIS. SACWIS then parses the XML and display the results using the CRS Search Results page.

This message contains demographic information for a client within SACWIS to perform an inquiry against client records already in CRS. CRS will perform an inquiry operation by invoking the CICS HRRSSCRN function on the mainframe, and this function will use the values in this message as search parameters.

Here is a potential sample message:

See Section 1.3.3

See Section 1.3.4

Case Managers enters details on each person in a case on the Person Detail page. The user must* *enter a valid Social Security Number, along with first and last name, gender, race, and ethnicity in order to initiate the CRS search. Date of birth may also be used if available and known. The user presses the “Get CRS ID” button on the Person Identifiers Detail page (button displays after selecting CRS as the Type) to invoke the search for that client. If the user supplies an SSN and the CRS search returns no matches, the application removes the SSN from the search criteria and searches again based on the demographic data. Search results are then displayed on the CRS Search Results page.

CRS is a real-time user interface, so the SACWIS user is informed of errors right away. If the web service is not available, the user is informed accordingly and requested to try again at a later time. I f there is a failure on the mainframe side, the user is informed accordingly and asked to try again at a later time.

Validation of SACWIS data occurs on the respective pages. No additional field level error handling is required.

None

Web Service, CICS, and other application failures are reported to the user, and the user is requested to try the operation again at a later time.

CRS ID request is initiated by the Case Manager selecting ‘CRS’ as the Type on the Person Identifiers page and then clicking the displayed “Get CRS ID” button.

The user entered information must match with CRS on SSN, last name, gender, race, and ethnicity to be considered a true match. If a social security number is specified as search criteria, the CRS interface first searches using the SSN. If no match is found based on SSN, the SACWIS application removes SSN (as a search criteria) and searches CRS again behind the scenes.

To summarize, screening without an SSN performs a search on the demographic info passed as follows:

FIRST CHECK BY SSN (if available)

SECOND CHECK BY (LAST, FIRST, MIDDLE, SUFFIX, DOB, RACE, SEX)

If no matches: Remove DOB as a search criterion.

THIRD CHECK BY (LAST, FIRST, MIDDLE, SUFFIX, SEX, RACE)

If no matches: Remove Race as search criteria

FOURTH CHECK BY (LAST, FIRST, MIDDLE, SUFFIX, SEX)

.

The SACWIS application invokes a web service through the WebMethods ServiceNet interface and the data is encrypted by SSL. WebMethods invokes the CICS transaction by parsing the XML fields in the SACWIS request payload and passing them on to the COBOL CICS transaction. The COBOL process then adds the client to CRS. Next, the WebMethods interface converts the relevant data into XML and returns the values in real-time to SACWIS. SACWIS parses the XML, displays result on the Person Identifiers Detail page, and stores the IRN in the Oracle database.

This message contains name, Social Security Number, and demographic information for a client in SACWIS for purposes of registering that client (creating a record for the client) in CRS. CRS will validate the information and create the record when the HRRSREGS CICS function is invoked on the mainframe.

See section 1.4.3

See section 1.4.4

Case Managers enter the details of each person on the Person Detail page. If the CRS search request does not return any search results for the respective person, the user can then register the person in CRS as a new client clicking the Add to CRS button on the CRS Search Results page. This registration process creates the client in CRS via a real-time, synchronous web service call.

CRS is a real-time user interface, so the SACWIS user is informed of errors immediately. If the web service is not available, the user is informed accordingly requested to try again at a later time. If there is a failure on the mainframe side, the user is informed accordingly and also requested to try again at a later time.

Data validation and transformation occurs in SACWIS prior to reaching CRS. Therefore, no additional field level validation is required in the interface.

None

Web Service, CICS, and other application failures are reported to the user, and the user is requested to try the operation again at a later time.

The Register request is initiated by clicking the “Add to CRS” button on the CRS Search Results page.

None