Clinical Encounter CSV API
The following page defines data and fields that may be imported into MIE systems (WebChart, Enterprise Health) using the Clinical Encounter CSV API.
A case encompasses a variety of data that is ultimately meant to generate an OSHA 300 log for occupational injuries and illness. The Case Management CSV API includes encounter information, and is used when encounters are imported as a part of a case.
The abstract that follows should be presented to decision-makers or stakeholders interested in a general explanation of the Clinical Encounter CSV API. Technical details are provided in the remaining sections.
The Clinical Encounter CSV API is used to import information related to an employee/patient’s condition from an existing system.
It is valuable to recognize the following terminology as it pertains to MIE systems:
- An accommodation is modification that allows an employee to continue working, or lost time (worker’s comp plan) available for an employee who cannot work after an incident.
- A case is a full report of a workplace injury, or incident, for an employee (patient). The case is created in an initial visit (encounter), and is then linked to subsequent visits. A case links all follow up visits (encounters), restrictions, accommodations, conditions, and nature of injury information. All of the documents pertaining to the case are grouped together within the patient’s chart for reporting purposes. There are several case types, which designate different required fields as well as state specific incident questions and forms. The terms case and incident may be used interchangeably in an MIE system.
- A condition in an MIE system records a patient’s health/medical problem, recorded using the appropriate medical coding (ICD9/10, SNOMED, etc.).
- An encounter documents a visit with a employee, and is also known as a patient visit. All aspects of the visit are covered in the encounter, such as the history of present illness, case/incident information, past medical history, medications, allergies, review of systems, vitals, tests and procedures, physical exam, assessment, restrictions/accommodations, plan and follow up information.
- The term incident refers to the workplace injury that opens a case for an employee. The database table in an MIE system where information on the injury is recorded is the incidents table. When an incident date is entered in the incidents table, a case is created. The terms case and incident may be used interchangeably in an MIE system.
- Lost time is the period of time that an employee (patient) is away from work due to an injury.
- Nature of injury codes and body part codes are combined in a case to create the incident nature of injury body part ID (nibp_id) in an MIE system.
- In occupational health, a restriction (clinical restriction) refers to an activity that an employee (patient) is not permitted to do after an injury (incident).
CSV refers to the type of file and format of data needed to import information into the WC system. API refers to how the data interacts with the WC system. See the Import Overview page for a more detailed explanation of terminology.
The Clinical Encounter CSV API is useful for clients importing encounter-related data such as annual tests for clearance. Each encounter includes a chief complaint and documents separate visits with an employee/patient. Additional information is included in the encounter via documents. A document in WC is a way of storing information in patient charts. This includes patient photographs, insurance cards, physician or nurse notes, imaging studies, past medical histories, physician tasks for a patient, CCDs and CDAs, email correspondence about a patient, injections, and many other forms of data.
The related Case Management CSV API imports encounter, restriction, accommodation, condition, or nature of injury information for a patient, and is used to generate an OSHA 300 log. Clients who do not submit OSHA 300 logs may find the Clinical Encounter CSV API more appropriate for their needs.
The following sections provide insight for technical personnel working with the provided import specifications. Although the specifications provided include details on each field utilized in the import, the sections below include further discussion on best practices for imported data to provide the best functionality in WebChart .
The specification may be downloaded as Excel, CSV, or duplicated as an online spreadsheet under the File menu.
Additionally, user instructions are available for importing data in WC .
Column Definitions and Specific Coded Values
Definitions for the columns utilized in the specification, as well as commonly used specific coded values appear on the Data Import Standards page.
The following fields (indicated in the Data Name column) are noted as required (R) or are recommended as best practice (BP) in the Clinical Encounter CSV API specification. Additional details and considerations are provided here.
The following fields are required:
- Chart Identifier (encounters.pat_id): Links a chart to a patient.
- Chart ID Type (encounters.pat_id_type): Identifies the type of chart.
- Record External ID (encounters.ext_id): Number that identified the encounter in the previous system.
Performing User ID Type (encounters.performing_user_id_type): Is a conditionally required field if the field Performing User ID (encounters.performing_user_id) is used to identify the user that performed the encounter.
Observations can be added to the encounter by adding the observation columns to the import file.
The field obs_result is required to create an observation.
Chart Observations Import Options can be used to modify how observations are processed as the file is loaded.
Chart Observations Default Values can be used to simplify the import file.
Although this information is not required, it is considered a best practice to use at least some of these fields to populate information in the header of a document for identification and organizational purposes:
- Visit Type (encounters.visit_type): Identifies how the encounter was performed (phone, office, etc.).
- Date of Service (enounters.serv_date): It is best practice to record the date of service for record keeping purposes.
- Encounter Closed (encounters.closed): Encounters that are flagged as closed cannot be opened as an encounter once imported into in WC .
- Case Date Time (incidents.inc_datetime): It is best practice to utilize this field if cases are used in WC .
- Case Type (incidents.case_type): It is best practice to utilize this field if cases are used in WC .
- Location Description (incidents.loc_description): The location description is a text description of where an incident occurred, and should be utilized with incidents.
- Work Related (incidents.osha_work_related): It is best practice to utilize this field for OSHA reporting purposes.
- OSHA Reported Date (incidents.osha_completed_dt): It is best practice to utilize this field for OSHA reporting purposes.
- Injury/Illness Type (incidents.osha_itype): It is best practice to utilize this field for OSHA reporting purposes.
- Privacy Case (incidents.privacy_case): It is best practice to utilize this field for OSHA reporting purposes.
- Workers’ compensation related (incidents.workcomp_completed_dt): It is best practice to utilize this field for OSHA reporting purposes.
- Last date of work (incidents.date_last_worked): It is best practice to utilize this field if cases are used in WC .
- Time patient began work on day of injury/illness (incidents.employee_starttime): It is best practice to utilize this field if cases are used in WC .
- Date supervisor notified (incidents.reported_super_datetime): It is best practice to utilize this field if cases are used in WC .
- Action employee performing before incident (incidents.comment_activity): It is best practice to utilize this field if cases are used in WC .
- Incident Explanation (incidents.comment_explanation): It is best practice to utilize this field if cases are used in WC .
- Incident Cause (incidents.comment_cause): It is best practice to utilize this field if cases are used in WC .
- Incident Status (incidents.status): It is best practice to utilize this field if cases are used in WC .
Unless otherwise specified, validation between the previous system and the new WC system requires the client to provide a number of test patients. This data can be compared in the previous system using the validation test script.
The following examples are available: