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 |