RX205 Willow Inpatient User Configuration - Chapter 1: Epic's Data Structure Flashcards
Hyperspace
Epic’s front-end user interface, accessed on the Hyperdrive client
end users log into Hyperspace to complete their workflows and do their jobs
admins and builders also log into Hyperspace to test and troubleshoot build
Hyperspace Web
web server that runs the web-based application, Hyperspace
when you launch the hyperspace icon, you are launching a specialized web browser called Hyperdrive –> the Hyperdrive client presents the Hyperspace Web application to users, like a commercially-available browser (eg. Chrome) presents a web site
Chronicles
the data management system (“the database”) that provides the underlying structure for all of Epic’s applications
users and admins access Chronicles via a number of paths, including Hyperspace, the Classic client, and Text
all the data that users access in Hyperspace lives in Chronicles
- when a user logs into Hyperspace and opens a patient chart, Hyperspace is requesting data from Chronicles
- when a user documents in a patient’s chart, they are saving data to Chronicles
Classic
the original Hyperspace client
as of the May 2022 release, all end-user facing activities are available in the new, web-based Hyperspace but many admin activities are only available in the Classic client (have yet to be migrated)
when migration is complete, the Classic client will be retired
Text
text-based back-end interface with Chronicles data, used solely by admins for creating, editing, and analyzing records
Text runs directly on a server that hosts Chronicles and you connect via a terminal emulator (eg. PuTTY in training, or Reflection)
there will always be some tools and editors that only exist in Text; will not be retired
includes multiple applications: Clinical Administration, Chronicles itself, Training Tools, etc
master file
aka INI
stores all the data about one type of thing
examples =
- patient data in the Patients master file
- clinician info in the Provider master file)
like a drawer in the Chronicles filing cabinet
INI
aka master file
stores all the data about one type of thing
examples =
- patient data in the Patients master file
- clinician info in the Provider master file)
like a drawer in the Chronicles filing cabinet
record
stores info about one individual or entity in the master file
examples =
- each patient has a record in the Patient master file
- each combination of drug/strength/form has a record in the Medication master file
like a folder in a drawer (master file) of the filing cabinet (Chronicles)
item
set of prompts or fields for storing information
examples =
- gender
- smoker
- MRN
like fields you fill in on each file folder (record)
value
every record in the same master file has the same set of items, but each record will have a different set of values
examples =
- male/female
- yes/no
- dates (string values)
what you write in the fields (items) on each file folder (record)
contact
set of values within a single record that relate to a particular event or significant change to that record
examples =
- patient record contacts can be visits, telephone encounters, admissions
- order record contacts mark when an order is signed, verified, dispensed, administered
like dated sheets of paper in the file folder (record)
record viewer
a utility for looking at the data stored in Chronicles for particular records
available in Classic to admins and others with proper security
path: Classic»_space; main toolbar»_space; Record Viewer
no-add items
values associated with a record and NOT a single contact
stored at the record level
over time items
values associated with a single contact
stored in a specific contact
Clinical Administration
a back-end application within Text to modify data in Chronicles
networked
when a value in Record Viewer is linked to another record
appears as a hyperlink
category list
every item in Chronicles has a data type, which determines what kind of data the item can store as a value
a category data type has values that will be selected from a list of possible options, called a category list
a category list is a list of potential values for a particular item; it is part of an item
shared category list
some items have a “category” data type but re-use the category list from another item (eg. yes/no, gender)
string data type
value is free text, any string of characters
release range
some category lists have release ranges, meaning Epic code expects those options to exist. you cannot edit the category options in that range.
you can see the release range for a category list in the Category List Maintenance activity
ALL CUSTOMER OWNED = no release range, can edit all options in the category list
ALL CATEGORIES = entire category list owned by Epic, you cannot edit, deactivate, or add choices to the list
FROM X TO Y = can’t edit options with IDs between X and Y but you CAN create and edit options outside that range
facility
the entire enterprise or “instance” of Epic, aka your
entire organization
this level was named a long time, before largescale
consolidation in the industry
broadest facility structure
service area
separate business entities within your
organization, or that you use your install of
Epic
used for grouping revenue and accounts
receivable
nested immediately under “facility” structure
location
a hospital or free‐standing clinic
there’s a separate Location (EAF) record for each
hospital and clinic in your organization
location records are where we attach:
- formulary
- main pharmacy for a hospital/clinic
- content that appears on the Facility List
nested immediately under “service area” structure
department/unit
places where patients receive care, and/or where users work
includes:
- nursing units in a hospital, where patients are admitted (“EMH 1 East” or “EMH 2 West” or technically “EMH Emergency”)
- outpatient departments, where patients make appointments, receive care, and go home (“EMC Family
Medicine,” or “EMH Allergy Clinic”)
- hospital outpatient departments, which can see both admitted patients and outpatients (“EMH CT Imaging” or “EMH Cardiac Cath Lab”)
- virtual departments, which never have patient encounters and exist only for users to pick as their login department (“EMH IP Pharmacy” or “EHS Internal
Medicine” or “EMH Admitting Department”)
department/unit records are where we attach the list of Pharmacy (PHR) records that serve patients in that unit
Willow users also log into a “virtual” department for their hospital’s pharmacy
nested immediately under “location” structure
room and bed
these records only exist in nursing units or some hospital outpatient departments
they represent the specific place where a patient gets admitted
appears on dispense labels, ADS load labels, and cart fill reports to help identify where the patient is
some hospitals will configure dispense logic (the list of pharmacies serving a patient) for specific sets of rooms in a unit
nested immediately under “department/unit” structure
how to edit values in a category list
describe the relationship between Hyperspace, Classic, Text, and Chronicles
