Conditions CSV API

Share

Covered by this topic

The following page defines data and fields that may be imported into MIE systems (WebChart, Enterprise Health) for conditions using the Case Management CSV API .
The following CSV APIs import information used to build a case:

Audience

The abstract that follows should be presented to decision-makers or stakeholders interested in a general explanation of the Case Management CSV API. Technical details are provided in the remaining sections.

Abstract

The Case Management CSV API is used to import information related to an employee’s (patient’s) condition, accommodation, and lost time 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, because an incident creates a case.
  • 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 an 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 following subsections outline situations in which cases are useful, and when they are not.

Importing Condition Information Separately

Case management in EH was built to collect data for OSHA 300 logs. Clients that are not required to keep OSHA 300 logs may not need to use the Case Management CSV API. Depending on the way the client uses the MIE system, the imported information may be included in an encounter, restriction, accommodation, condition, or nature of injury information for a patient.
It is possible to import conditon data separately. See a developer for more details.

Importing Condition Information as Part of a Case

Not all encounters are part of a case, but a case is always created when an incident is created in the system. The Case Management CSV API requires an incident date (incidents.inc_datetime).
A major advantage of using the Case Management CSV API is that once data is imported, all information related to case is in the system, not just visits (encounters).

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.
Case Management CSV API specifications are available here .
Additionally, user instructions  are available for importing data in EH.

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 sections outline requirements for importing condition data related to case management. The Case Management CSV API utilizes data from multiple locations to track the progress of a workplace injury or illness by building a case for the patient.

Required

Since each page in the full Case Management CSV API spec also imports information separately, there is some overlap in what is required.
The following fields are required to import conditions data:

  • Case Number (External ID) (encounters.ext_id): Links a chart to a patient.
  • Condition External ID (patient_conditions.ext_id): Identifier from the legacy database or spreadsheet. This is typically the primary key of the legacy database’s conditions or problems table.
  • Chart ID (patient_conditions.pat_id): Identifier of the chart to which this condition pertains.
  • Chart ID Type (patient_conditions.pat_id_type): Type of identifier of the chart to which this condition pertains. Applies the condition to a specific patient.
  • Status (patient_conditions.status): Status of condition. Active conditions display on the encounter, while concluded conditions display elsewhere on a list of previous conditions.
  • Description of Condition (patient_conditions.description): A short description of the condition, this may be an ICD, Snomed, or free text. This description appears on the encounter.

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.
The fields that follow are used to populate the OSHA 300 log.

  • ICD-10 Code (patient_conditions.icd10): ICD10 code.
  • Onset Date (patient_conditions.onset_date): Date when the condition began.
  • Conclusion Date (patient_conditions.conclusion_date): Date when the condition was concluded.
  • Snomed Concept ID (patient_conditions.concept_id): SNOMED concept ID.

Examples

Troubleshooting

Validation

Resources

Did this doc help you?

Enterprise Health Documentation

Page Created:
Last Updated:
Last Build: Sun, 13 Nov 2022 01:02:21 UTC
WikiGDrive Version: 8799ccfd58b47ed721e42eeadb589071776ed64f