caBIG Clinical Information Suite Service Interaction Scenario

1. caBIG Clinical Information Suite Service Interaction Scenario January 2011

2. Purpose The purpose of this presentation is to describe in a high-level detail the interaction scenarios in the Mid-January release This deck is for discussion purposes This scenario and components are based on an understanding

3. Conceptual Flow

4. Access Scenario • Access is based on a referral from a portal access • It is assumed the access is coming from an external organization (not from NCCCP site itself) • It is also assumed the referral organization has its own IDAM and can support SAML based federation • The registry services will be those at the NCCCP site

5. Interaction Scenario • Log on to Portal (This is an SSO using existing login session of the user on local systems. The SSO client will facilitate a SAML 2.0 token to send over to the Portal). • Create Referral: During the create referral a request is sent for creating a referral in CaCIS. In this Interaction scenario the login process is also demonstrated process and system flow, authenticated or authorized to use the system. Therefore flow 2-5 will facilitate this process. • At this stage the ESB is validating against the User Registry if the user exist. If the user does not exist an error message is generated and process flow will terminate. • The federated ID, if it is the very first time the user attempts to log in the user would not exist in the User Registry • Federated Service will coordinate an automated registration of the user in the User Registry. This process is simply done by populating the user into the appropriate group/groups associated with the source organization as well as the user roles assigned to the user in the SAML token • After validating the user, the ESB will send an authentication request to the Authentication Service. This service will receive the user credential (SAML token mapping to local token) of the user and validate against its own records before granting authentication. The Authentication Service will comply with all appropriate policies and procedures as part of each deployment site. It is important to keep in mind that in some deployment scenarios this service may already exist as a local service. If the username and password combination do not match the system expected username and password an error is produced, and the flow is terminated. The Authentication Service is based on LDAP and at this point the ESB will communicate through LDAP calls

6. Interaction Scenario Cont’d • Upon a successful authentication the ESB will then query the Authorization Service for the coarse grain authorization of the user. The coarse grain authorization is simply to determine whether the user has access privilege to the application. As part of this request the membership enrolment of the user is also requested (this is the mapping of the SAML membership to local groups) If the user does not have the permission the use the system an unauthorized message is generated and the flow is terminated. This authorization service is also an LDAP service that identifies group membership • An authenticated and authorized user will receive an authorization token from the ESB that includes the enrolment membership of the user. This allows for the user to access any of the subsystems that the ESB has access to and the user is permitted to access. If the token is not presented, invalid, or expired the user is prompted to authenticate again. This is a local token that is mapped back to the SAML. • At this phase the actual “create referral” is initiated. The patient is validated by a query made to the Patient Registry. The required patient information is retrieved and passed back to the ESB cached on the ESB. • The provider is also validated. The Provider Registry is queried by the ESB and the information is cached on the ESB as part of the request.

7. Interaction Scenario Cont’d • Similar the step 6 and 7 the location is also validated against the Location Registry and cached. • Once the patient, provider, and location have been identified (cached on the ESB as part of the same “create referral” request) the Consent Registry is queried by the ESB to determine if there are any consent directives that prevent the provider from accessing any information of the particular patient. There may also be some restrictions place on the location where the user is located that may prevent access. These are business decision that are unique to each deployment site and are yet to be developed. In the event of a consent directive block, a message is sent back to the user informing them that they are unable to access information on the patient requested due to consent restrictions. • During this step ESB is sending the “Create Referral” request to the Referral subsystem. • Once the referral is created the Referral subsystem will send the response back to the ESB. • ESB will forward the response from the Referral subsystem to the requestor that the referral has been created. • All the above processes, the success of the process, or any error messages are logged to the Audit Service.