LSI-Template Solution

Usecases and Data Flow

1. OneKey Updates (OneKey ➔ Client)

   This service delivers all the data that has been updated since the previous delivery. In the initial delivery all the data subscribed by the client are sent. A processing code indicates the action to perform: “I” for Insert, “U” for Update, “R” for entities that are re-sent following client request and ‘D’ for entities that has been removed from the target group.

2. Validation Requests (Client ➔ OneKey)

   This service allows validating client data based on OneKey reference database. The database operators compare the validation request data with OneKey data and after investigation and phone verification, can accept or reject the client request. A validation report is delivered back to the client with the answer (Accepted/Rejected) and a comment from the database operator in case of reject. OneKey database might be updated if needed. OneKey data is sent to the client in case of an update/creation or even in case of a simple verification with no modification (reset option).

The requests can involve:

• New entities that Cegedim don’t have or that were not sent to the client (out of target group) => creation requests
• Existing entities, already sent to the client => update requests

More generally, the client might not know if it’s a creation or update request. The core idea is that the client provides the information he has in order that Cegedim check its validity. One of the most important information to provide is the Cegedim OneKey id (for update requests).

Workplace validation request: Cegedim validates the existence or not of a workplace or one of its department based on mainly its address and name

Activity validation request: Cegedim validates the existence or not of an activity for a given individual and address (or workplace). The workplace is identified by its address or name and the individual by its name and type.