We receive two files from EPIC per affiliate every day: the Patient Visits file and the Future Visits file.
The patient visits file contains all visits with a discharge date where (1) the Primary financial class is not Medicaid, (2) the visit is not associated with a research project, and (3) the visit is not being billed professionally (instead of by the hospital).
The future visits file contains visits scheduled to appear up to 365 days in the future where (1) the Primary financial class is not Medicaid, (2) the visit is not associated with a research project, and (3) the visit is not being billed professionally (instead of by the hospital).
Epic visits data is available on the Patient Detail tab and in the ad-hoc query node EPIC patient visits. Some of the fields unique to this node are
- Account ID. In Epic, this is referred to as HAR (Hospital Account Record); it’s a value used to group charges for billing purposes. In Atlas, we use it to group multiple encounters into a single visit.
- Employer ID and Name. This may be provided by patients at the time of the visit. It’s not considered very reliable.
- Guarantor constituent name. This is the name provided as guarantor for the visit unless guarantor was listed as “self”. The import procedure creates constituents out of the guarantor data (as well as a relationship to the patient if one was provided); this information is available in the Guarantor node described below.
- Guarantor relationship to patient. If the guarantor on the visit was not “self”, it was a relationship like Mother, Father, Grandparent, or Sister. The import Job does not attempt to create relationships in these cases, but the Guarantor constituent record is created. The guarantor relationship to patient field in ad-hoc query can help determine the type of relationship, and that relationship can be built manually if needed.
- Is confidential. This can be set one of two ways.
- PHS Type The PHS Type field has multiple purposes, including identifying employees and confidential constituents. If PHS Type is set to “confidential” on a visit, that visit won’t be available in the EPIC patient visits node, but only in the EPIC patient visits – restricted node.
- Private Encounter(s) See below.
- Is future visit. This column is set to Y if the visit is schedule to appear in the future.
- Is sensitive. This column is set to Y if the visit was considered to have a “bad outcome”; this is based on a hard-coded list provided to the EPIC reporting team.
The EPIC patient visits node has three sub-nodes: Encounters, Guarantor, and Patient
The Encounters node is where you’ll find details about the visit, including department, location, and type (e.g. office visit). Think of a visit as being made up of multiple encounters. Some of the other unique fields available here are
- Is Private encounter. There is a Federal regulation (42 CFR) that establishes some additional confidentiality requirements for patients who are being treated for substance abuse. MGB is required by this law to mark these visits as confidential, and this is done via the privacy encounter flag. Patients for specific departments/programs are automatically marked with this flag. In some cases, the patient has requested that the encounter be considered private or confidential. When Is Private Encounter is set to Y, that encounter won’t be available in the EPIC patient visits node.
The Guarantor node joins to the Constituent node for the visit guarantor, unless that guarantor was “self” in the EPIC data file.
The Patient node joins to the Constituent node for the patient.
Good to Know!
- Patient Pronouns are currently only visible in ad-hoc query and in the data warehouse. If a patient has opted for multiple pronouns, they will all be listed in this one column, separated with a semicolon.
- A global change to delete future visit records once they have occurred (or have been cancelled) runs daily.
- Per policy, new constituents are not created from records in the Future Visits file.
- Private and confidential visits are not visible in the EPIC patient visits node, but they are available in the EPIC patient visits – restricted node. Only users with the Atlas | Epic Confidential Visits system role have access to this node.
- Discharge date is X months prior to current month and Discharge date is X years prior to current year. These fields can be used to select dates relative to today, which is helpful when creating selections for use in marketing based on visit dates.
- By default, Epic visits are considered confidential if (1) the PHS Type field equals “confidential” or (2) any one of the associated encounters is marked “private”. You can override this setting via the EPIC Hospitals table setting Display private encounters.
- Occasionally, Guarantor relationship to patient is not blank, but Guarantor name is; this likely means that BVDL was unable to create the relationship record and generated an exception during processing.
- Account ID (HAR) is required in Atlas. When the Epic files include records without HAR, those visit records are considered incomplete and not imported into Atlas, except for CDHC VNA future visits. The VNA workflow does not include creating HAR until the visit is complete, so the VNA future visits file never contains it; for the VNA import only, the BVDL job creates a placeholder value so the records can be imported.
How Do I?