Mount Sinai Requirements for First Release Integration

Introduction and Background

Mount Sinai Hospital and Seaton House Men’s Shelter (Inner City Health Associates) are preparing to share client information with each other. This will be the first release of integration. Mount Sinai has been an active and supportive agency with the CAISI Project. Sue Owen, the Director of Corporate Planning, is currently the Chair of the CAISI Agency Committee whose members are representatives of participating agencies. This sharing of information will take place in the Emergency Department.

Use Case Scenario Mount Sinai Hospital

As per PHIPA, signs will be posted in the Emergency Department at Mount Sinai Hospital (MSH) at street access and at registration desk and triage/nursing station explaining that those indicating No Fixed Address or residence at Seaton House will have their Seaton House medical files accessed through the CAISI system.

will search name & access file if have one
may disclose PHI to ICHA by inputting PHI into file
can withdraw consent

Client information accessed:

Individual enters the Emergency Department, fills out MSH registration form
Registration Clerk notes that there is no fixed address on the form
Registration Clerk searches the CAISI system to see if they are a client at Seaton House
If their name appears the clerk notes the type of consent used (express or implied) and the presenting problem; the client is automatically admitted to MSH program
Registration Clerk prints off report and puts report in the patient's chart
Physician meets with patient and looks over report – wants to access more detailed information
Doctor logs into system as erDoctor and accesses client file where they can read information as well as contribute the client’s care plan

Client Incapacitated:

Individual enters the Emergency Department
They are incapacitated – can not fill out form or let Clerk know if they reside at Seaton House
Clerk searches for name if name is known, prints off report
If name is not known, the clerk searches for name once/if they find out the patient name

Client withdraws consent:

Individual enters the Emergency Department
They tell the Registration Clerk that they do not consent to the Clerk looking their name up in the CAISI database
The Clerk does not look their name up, the doctor cannot access the client’s file at Seaton House
Clerk gives the patient information and suggests that they speak with their doctor or counselor at Seaton House on how to opt out of the system

Search protocol

Search Engine

will have all names in the search engine
only 'medical information' (Personal Health Information created by Health Information Custodian at Seaton House - i.e. information added by OSCAR-CAISI 'doctor' role) will be visible
no other information will be visible; if there is no 'medical information' the file will be empty

Consent for Searching

searching will be dependent on consent
unless clients/patients expressly withdraw consent, consent will be implied
MSH will indicate type of consent when patient presents (implied, express)
Notification for ‘knowledgeable’ consent by signs & direct discussion

implied consent for the purposes of the ICHA - MSH integration will include the following criteria:

client has stayed at Seaton House after the notification date
client has a note entered into their CAISI record by a CAISI doctor role
client has not withdrawn consent (opted out)
it is less than a year (implied consent period) since the client was last at Seaton House.

if these criteria are met, then it can be assumed that the client has given implied consent and can appear in the search list at MSH

Consent Scenario at Seaton House

The 'medical information' collected by HICs (ICHA physicians & support staff) working at Seaton House is going to be configured to allow for MSH HIC access. This is how it will look for the user and the client:

Notification of data sharing with MSH for ‘knowledgeable’ consent
- First sign posted in SH: if you have medical records, will search name at MSH, records are available to MSH, can withdraw consent
- Second sign posted in SH: sharing will not start until X date, opt-out now if want but can opt-out later
- (Sign posted in ED waiting room)
- ICHA providers (doctors/counselors) will inform clients individually
Notification includes: MSH staff will be able to search for their name. When they visit MSH, staff will be able to register their visit into their CAISI record and then be able to access only their medical information. If there is not any medical information in the client’s file then the only data that a MSH staff would be able to access would be name and date of birth. MSH staff may enter data into their Seaton House file.
Clients will be given information on the controls in place to prevent staff from accessing their records when they are not at MSH, e.g. staff will only be able to see information if the visit is registered in their CAISI record - which will be easily seen in their file, also provincial laws, hospital rules, staff trained not to do so, electronic audit trail
If clients choose to opt-out, their name/file will not be searchable by MSH staff
Clients wanting to opt-out will speak with a designated person at Seaton House, who will explain consequences of opting-out (may lower quality of care)
If clients are in the Seaton House database but they have not been admitted to any program at Seaton House after the data set for data sharing to commence, their names will not show up in the search list (they have to be current clients, or clients who have been admitted after the date of notification in order to be exposed to this knowledge and have the option to opt out)

Technical Requirements

There are three main requirements that need to be met in order to facilitate the sharing of information between Mount Sinai Hospital and Seaton House:

Opt-out Process
ErClerk Access
ErDoctor Access

Opt-Out Process

Clients at Seaton House need to be able to opt-out of the information sharing between MSH staff and Seaton House Doctors.

This opt-out needs to remove them from showing up in the client search, so there is not any way for a provider at MSH to pull their record
This opt-out will need to be role based, as the information sharing will be taking place on one server. It should be linked to the Oscar roles Erclerk, ERnurse and ErDoctor
When a provider is logged in as Erclerk, ErNurse or ErDoctor, the opt-out feature would be enabled and those clients who have opted out would not be accessible in the client search
This should be built as a generalizable feature or with generalizability in mind, in other words, there may be other scenarios where a particular role would be defined as having certain limits placed in the search engine (similar to the limits placed on roles in programs - this would be a limit placed on the agency database)
All other staff at Seaton House with the Oscar Roles Doctor, Nurse and Administrator, would not have their client access affected by this opt out – all staff with those roles will not have their client access levels altered (they should be able to access the same client lists that they can access presently)

ErClerk Access

This Oscar role already exists in CAISI. It needs to be associated with the ‘opt-out’ function mentioned above. When a provider is logged in as an Erclerk they will not be able to access records of individuals who have opted out in the client search

ErDoctor, ErNurse Access This would be a new Oscar role. The ‘opt-out’ function needs to be linked to this role so that when a provider is logged in as an ErDoctor or ErNurse, they will not be able to search the records of clients who have opted out. This role will be able to access files of clients admitted to the service program “Emergency Department�?. This role can only access medical information. All client files should only contain:

Doctor’s notes
Doctor’s issues
Clinical Modules
Patient History
Allergies
Prescriptions
Programs currently admitted to (this is medical information e.g. Infirmary, Drinking program, Annex, Long Term Program, housing program etc.)

Non Medical informatio must be removed from the client’s record, including:

Access to the intake A, intake B
Access to any User Created Forms
Counsellor/CSW Issues
Counsellor/CSW Notes
Program History Tab

-Ticklers

Initial Implementation Details

As the initial implementation, I was asked to do the following:

add an opt out checkbox to the clients summary page
filter anyone who has opted out from showing up in the search pages (both search and searched caused by new intake)
upon intakes of people (existing, and new) into the system, they will be implicitly opted in

The expectation is that a role called "external" will be added. The opting process only affects the display of information for providers with that role.

There is a new configuration property in oscar.properties.

  DATA_SHARING_OPTING_DEFAULT=IMPLICITLY_OPTED_IN

There are currently 5 valid options for this property

comment it out, it means when new clients come into the system, nothing happens to their opting status.
IMPLICITLY_OPTED_IN
IMPLICITLY_OPTED_OUT
OPTED_IN
OPTED_OUT

There is no functional difference between the IMPLICITLY and non IMPLICITLY options, they are there for audit purposes only. IMPLICITLY means the client didn't actually say to opt in or out. So as an example for our above "Consent Scenario at Seaton House" we should set this to IMPLICITLY_OPTED_IN. Depending on he agency, one may choose to use IMPLICITLY_OPTED_OUT. Generally speaking the default should not be OPTED_IN or OPTED_OUT, it only makes sense to use these two if an agency explicitly/actively asks/tells the client every time they show up.

When upgrading to this feature, do NOT try to update any database records. I.e. existing Demographic records should have null as their opting status, those should stay as null. They are only changed from null to implicitly_opted_* when the client is readmitted into the system. (It's possible to do a database update to implicitly opt-out everyone if necessary but code wise, null is not opted in so it's not necessary from a security point of view, if you implicity opt-out people, they won't be implicity opted in on next admitance, only with with state null are changed to the default state on next admitance.)

Sections

Personal tools