Patent Application
20050131737
1. Field of the Invention
This invention relates generally to occupational health and safety, and more specifically to a method and system for automating occupational health and safety information management.
2. Background Art
The Occupational Health and Safety Administration (“OSHA” www.osha.gov) was established in 1971 to ensure safe and healthful workplaces in America. OSHA sets forth and maintains a comprehensive set of standards for assuring safe and healthful conditions for working men and women. Since the agency was created in 1971, workplace fatalities have been cut in half and occupational injury and illness rates have declined 40 percent. At the same time, U.S. employment has doubled from 56 million workers at 3.5 million worksites to 111 million workers at 7 million sites today.
Maintaining compliance with OSHA standards and managing health and safety-related information is an important and challenging task—especially for larger organizations employing hundreds or thousands of employees nationally. First, there is a tremendous amount of information to gather, process, analyze and report to establish compliance (e.g. patient medical visits, organizational injury/illness statistics, OSHA-required reports, etc.). Second, information originates from many different sources throughout an organization. This fact challenges centralized management of occupational health and safety-related information.
The following table compares disadvantages of the conventional methodology for managing occupational health and safety-related information against certain advantageous aspects of the present invention.
What is needed is a comprehensive system and methodology for the efficient administration of occupational health and safety information and OSHA compliance. Embodiments of the present invention provide such a solution—leading to a reduction in injury, illness and loss through prevention.
One embodiment of the present invention is a computer-implemented occupational health and safety information management (“OHSIM”) system.
Embodiments of the present invention enable users to manage occupational health and safety information. Users can input medical data, incident investigation data, perform data analysis, and generally administer the management of occupational health and safety information in an automated fashion. Functionality associated with the present invention may be divided into three general modules: an Electronic Medical Record (“EMR”) module, an Incident Investigation module (“IIM”), and a Data Analysis module (“DAM”).
Within a corporate environment, several different users will find aspects of the present invention beneficial. For example, plant operations staff, safety engineers and union representatives may use aspects of the present invention to access statistical information and to analyze/control risk situations promoting safety in the workplace. A company's clinical healthcare providers may use aspects of the present invention to easily open/edit occupational and personal medical visits, update medical history information, open/edit medical leaves, and trigger investigations of work related injury/illness events. Supervisors, team leaders and safety engineers may use aspects of the present invention to enter, maintain and process/query incident investigation data, including information on property damage and near miss events. Plant level application administrators may use aspects of the present invention to adjust security access levels, as well as administer data reporting tools. Worker's compensation representatives may use aspects of the present invention to access occupational visit data and personal visit information. Human resources representatives may use aspects of the present invention to open/edit or create medical leaves and administer job placement/no work available (NWA) leaves. Corporate and plant operations staff, superintendents, area managers, plant level reporting personnel, and medical staff may use aspects of the present invention to query statistical information about a particular plant or multiple plants.
Benefits of the present invention include data-driven company processes which reduce workplace hazards, standardized processes, efficient in-plant medical data management, a standardized single point of entry for data collection, and electronic reports that are available to plant managers, safety engineers, supervisors, union representatives, and many others.
Embodiments of the present invention include methodologies, computer systems and computer software for automated health and safety information management. Depending upon the particular embodiment, aspects of the present invention may include an electronic medical record module configured to receive a plurality of data concerning patient medical visits resulting from occupational health or safety incidents (e.g. injuries, illnesses, etc.), process the data based on pre-defined OSHA logic to automatically identify one or more patient medical visits that are OSHA-recordable, and output one or more reports including a summary of the data characterizing one or more patient medical visits that are OSHA-recordable.
Another aspect of the present invention includes an incident investigation module configured to electronically dispatch an investigator to investigate one or more of the occupational health or safety incidents, and receive a plurality of data concerning an investigation of one or more of the occupational health or safety incidents including one or more corrective actions to avoid reoccurrence of the one or more of occupational health or safety incidents.
Another aspect of the present invention includes a data analysis module configured to filter received data at one or more filter levels (e.g. worker characteristics, injury/illness codes, work assignment, time period, etc.) based on one or more user-defined criteria, and generate a plurality of reports based on the filtered data.
Data characterizing the patient medical visit may include data representing the date of the incident, whether the patient died or lost consciousness, diagnosis, treatment, medications, test orders, referrals, medical leaves, medical restrictions, an indication as to whether the patient is fit for work, etc.
According to another aspect of the present invention, an indication may be automatically displayed as to whether enough data characterizing the patient medical visits has been provided to determine whether the visit is OSHA-recordable.
According to another aspect of the present invention, functionality is provided enabling users to query collected data in a variety of different manners to produce or otherwise output a plurality of different report types. For example, a report summarizing the occupational health or safety incidents for a particular organizational location or patient, a report summarizing patient medical leaves of absence for a particular organizational location or patient, a report summarizing patient medical restrictions for a particular organizational location or patient, a report summarizing patient medical visits for a particular organizational location or patient, a report summarizing one or more incident investigations, a report summarizing corrective actions to avoid reoccurrence of the one or more of occupational health or safety incidents, etc.
One embodiment of the present invention is a computer-implemented occupational health and safety information management system (“OHSIM”). Aspects of the present invention may be divided into three general modules: the Electronic Medical Record (“EMR”) module, the Incident Investigation module (“IIM”), and the Data Analysis module (“DAM”). As will be discussed in greater detail below, each of the modules may be implemented in computer software and hardware and may be configured to share information in an electronic fashion with one another.
Roles and tasks of system users can vary widely depending on the particular implementation of the present invention. In accordance with a preferred embodiment of the present invention, however, Table 1 below illustrates a preferred matrix of user roles and responsibilities.
Those of ordinary skill in the art of computer programming will recognize that OHSIM functionality including functionality supported by the EMR, IIM and DAM modules may be implemented in a wide variety of different graphical user interface (GUI) configurations across a plurality of different computing platforms in a variety of different programming languages. As such, the present disclosure will describe user interfaces in terms of example functionality that those aspects of the present invention may be configured to support. Of course, the scope of the present invention is not limited to the particular examples or embodiments provided herein.
Preferably, functional aspects of the present invention are implemented in a Web-based fashion such that user interfaces are viewable and operational via Web browser (e.g. Internet Explorer, Netscape Navigator, etc.) in operable communication with one or more servers and associated databases.
Table 2 correlates several categories of OHSIM users with the OHSIM module these users may utilize. Notably Table 2 is an example—an unlimited number of different users may use any and all OHSIM modules in connection with occupational health and safety activities.
Electronic Medical Record Module (200)
The EMR module 200 provides users access to online medical record functionality with which personal and occupational medical visits can be documented, viewed and updated on a personal or corporate plant/facility level. This aspect of the present invention enables a user to view and update a person's medical history, document medical visits, open and update medical leaves of absence, generate reports for a person as well as a corporate plant/facility reports, update a person's demographic information, view a person's history of restrictions, and update medical user information. These and other features of the EMR module are described in greater detail below.
One aspect of the EMR module supports or otherwise enables the creation of an OSHA report having a log of OSHA-recordable events that are designated as such automatically based on the application of OSHA logic to data associated with or otherwise characterizing the events. These features of the present invention are described in greater detail below.
A computer-implemented embodiment of the present invention receives user-specified data characterizing an occupational medical visit. First, a user may select or otherwise specify an occupational treatment facility as represented in block 10. Next, the user may query a database of employees for the particular injured or ill patient, as represented in block 12. If no such patient is located, the application provides a new patient registration form.
Next, a check-in form may be completed for the injured/ill person, as presented in block 14. Check-in information submitted to the form may include the name of the injured/ill person, the person's date of birth, the treatment facility, the visit date and time, the visit type (e.g. short, personal, occupational, etc.), and a visit association (e.g. whether the visit is a follow-up to an existing condition or an initial visit).
As represented in block 16, an occupational detail form is provided for receiving a plurality of information relating to the incident. Information may include, but is not limited to the location of the incident (e.g. on/off premise, plant/building, department, work location, day, etc.), a date for the incident or onset of illness, a description of what the injured/ill person was doing before the incident/illness occurred, the injured/ill person's personal statement of the incident, a health care representative's interpretation of the statement or injury/illness, the object or substance that directly harmed the person, the tool/equipment used during the incident, the type of the injury/illness, and treatment facility information (e.g. physician name, emergency room, overnight, out-patient, etc.), an indication as to whether recessitation was required, an indication as to whether the person lost consciousness, and an indication as to whether the person died. Notably, certain fields within the occupational detail form are utilized by OSHA logic (discussed in greater detail below) to determine certain items for OSHA-recordable visits (e.g. OSHA log ID, which OSHA rules to follow, the creation of an OSHA case, etc.).
As represented in block 18, one or more interfaces may be provided for receiving a subjective and objective description of the injury/illness as well as an indication as to the patient's current medication and any objective measurements. According to one embodiment of the present invention, the subjective/objective statements do not affect OSHA recordability.
As represented in block 20, a variety of forms may be provided for receiving input assessing the person's injury/illness and adding a diagnosis for same. According to one embodiment, the assessment if via free text data entry. A form for adding a diagnosis may be provided including items including, but not limited to, an indication as to whether the diagnosis is a primary diagnosis or not, an indication of the body part affected, an indication as to the laterality of the body part, an indication as to whether the diagnosis is a simplified diagnosis (e.g. diagnosis selected from a drop-down menu), a flag for whether an illness is involved, an ICD-10 diagnosis parameters (e.g. chapter, main, subcategory 1, subcategory 2, clarification, etc.).
As represented in block 22, one or more user interfaces may be provided enabling users to define a plan or treatment for the injured/ill person. The treatment/plan may include a free-text description of the plan or procedure, treatment orders, medications, referrals, restrictions, medical leave, response to treatment, test orders, etc. Adding a medication to the plan/treatment may include specifying the name of the medication, the dosage, the number to dispense, special instructions (e.g. DAW, with food, drowsiness (precautions), etc.), an indication as to whether the medication was dispensed in medical, an indication as to whether a refill for the medication is available, and if so, refill limits, and a medication alert.
Adding restrictions to the plan/treatment may include the type of restriction (e.g. permanent, temporary, etc.), a main category for the restriction, a begin date, a through date, and a revisit date. Adding a medical leave to the plan/treatment may include specifying the type of leave (e.g. personal, occupational, etc.), the reason for the leave, the leave status, the begin date, the updated date, an indication as to who requested the leave, an indication as to how the leave was requested, a description of the reason or comments regarding the leave, DROP, the last day worked, contact information for the medical leave, and a description of the diagnosis.
Adding test orders to the plan/treatment may include specifying the type of test, the laterality, the order date, the order time, an indication as to whether the test was performed in-house or external, an indication as to whether a fracture occurred, and a description of the results or interpretation of the test orders.
As represented in block 24, a visit outcome form may be provided in which a user specifies whether or not the injured/ill person is fit for work. This aspect of the present invention may affect the OSHA-recordability of the visit. Visit outcome information may include an indication as to whether the injured/ill person is fit for work, an indication as to whether a revisit is required, an indication as to the date and time out, an indication as to whether a worker's compensation department should review the event, a worker's compensation code (if applicable), and an indication as to whether this event raises a privacy concern for the injured/ill person.
As represented in block 26, a complete verification form may be provided as feedback to the user indicating whether or not certain required data input fields had been properly completed.
As represented in block 28, an OSHA case adjustment form may be provided enabling a user to increase or decrease days away or restricted days for an OSHA case. This screen may also display medical leaves and/or medical restrictions associated with the visit(s).
As represented in block 30, a plurality of reports (e.g. regulatory reports, U.S. OSHA, etc.) may be generated. Reports may include an OSHA log of OSHA-recordable events, an OSHA injury/illness incident report, an OSHA summary report, and an OSHA execution and privacy concern summary. Preferably, a plurality of user-definable or user-selectable criteria are provided for querying a database of received data associated with OSHA visits for populating reports generated by the present invention. For example, an OSHA log analysis report may include query parameters such as plant/building, calendar year, incident date, incident date range, case number, case number range, incident department, incident work location, case type (e.g. illnesses only, injuries only, etc.), person name, person ID number, and OSHA cases (e.g. active, closed, etc.). Additionally, reports by facility or individual with regards to visits, medical leaves and/or medical restrictions may be provided. As discussed in greater detail below, a work queue may also be provided to assist medical workers with completing patient visits.
A “Create Visit” GUI (not shown) enables a user to create a new or “original” patient visit, or to open a “revisit” (e.g., to open an existing visit for editing or entering additional information such as test results). Preferably, a search feature is provided enabling a user to search among patients (e.g., employees at a particular plant/facility, by treatment facility or corporate-wide including by country). Patients may be searched according to demographic information including name, ID no., treatment facility, plant, etc.).
If a patient is not found during a search, a registration screen is preferably provided enabling the user to register the patient within the system. Patient registration may include defining conventional demographic information as well as the patient's plant/facility, medical treatment facility, and employer (e.g., in the event that the patient/employee is a contract employee).
A “Check-In” GUI (not shown) enables a user to define a medical visit. Visit types may be defined by selecting from a “short”, “personal” or “occupational” visit identifier. Next, the user defines visit data and time-in. In accordance with a preferred embodiment, once the check-in date and time have been saved by the user, they cannot be changed. According to one embodiment, if the user selected a “personal” or “occupational” visit, the user next selects a “visit association”, if applicable. If the current visit is a new or “original” visit, then there is no association. However, if the current visit is a follow-up, then the user associates the current visit with the original visit that it derives from. Preferably, the user is provided with a GUI to view information regarding any other visits that have been associated with an original visit.
A “Short Visit” GUI (not shown) enables a user to quickly define an office visit. Short visits are typically used for minor problems that do not require extensive treatment or testing. Once the short visit option has been selected additional fields appear on the screen. The visit may be changed to personal or occupational at any time before the record is saved.
Information collected during a short visit may include a primary/secondary diagnosis, a primary/secondary treatment/order, a data/time out, and additional comments, if necessary. Preferably, a primary diagnosis is selected from a diagnosis list available for short visits. A patient's vital signs may also be input during a short visit.
Preferably, a user is provided with links to view various categories of information associated with the current patient. For example, links may be provided for a patient's complete visit history, or only visits deriving from the current original visit. Additional links may provide a user with a person's medical, medication and allergy history, current and historical patient restrictions, and staff notifications/messages, etc.
For First Time Occupational Visits (FTOVs), a GUI may be provided (not shown) in which the user inputs the details of an occupational incident. FTOV information to be input may include the location of the incident (plant, building, department, bay, etc.), the date/time of the incident, a description of what the patient was doing just prior to the incident, the patient's account of the incident, a user's (e.g., health care representative's) interpretation of the patient's account, the objects/substances that caused the incident, the tool/equipment being used at the time, the injury/illness type, indications as the whether resuscitation was required, whether the patient lost consciousness, and whether the patient died. Preferably, treatment facility information includes the name of the associated physician or health care professional, the location where the person was treated, etc.
For personal and occupational visits, the user may also input subjective statements, such as a person's description of the reason for a visit, information on history or healthcare problems into a “Subjective” EMR GUI. Preferably, data entered in the person's personal account (described above) is automatically copies to the Subjective GUI in a first time occupational visit. It is additionally preferred that once this data is saved, it cannot be edited. Current medications documented in the person's record may also be displayed.
An “Objective” GUI (not shown) may be provided for recording clinical observation information (i.e., factual and measurable data—vital signs, body mass index, physical condition, etc.) regarding the person's medical condition at the time of the visit.
A user may specify a “Simplified Diagnosis” from drop-down menu 22, or define a diagnosis from among the International Statistical Classification of Diseases and Related Health Problems (ICD) from among drop down menus 24. ICD classifications can be obtained from the Center for Disease Control and Prevention, 1600 Clifton Rd., Atlanta, Ga. 30333.
Preferably, the selection 24 made at each level determines selections that are available in the next level of the hierarchy. The preferred pathway is: Chapter, Main, Sub-Category 1, Sub-Category 2 (if applicable) and Clarification (if applicable). While laterality and body part are not applicable for every diagnosis, documentation when appropriate is important in maintaining an accurate medical record.
Occupational diagnoses may be documented using the “ICD” or “Simplified Diagnosis pathways.” When using the Simplified Diagnosis pathway, the corresponding ICD automatically displays based on a combination of body part, laterality, and Simplified Diagnosis selections.
Preferably, a “Plan” GUI is provided enabling a user to input interventions for resolving the patient's problem or injury. A “medication” form allows a user to delete or view prescription/non-prescription medications already ordered for a patient during the current visit, order new medications, and complete medication order forms for medications to be given outside of the medical department. Ordering new medications preferably includes defining the name of the medication, the dosage, specific dosage instructions, the number to dispense, the number of refills, and any alerts (e.g., allergy alerts). Preferably, medications and immunizations that are ordered during a patient visit are automatically entered into the person's medical history.
Functionality for printing prescriptions may also be provided. Preferably, user-access to the prescription printing functionality is restricted based on user ID or role. A “Dispense Medication/Immunization” GUI (not shown) enables authorized users to document details regarding dispensed medications/immunizations. Information to be submitted may include a “Route” if the medication is given intramuscular, subcutaneous or intradermal. Additional information for immunizations may include Series, Booster, Brand, Manufacturer, Lot Number, Expiration Date, Amount, Route, Site, Date and Time of Immunization, Next Due Date, etc.
A “Test Orders” GUI (not shown) enables a user to view, delete or add orders for patient tests. Test orders may include an audiogram, a breathalyser, an electrocardiogram, an electroencephalogram, electromyogram, blood work, urine test, pulmonary function tests, a radiology exam, a scan, a sleep apnea examination, a treadmill test, an ultrasound, a vision test, and user-defined tests (i.e., free-text description). The GUI may provide the user with data entry/selection fields for defining the date of the order, the date of the test, the test results, the entity to perform the test, and/or test conclusions.
A “Treatment Orders” GUI (not shown) enables a user to view, delete or add orders for patient treatment. Treatment orders may include medical goods such as an ace wrap, arm sling, band aid, brace, cane, clavicle strap, crutches, etc., or wound care such as antibiotic ointment, butterflies, dry and wet dressing, dressing pressure, drainage, etc.
A “Response to Treatment/Observation” GUI (not shown) enables a user to input a patient's response to treatments and any significant clinical observations. Preferably, this is performed in a free-text fashion.
A “Referral” GUI (not shown) enables a user to add, view or delete current referral orders. Defining a referral includes specifying the referral type (e.g., specialist, etc.), the scope of the requested referral (e.g., evaluation, treatment, both), a referral name, address, telephone number, etc., an appointment date and time, and special instructions or comments.
A “Medical Restrictions” GUI (not shown) enables a user to view all open restrictions or expired restrictions with a revisit date (even if the restrictions is not within the current visit series), print a report listing all open restrictions, add a new restriction for the current visit, attach a restriction if this is a revisit in the same series of visits, unattach a restriction from the current visit if attached in error, edit a restriction from a “Restrictions for Current Visit” table, and delete a restriction from the “Restrictions for Current Visit” table. Adding a new restriction may involve defining the type of the restriction (e.g., temporary, permanent, etc.), a category for the restriction, a begin date, an end or thru date, and a revisit date.
A “Medical Leave” GUI (not shown) enables a user to view open and pre-scheduled medical leaves, view and edit closed and deleted medical leaves, attach an existing leave not previously attached to a visit, attach an open leave to a revisit in a series of visits, and begin a new “Unfit for Work” leave. In accordance with a preferred embodiment of the present invention, medical leaves are divided into four main categories: open, pre-scheduled, closed, and open/closed. Open medical leaves a reoccurring open medical leaves. Pre-scheduled leaves are used when a person knows in advance that they will be going on leave (e.g., for a scheduled surgery). Preferably, leaves can only be closed by an authorized health care representative. “Open/closed” leaves are for “Unfit for Work” medical leaves—when a person goes out on a medical leave but the leave is not entered into the OHSIM system.
Opening a new medical leave may include defining the type of leave (e.g., personal, occupational), the reason for the leave (e.g., unfit to work, etc.), the begin date, the end date, the update date, the requester, the manner requested, comments, the last day worked, contact information for the patient during the leave, and a diagnosis.
A “Visit Outcome” GUI (not shown) enables a user to summarize the medical visit, including whether the person is fit to work, needs medical restrictions, etc. This interface allows a user to record a disposition for the visit. To do so, the user may select or otherwise define an overall disposition, an indication as to whether a revisit is necessary, and if so, when. Additional user-definable/selectable information may include an indication as to whether the worker's compensation department should review the visit, a worker's compensation code, or an indication as to whether the visit poses a privacy concern for the patient.
Preferably, a “Complete Verification” screen is provided to the user indicating whether the extent to which any required fields in the GUIs (described above) have been completed.
In accordance with a preferred embodiment of the present invention, OSHA logic is applied to the visit information upon a successful verification that all required data has been entered. This feature of the present invention will be discussed in greater detail below.
OSHA Logic
Tables 3 through 9 contain example business rules and processing logic for processing visit data and generating reports, including formal OSHA log reports. For example, business rules and logic such as that exhibited in Tables 3 through 9 may be executed by the OHSIM application to process and automatically identify visits that are OSHA-recordable (e.g., visits to be included in an official OSHA log). This automated aspect of the present invention reduces or eliminates error and inconsistency typically associated with the conventional “human-implemented” decision making process to determine which visits are OSHA-recordable.
Notably, the business rules and processing logic contained in Tables 3 through 9 are only examples to assist in the understanding and implementations of the present invention. Tables 3 through 9 are not intended to limit the scope or application of the present invention.
OHSIM Reports
The OHSIM system is configured to present processed health and safety data in a plurality of different reports and report formats.
“Incident Reports” compile and display information collected during a patient visit or re-visit. A user is provided with selectable criteria to customize a report (e.g., for incidents at a plant, for a particular individual, etc.). As discussed in greater detail with regard to the IIM, plant level clinicians and others may view incident investigations reports resulting from a reported incident.
An OSHA Log may be the official Occupational Safety and Health Administration (OSHA) Log. An OSHA Log Analysis provides selection criteria to customize what is displayed on the Log. An OSHA Injury/Illness Incident report provides information from a medical visit (in particular occupational detail information) for particular OSHA Case(s). The report provides supplementary information regarding Case(s) on the log. An OSHA Summary may be used to meet employee-posting requirements in accordance with OSHA requirements. An OSHA Execution report provides information regarding Occupational Medical Visit activity. An OSHA Inj/Ill Incident for Authorized Employee Representatives provides information from a medical visit (in particular, occupational detail information) for particular OSHA Case(s). This report provides Case supplementary information regarding a Case(s) on the OSHA Log and is available to Authorized Employee Representatives as defined by OSHA. A Privacy Concern Case report provides confidential information related to privacy concern cases as defined by OSHA.
A “Medical Leaves by Facility” report displays leaves in selected statuses for selected or user role-defined plant/building(s). Selection criteria allows a user to customize the data display by a particular department or work location as well as by leave type (personal or occupational) and active, unattached, NWA, and deleted. A user can also search by leave status (closed, open, open-closed and pre-scheduled). In addition, the report can be sorted by leave end date, employee name, work location, etc.
A “Medical Restrictions by Facility” report enables a user to view all individuals with restrictions in selected statuses for selected plant/building(s). Selection criteria allow a user to customize data display by selecting a visit type (personal or occupational) and status (active, deleted, expired, and expired with a revisit date). In addition, the report can be sorted by restriction end date, employee name, or work location.
A “Medical Visits by Facility” report is a visit log for a particular treatment facility. Selection criteria allows a user to customize the report by selecting a visit type (FTOV, Occupational, Personal, or Short) as well as a date range. In addition, a user can customize the data display by selecting a Sort By option (Person Name, Visit Type, Visit Outcome, Last Updated By, or Work Location). A user can search within any date range. Preferably, if the date range is thirty-one days or less, the report is available online. If the date range is greater than thirty-one days, the report is a batch report and will not be available for immediate viewing.
A “Medical Revisit” report allows a user to print a report of all scheduled medical revisits. A user can search by date multi-day increments (e.g., up to 31-day increments). Preferably, the printed report separates required revisits, restriction revisits, medical leave revisits, and immunization revisits onto separate sheets.
A “Medical Restrictions by Individual” report allows a user to view the medical restriction history for a person. Selection criteria allows a user to customize the data display by selecting a visit type (personal or occupational) and status (active, deleted, expired, and expired with a revisit date). In addition, the report can be sorted by restriction end date, employee name, or work location.
A “Medical Leave by Individual” report allows a user to view the medical leave history for an individual. the data display by selecting a leave type (personal or occupational) and active, unattached, NWA, and deleted. A user can also search by leave status (closed, open, open-closed and Pres-scheduled). In addition, the report can be sorted by leave type, leave begin date, and OSHA case number.
A “Visit Summary by Individual” report allows a user to print a report of all visits to the Medical Department for a particular person. A user can elect to print only OSHA, occupational or personal visits with associated revisits or visits for a date range. An original or OSHA visit with associated revisits selection typically result in an immediate online report. A Multiple Visits by Date Range selection is preferably implemented in a batch report.
In addition to the “standard” reports described above, the OHSIM system is capable of and configured to implement custom analytical reporting. This aspect of the present invention is described in greater detail in accordance with the detailed description of the DAM module.
Table 10 contains a descriptive summary of task menu links that may be implemented in accordance with the EMR module GUIs and reports described in greater detail above. Notably, this descriptive summary depicts a preferred implementation of the EMR module, and is not intended to limit the scope of the present invention. An unlimited number of related tasks and corresponding role combinations may be implemented within the scope of the present invention.
Incident Investigation Module (202)
The Incident Investigation Module (IIM) is an online tool that enables users to capture information from the investigation of a work-related injury/illness incident, a property damage incident, or a near miss. It enables users to generate detailed reports of specific incidents, specific corrective actions, and provides users with the capability to generate a summary report for all incidents occurring within a specific time frame. The information stored within IIM can be used for risk analysis and loss control.
Following are some examples of how different user roles might use the Work Queue:
Table 11 contains example task descriptions and roles corresponding to various “Actions” within selection criteria 46.
As mentioned above, the EMR and IIM modules are configured to generate a variety of automatic or semi-automatic e-mail notifications to assist in the effective reporting, investigation and resolution of injury/illness incidents within the workplace. Within the EMR module, health care representatives are able to identify the incident supervisor of an injured or ill employee while reporting a medical visit. The OHSIM system may be configured to automatically send an e-mail notification of the visit to the specified incident supervisor that includes a link to the incident pending investigation.
Similarly, e-mail notifications may be initiated within the IIM module via the work queue as well. For example, if another user finds an incident in the Work Queue that should be investigated by someone else, that user can send e-mail directly to the supervisor, reassigning responsibility for the investigation. Superintendents and area managers can send e-mail to the designated supervisor, while viewing the medical incident in the Work Queue. In each instance, the OHSIM system generates an e-mail notifications that include a link to the incident report.
In one implementation of the present invention, there are four types of investigations:
Notably, a wide-variety of different investigation types may be supported by the OHSIM system depending upon the particular implementation of the present invention.
The investigator information screen illustrated in
Notably, the features shown and described with respect to
Preferably, if medical personnel have already processed an injured or ill person, the human injury/illness investigation type is automatically selected. Some indicant details may be pre-populated with information entered by medical personnel. According to one embodiment, the investigator must initiate injury/illness investigations from the Work Queue.
The location/job information screen (not shown) is used to capture data related to where the incident occurred and specific data related to the incident. In one embodiment, this screen is divided into two sections, a location information section, and a job information section. If the incident happened in an off-facility location, a checkbox may be selected and specific location information may be entered. If an injury/illness incident did not happen at a person's normal work location, the displayed fields may change accordingly. The job information portion of the screen captures specific data related to the job of a person involved in an injury/illness incident.
Information collected at the location/job information screen may include an indication as to whether the incident occurred on or off facility premises, an indication as to whether the incident occurred at the person's normal place of work, information describing the location of the incident (e.g. plant/building, department, work location, incident location/bay, station number, etc.), and employee job information (e.g. job code, job description, job experience, shift, etc.).
The incidence analysis screen (not shown) may be implemented to document the incident in greater detail. In one embodiment, the incident analysis screen is divided into three sections. The first section defines the general source of injury. The second section assesses the actual and potential risk, using a risk factor matrix calculation. The third section defines the contributing factors to the incident, such as substandard acts and conditions.
The incident analysis screen may receive general incident analysis information including the type of contact or the manner in which the employee was exposed to the incident or injury, the source of the injury, and the task/activity the employee was performing when the incident/injury occurred.
A loss severity/probability of reoccurrence portion of the incident analysis screen may include selection of an actual loss severity/probability of reoccurrence value as well as a potential loss severity/probability of reoccurrence value. A contributing factors portion of the incident analysis screen may enable a user to define a substandard act, a substandard condition, a personal factor, a job factor, and/or controlling program element that led to or otherwise contributed to the incident under investigation.
Table 12 sets forth example loss severity/probability of reoccurrence values in accordance with one implementation of the present invention.
A corrective action screen (not shown) may be utilized to capture recommended corrective actions to prevent reoccurrence of an incident. Notably, multiple corrective actions may be added for a single incident. In addition, a corrective action may be deleted if it no longer applies.
In one implementation, the corrective action screen receives user input defining, for a new corrective action, the type of correction action (e.g. interim, permanent), a description of the recommended corrective action, a target completion date for the recommended corrective action, and an actual completion date. In addition, a person responsible for implementing or otherwise overseeing the corrective action may be identified.
The witnesses screen (not shown) may be utilized to capture information from and about any witness to the incident. Witness information includes the witness's name, identification, contact information, and comment. Witness records may be removed from the incident investigation, but preferably the witness record is retained.
A cost screen (not shown) may be used to capture known actual and potential costs of the damages to people, equipment, environment and material, etc. Current plant policies and procedures for costing may be utilized as guidelines to complete this screen. According to one embodiment, an actual and potential cost value is input for each cost category (i.e. people, equipment, environment, material, etc.). People cost represents the cost of people involved in the incident (i.e. the cost of replacing an injured person with someone else, etc.). Equipment cost represents the cost of the equipment involved in the incident (i.e. the cost of repairing or replacing equipment as a result of an incident occurring). Environment cost is the environmental cost associated with the incident (i.e. the cost to clean up a chemical spill).
An injury/illness information screen (not shown) may be utilized to capture information entered by medical personnel for an injured/ill person. Preferably, this screen is implemented as a read-only screen and cannot be changed by investigators. It is additionally preferred that any diagnosis information within a person's medical record is maintained as confidential and does not display on the screen. Preferably, any other appropriate information is automatically transferred or otherwise transmitted to the incidence investigation record from the person's medical record. In one embodiment, a button is provided allowing an investigator to view diagnosis information. Only OSHA-recordable events will be displayed. Information displayed may include the body part or area affected by the person's injury or illness, the side of the body or region where the injury/illness is located, and an injury/illness type (e.g. injury, illness, repetitive motion, etc.). Days away from work due to this incident may be identified as the number of full days unavailable for work due to an injury or illness. This field may be blank if the information has not already been entered into the EMR. Preferably, a first time occupational visit number is provided as a unique number assigned to new occupational visits and may also be blank if the information has not previously been entered into the EMR (discussed above).
A complete/verification screen may be provided that is similar to the EMR verification screen shown in
An attachment screen (not shown) may be utilized to attach pertinent information to an investigation. The attachment can be any type of file such as a photograph, spreadsheet, graphic or document.
Preferably, a restriction information screen (not shown) is provided as an aspect of the present invention to input selection criteria and view persons with active medical restrictions. This information assists supervisors in assigning employees to jobs that accommodate their restrictions. Preferably, the restriction information screen is also accessible from the work queue (discussed above). Search criteria may include plant/building, department, work location, person name, and person identification number. By selecting one of the search results, a user may be presented with a description of that user's restriction(s), in the corresponding begin date, through date, and revisit date.
Additional search functionality may be provided enabling users to search investigation records. Search criteria may include investigation identification number, an investigator's identification number, person name, investigation type, incident plant/building, incident department, incident work location, and incidents that occurred within a user-specified date range.
An additional search screen enables users to search for people involved in or otherwise associated with incident records. Search criteria for the people search may include first name, last name, identification number, date of birth, country, plant/building, etc.
The incident investigation module may be programmed and configured to generate a plurality of reports based on information collected in connection with incident investigations.
Table 13 associates a plurality of IIM-related reports with likely users of those reports. Some reports are described in greater detail below.
A corrective action report may be utilized to generate a report for information regarding a corrective action, particularly an outstanding corrective action. Primary safety engineers, superintendents, and area managers may use such a corrective action report. Preferably, a corrective action report search screen is provided (not shown) for searching corrective actions by a variety of criteria including incident plant/building, investigation I.D. number, incident department, incident work location, corrective action type, and target date range. Search results include a listing of corrective actions by investigation I.D. number and include a description of the corrective action. Preferably, a hyperlink is provided enabling the user to view each investigation record.
An incident investigation report (not shown) may be utilized to view and print reports after an incident investigation has been entered into the system. Preferably, a search screen is provided enabling the user to search among all incidents according to a plurality of search criteria. Search criteria may include incident plant/building, investigator identification number, investigation type, incident department, incident work location, person or witness name, incident date range, incident job code/description, diagnosis/observation, type of contact, source of the injury, and task/activity. Additionally, incident reports may be searched according to loss severity/probability of reoccurrence including an actual value, potential value, a substandard act, a substandard condition, and a controlling program element or detail. Similar to the corrective action report, search results for the incident reports are preferably provided with a corresponding hyperlink enabling a user to view the relevant investigation record.
A management summary report screen (not shown) may be utilized to generate a report for occupational incident activity reported to a medical facility for treatment that occurred at a user's assigned plant/building. Preferably, an investigation link will appear for any investigation that has been initiated for an incident. If an investigation has not been initiated, only the injury/illness incident will display on the report but without corresponding investigation information. Near miss, property damage and risk assessment incidents may also be associated to an investigation and may be viewed through this report.
According to another aspect of the present invention, a plurality of regulatory reports may be automatically generated, including an OSHA log report, an OSHA log analysis report, an OSHA summary, and an OSHA injury/illness incident report for an authorized employee representative report. The OSHA log report is the official year-to-date occupational safety and health administration log. This report may not include deleted cases. Preferably, two different layouts are provided: Form 200 for years 2001 and prior; Form 300 for years 2002 and beyond.
The OSHA log analysis report provides selection criteria to customized what is displayed on the OSHA log report, including deleted cases. Preferably, two different layouts are provided: Form 200 for years 2001 and prior; Form 300 for years 2002 and beyond.
The OSHA summary report is used to meet employee posting requirements in accordance with OSHA requirements for the year 2002 and beyond. Preferably, summary counts for years 2001 and earlier appear on the last page of the OSHA log report.
The OSHA injury/illness incident report for an authorized employee representative is available to authorized employee representatives, as defined by OSHA, for the year 2002 and beyond. This report provides information from a medical visit (in particular, occupational detail information) for a particular OSHA case. Preferably, this report provides only case supplementary information regarding a case on the OSHA log, and does not show any information regarding the employee and the physician/health care professional. The layout for this report may be defined by OSHA Form 301.
A work queue management report (not shown) provides a tool for viewing incident work queue related counts at various stages. Preferably, statuses are displayed according to a green yellow and red status format for selected incident plants/buildings for incidents involving restrictions, incidents not initiated, incidents not complete, incidents awaiting review, incidents awaiting sign-off, and incidents awaiting update. The work queue management report is a real-time report, displaying information accurate to the date and time the report is generated. Totals for the green, yellow, and red statuses may be displayed by plant/building.
Data Analysis Module (204)
The data analysis module (DAM) is a custom analytical reporting aspect of the present invention. This aspect of the present invention provides users with an ability to compile and process organizational information relating to occupational health and safety. Basic and detailed reports for incident investigations, property damage, and near-miss incidents can be generated based on user selected criteria and include single plant or multi-plant reporting. This aspect of the present invention may be implemented in a web-based environment and may improve efficiency, standardize health and safety functions, and report/track trends for injury/illness, property damage, and near-miss incident types.
Table 14 illustrates a comparison of some high-level functionality and distinguishing characteristics between the DAM module and the IIM/EMR modules.
The format output form allows a user to modify the format of the chart/table or specified listing report. Notably, the information displayed on this screen may differ depending on the report type selected. The count values include the number of a specific item, such as incidence, days, persons, etc. The rate values include the rate at which an action occurred. The chart type selection 92 specifies the type of chart to be generated. Depending on the selection, different fields may be displayed or become unavailable. Table 15 contains example chart types corresponding to the type of data those charts might be utilized to display.
A review selection tab (not shown) illustrates a summary of user-defined selections (e.g. basic selections, detailed selections, output format, etc.). Selections presented include the current status of organizational variables, personal variables, visit type, injury/illness variables, body parts, incident investigation codes, cost, output format, etc.
The personal variables GUI (not shown) enables a user to select information about the type of people to be reported on. The user can select to report on all or a specified selection of variables. Variable selections may include pay status (e.g. hourly, salary, etc.), employee types (e.g. regular, apprentice, agency, temporary, etc.), gender, seniority, time on job, age group, ethnic group, etc.
A detailed selection form for visit type (not shown) enables a user to select the medical case types to be reported on. The reports can be based on first time occupational visits, first time personal visits, or both. Selection fields include a first time occupational visit selection, a selection of government reportable cases (if FTOV is selected, a user can report on all FTOVs with one or more days away from work, and/or one or more restricted days at work, due to an occupational injury or an illness), cases with days away (report on all FTOVs with one or more days away from work due to an occupational injury or illness), cases with restricted days (report on all FTOVs with one or more restricted days at work due to an occupational injury or illness), and first time personal visits (for a non-occupational injury or illness).
A detailed selection form for injury/illness variables (not shown) provides the user with functionality to select the type of injury or illness to be reported on. One field that may be associated with the injury/illness variable screen includes a selection between all injury/illness codes or specific codes to be defined below. The following fields are filters for specifying specific injury/illness codes. A summary diagnosis/detail diagnosis selection is provided. Selecting a summary diagnosis enables a user to select from a drop down list of high-leveled diagnosis to report on. A detailed diagnosis, on the other hand, is selected to specify detailed diagnosis by ICD-10 codes, which are provided via drop down menu. An injury/illness code field allows a user to select one or more injury/illness codes to report on (i.e. blood exposure, burn, contusion, etc.). An injury/illness type field allows a user to select one or more injury/illness types to report on (i.e. illness, injury, repetitive motion, etc.). A chapter field allows a user to specify the detailed ICD-10 diagnosis chapter information (i.e. chapter 19 injury, poisoning and certain other consequences of external causes). A main category selection field enables a user to categorize/define the area associated with an injury/illness via ICD-10 code (i.e. 19-15327-injuries to the ankle and foot). Sub-category selection fields are also provided to describe or further define the injury (i.e. 19-15327-S91.0 open wound to ankle).
A body part detail selection form (not shown) enables a user to select body parts to be reported on. Users can select from all body parts or from specific body part selections. Body part selections may be made via body part group, body part, laterality, etc.
An incident investigation code detail selection GUI (not shown) enables a user to select from all or specific incident details to report on. One selection field includes the type of contact. For example, contact with a source of energy or substance. Another selection field includes the source of the injury. For example, if the type of contact was slip, trip, or fall, then the source of the injury value could be working surface. A task/activity field enables a user to specify what task or activity the person was doing when the incident occurred (i.e. maintenance or repair, emergency, material handling, etc.). A sub-standard act field allows a user to specify a result of a sub-standard condition that was allowed to exist in an individual resulting in a sub-standard act/behavior (i.e. failure to use personal protection equipment, removing safety devices, etc.). A sub-standard condition selection field specifies a condition that was allowed to exist in the work place that led up to the incident (i.e. congested or restricted action/area, inadequate ventilation, inadequate guards, etc.). A controlling program element field specifies the type of safety program that most directly applied to an incident under investigation (i.e. chemical safety, no program or standard, etc.). A loss severity/probability of reoccurrence field may reflect actual or potential values. A graph icon is provided to open a window allowing a user to select the actual loss of severity and the probability of reoccurrence. A vertical access presented within the window may represent the actual frequence or likelihood of the event occurring. A horizontal access may represent the actual severity of the event. (See Table 12 for an example loss severity/probability of reoccurring stable.) Preferably, color descriptions are provided for frequency. Green (low) may be tolerated but should be reduced if possible with minimal investment. Yellow (medium) should be modified unless unreasonable. Red (high) is not tolerated, and correction is mandatory. For injury/illness incidence, the color scheme can be interpreted based on severity logic as follows: green means no medical assistance was required, yellow means medical attention was required with complete recovery, red means the person was seriously injured and there is permanent impairment, or there was loss of life.
A cost screen GUI for making detail selections (not shown) may include a variety of price of cost related criteria to be reported on. For example, reports may include total actual and potential costs, actual cost only, and potential cost only. Cost ranges may be specified for the report in a variety of categories (e.g. total costs, people costs, equipment costs, environment costs, etc.). People costs include the cost of people involved in the incident (i.e. cost of replacing injured person with someone else, etc.). Equipment costs include the cost of the equipment involved in the incident (i.e. the cost of repairing or replacing equipment as the result of an incident occurring). Environmental costs include the costs associated with an incident (i.e. the cost to clean up a chemical spill, etc.).
Notably, the DAM aspect of the present invention is directly interfaced with the OHSIM suite (EMR, IIM, DAM). According to one embodiment of the present invention, some data fields are required, whereas other fields are dependent on the incident type. For instance, type of contact is required for injury/illness incident types, but it may not be a required field for near miss or property damage incidents. Table 16 summaries which fields which, according to one embodiment of the present invention, may be required in OHSIM for use in connection with DAM reporting on human injury/illness. Of course, fields may be required or not depending on the particular implementation.
Table 17 summarizes OHSIM fields which may be required for DAM near-miss reporting:
Table 18, below, summarizes OHSIM fields which may be required for DAM property damage reporting:
While the best mode for carrying out the invention has been described in detail, those familiar with the art to which this invention relates will recognize various alternative designs and embodiments for practicing the invention as defined by the following claims.
