Data Seperation

There is a requirement to keep each client's data seperate from each other and also not allow one Requestor to see another Requestor's data.

In order to access the data a token is required, in that token there is:

  • The Program Area code the person is logged on under
  • The Requestor Role are logged on as or are working on behalf of

Restriction by Program Area

To keep client data seperate some of the data will live in Program Area specific partitions. For example ODSP requests will be in ..\ODSP\ServiceRequest. The table below illustrates where data will be stored based on the resource\profile.

FHIR Resource Profile Partition
Communication Announcement DEFAULT
Communication ClientCommunication Program Area Code
Communication OutgoingEmail Program Area Code
Consent TermsOfUseConsent Program Area Code
DocumentReference RequestPDF Program Area Code
DocumentReference TermsOfUse DEFAULT
Location RequestorLocation DEFAULT
MessageDefinition MessageTemplate DEFAULT
Organization ProgramArea DEFAULT
Patient Applicant Program Area Code
Practitioner FlexFormPotentialUser DEFAULT
Practitioner FlexFormUser DEFAULT
PractitionerRole FlexFormsRole DEFAULT
Questionnaire FlexForm DEFAULT
QuestionnaireResponse FlexFormResponse Program Area Code
ServiceRequest Request Program Area Code
ServiceRequest RequestSubmission Program Area Code
ValueSet n/a DEFAULT

Restriction by Requestor Role

To keep users from seeing and modifying other user's data there are restrictions based who the current Requestor Role is (or who they are working on behalf of in the case of Delegates and Designates).

These are the resources/profiles that need to know what Requestor Role owns that data and where the Requestor Role is stored in that resource.

FHIR Resource Profile Requestor Role Element PHI Read Write Description
Binary Attached Document Binary.securityContext Yes No No For each resource that stores binarys here is where to get the Requestor Role:Client Communication, Communication.partOf = Requestor Role; Outgoing To Prescriber, Communication.partOf = Requestor Role; Questionnaire Response, QuestionnaireResponse.author = Requestor Role; Request PDF, DocumentReference.author = Requestor Role
Communication Announcement n/a No Yes No Where category.code='PROGRAM_ANNOUNCMENT' in DEV they are not using this correctly
ClientCommunication Communication.partOf Yes No No category='CLIENT'.
OutgoingEmail Communication.partOf Yes No No category='OUTGOING_EMAIL'.
Consent TermsOfUseConsent n/a No No No There are 4 different types of Consent, Submit Consent is the only one tied to a request, We allow Read everything. And Write only if the current users role = performer
DocumentReference ODSPDataLoad n/a No Yes No
TermsOfUse n/a No Yes No Where type.code is in (TOU-General,TOU-Submit,TOU-DELEGATE,TOU-DESIGNATE). Nobody can write, this is preloaded data.
RequestPDF DocumentReference.author Yes No No Where type.code = RequestPDF
Location RequestorLocation n/a No Yes No For Release 1: no checks. For Release 2: Check to see if location is associated with the User's current role. If role is Requestor or Delegate check locations of associated Practitioner Role. If the role is Designate check the locations associated with this role.
Patient Applicant Patient.generalPractitioner Yes No No Each Patient record belongs to only one request so only the Requester of that request can view/modify the record.
Practitioner FlexFormUser n/a No Yes Yes Since the qualifications, name, telecom, active flag and identifier get reset/updated from CPDB every time the user logs in it doesn't really matter someone tried to change it using a product like Postman. We need to keep this writeable because Requestors can andd Delegates and Designates
PractitionerRole FlexFormRole RelatedRequestorRole No No No Using Team Maintenance users should only be able to modify members of their own teams. RelatedRequestorRole is the owner of the team.
Questionnaire FlexForm n/a No Yes No This is preload so nobody can write.
QuestionnaireResponse FlexFormResponse QuestionnaireResponse.author Yes No No
ServiceRequest Request ServiceRequest.requester No No No
Subscription n/a n/a No No No All Subscriptions should be read-only. They are part of the application configuration