Clinical Encounter CSV API

Introduction

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.

Audience

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.

Abstract

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 EH system. API refers to how the data interacts with the EH system. See the Import Overview  page for a more detailed explanation of terminology.

Workflow Considerations

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 EH 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.

Specifications

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 Enterprise Health .
The Clinical Encounter CSV API specifications are available here .

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.

Field Requirements

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.

Required

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

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.

Best Practice

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 EH .
• Case Date Time (incidents.inc_datetime): It is best practice to utilize this field if cases are used in EH .
• Case Type (incidents.case_type): It is best practice to utilize this field if cases are used in EH .
• 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 EH .
• 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 EH .
• Date supervisor notified (incidents.reported_super_datetime): It is best practice to utilize this field if cases are used in EH .
• Action employee performing before incident (incidents.comment_activity): It is best practice to utilize this field if cases are used in  EH .
• Incident Explanation (incidents.comment_explanation): It is best practice to utilize this field if cases are used in EH .
• Incident Cause (incidents.comment_cause): It is best practice to utilize this field if cases are used in EH .
• Incident Status (incidents.status): It is best practice to utilize this field if cases are used in EH .

Validation

Unless otherwise specified, validation between the previous system and the new EH 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. Clinical Encounter CSV API Validation Test Script

Examples

The following examples are available:

• Google spreadsheet
• Downloadable CSV

Related Pages

• Case Management CSV API
• Restrictions CSV API
• Accommodations CSV API
• Conditions CSV API
• Nature of Injury CSV API
• Data Import Master List
• Import Overview
• Data Migration File Format Standard