In the “paper” world, external users (researchers, auditors, insurance reviewers, etc) would go to medical records with a listing of patients and appropriate authorization forms. Medical records staff would then pull the paper charts that needed to be reviewed. These external users would only have access to the patients/charts that were presented to them.
How will these external users access the information that they need in the EMR world? More specifically, how do we control which patients, charts, and specific information these users will have access to, and how do we log the release of this information?
For the Epic Application, there are a few workflows that could be used to for external requesters:
Release to Inspector:
This is the Epic standard workflow and has the most controls regarding what information is released to the external requester. However, this workflow can be labor intensive for the HIM staff. The workflow requires the HIM staff member to open a release record, select the appropriate encounters and/or individual items, associate an “Inspector Key”, then print a letter. If releasing information on multiple patients to the same requesting party, HIM staff would have to do a release record and select appropriate information for each patient, then associate the same key to each release. The final step would be to print a letter that includes the Inspector Key for the requesting party. The requesting party would then log in to specified workstations and enter their Inspector Key. The information released to these users would be presented in a PDF format.
Pros:
- Most control over what information is released.
- Disclosure logging and documenting consent forms are already included into the workflow for creating releases.
Cons:
- Workflow is labor intensive on HIM staff when there are many patients.
- If the initial release(s) did not contain all of the information required by the external party, each release would need to be redone.
Build Elements:
- This is a standard workflow, so the build should be part of the model. Generic user records can be used for the requesting parties as the accessible information is controlled by the Inspector Key.
- Requester record added to the Requester Database
- Designated workstations are generally set up in the HIM department for the external users. These workstations generally attach to the network with generic network logins.
- Consent forms: Logging of consent forms is standard functionality of this workflow.
Inbasket workflow:
This workflow uses Inbasket functionality to access patient records. HIM staff creates and Inbasket message and attaches a patient record. A separate Inbasket message is needed for each patient record. This process is a lot faster than the ROI Kiosk workflow. The Inbasket message can be sent to the individual user or a pool of users. The external user will log in and access the patients’ charts via the Inbasket message(s), and can navigate in chart review to find the data that they need. The external user(s) will not have access to “look-up” any patient so their access is limited only to the patients listed in their Inbasket.
Note: This workflow work should be used only if accessing all encounters for the patient is required. This work flow may not be appropriate for multiple hospital systems where access to specific encounters should be restricted.
Pros:
- Workflow process is quicker for HIM staff. External users can navigate chart and review to find required information.
Cons:
- External user has access to all encounters for the patients that they can access.
- Logging disclosures will be a separate process (manually entered, or potentially by batch import)
- Logging consent forms will also be a separate process
Build Elements.
- Menus and User Role:
- External user menu and tool bar should not have any buttons. Inbasket should be start up activity. Additional start up activity could open a tutorial page on the facility intranet that contains instructions on navigating chart review.
- Security:
- Read only access to the EMR data
- No send option for Inbasket messages (user should not be able to send Inbasket messages)
- Profile and associated items (Chart Review Tabs/ Reports, etc)
- A profile is needed to control what types of information will be available to the user in chart review. Reports, Chart review tabs, note type restrictions, filters, etc are built into the profile.
- Inbasket:
- Users Inbasket tool bar should have buttons for chart review and to complete the Inbasket message.
- The report that is displayed in Inbasket could contain instructions on navigating chart review if the web page option is not used.
- Inbasket pools could be used if multiple users need to access the same set of patients.
- Disclosure Reporting / Consent Forms: A process should be in place for logging these disclosures and forms.
Hospital Billing Work Queues Workflow:
In this workflow, the patient’s accounts are sent to a work queue. These accounts are generally added manually to the work queue by HIM staff. In certain scenarios, such as insurance reviews or collection agency accounts, the work queue could be automatically populated with accounts that meet specific criteria. The external users would only have access to the patient’s accounts that are in their work queue, and would not have access to “look-up” any other patients. We can control which parts of the EMR can be seen by controlling which reports are available. Additionally, they will only have access to the EMR data for the encounter(s) associated with the specific account, but we will also have the option to allow access to all encounters for certain groups of users.
Pros:
- Workflow process is quicker for HIM staff, or in some cases, the accounts can be added automatically.
- External users can navigate reports find required information.
- Option to limit access to specified encounters is available.
- Access to chart review (all encounters for the patient) can be granted if needed for specific groups of users.
Cons:
- Logging disclosures will be a separate process (manually entered, or potentially by batch import)
- Logging consent forms will also be a separate process
Build Elements.
- Menus and User Role:
- External user menu and tool bar should not have any buttons. Work queue should be start up activity. Additional start up activity could open a tutorial page on the facility intranet that contains instructions on navigating the work queue and associated reports.
- Security:
- Read only access to the EMR data
- Hospital billing security needs to be analyzed and built to control access to Account specific information. In some scenarios, access to data and even functionality may be deemed appropriate.
- Reports:
- Reports are built to display the parts of the EMR that are required
- Work Queue:
- Users Work Queue tool bar should not have buttons that allow patient lookup
- Multiple users can have access to the same work queue
- Profile and associated items (Chart Review Tabs/ Reports, etc)
This part is only needed if access to chart review is included.
- Reports, Chart review tabs, note type restrictions, filters, etc are built into the profile.
- Disclosure Reporting / Consent Forms: A process should be in place for logging these disclosures and form.
As you can see there are a lot of factors to consider when determining the best approach to providing external user access to EMR’s. For assistance defining the optimal workflow for your healthcare organization, feel free to email us at contactus@santarosaconsulting.com.
Brian Hino
Santa Rosa Consulting