Covered by this topic
The following page defines data and fields that may be imported into MIE systems (WebChart, Enterprise Health) to create completed order records using the Completed Orders CSV API.
The abstract that follows should be presented to decision-makers or stakeholders interested in a general explanation of the Completed Orders CSV API. Technical details are provided in the remaining sections.
The Completed Orders CSV API imports patient order records.
It is valuable to recognize the following terminology as it pertains to MIE systems:
- A chart is a patient’s electronic medical information organized in tabular form. A chart is simply a way to collect different information on one topic, just like a physical patient chart would contain a variety of information on an individual patient.
- A panel is a group of one-time or recurring testing items to performed for a person.
- An order is a specific procedure that has been completed for a patient, such as an EKG. 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 system. See the Import Overview page for a more detailed explanation of terminology.
If you have panels with action items set to trigger on prior action (completed) (see other help documentation named Health Surveillance Panels-Actions.pdf) then it’s important to have specific order items in the employee’s history to have the ‘last completed’ date so the system knows when the last specific order item was marked complete in order to trigger other action items dependent on it. The last completed date is imported during the migration process to ensure that surveillance actions trigger with the appropriate due date. This is needed for manual and/or
automated panel membership needs before the HR feed is turned on and before panel membership automation (if there is any) gets turned on and processes via the scheduled job.
Access the Data Import tab found in Control. See the Data Import Tab help documentation.
Make sure all order items are listed in the import template tool that are part of the panel w/ a completion date, along w/ the representative event order item. Work with your MIE Implementer to import completed orders for Health Surveillance Panel needs.
Importing prior order id’s as ‘completed’ will show them as completed along w/ the date in the Due List View along w/ the comment from the import tool spreadsheet.
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
Specifications for the Completed Orders CSV API are available here.
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), recommended as best practice (BP), or optional (O) in the Completed Orders CSV API specification. Additional details and considerations are provided here.
The following fields are required:
- Chart ID (encounter_orders.pat_id) and Chart ID Type encounter_orders.pat_id_type) are used to to correctly identify a chart.
- Completed Date (encounter_orders.completed_dt) is the date the order was completed.
Although this information is not required, it is considered a best practice to use them:
- Due Date (encounter_orders.due_date) is the date that the order(s) is due.
These fields are optional:
- Modified Date (encounter_orders.modified_dt) is the date that the order was last modified.
- Comments (encounter_orders.comments) list any comments associated with the order.
- Panel ID (panel.panel_id) specifies the ID of the panel that this order is associated with.
This example imports two completed orders due to there being two order_ids (this is useful when multiple orders have been completed at the same time):
encounter_orders.pat_id, encounter_orders.pat_id_type, encounter_orders.completed_dt, encounter_orders.modified_dt, encounter_orders.due_date, encounter_orders.order_id, encounter_orders.order_id, encounter_orders.comments 10019, part:MIE, 12/23/2009, 12/24/2009, 12/25/2009, 4341, 4165, Two orders will be imported both with the dates provided
This first example shows how even though there may be one row utilizing multiple order_id columns, subsequent rows need not:
encounter_orders.pat_id, encounter_orders.pat_id_type, encounter_orders.completed_dt, encounter_orders.modified_dt, encounter_orders.due_date, encounter_orders.order_id, encounter_orders.order_id, encounter_orders.comments 10019, part:MIE, 12/23/2009, 12/12/2009, 12/25/2009, 4341, 4165, This row will create two orders which will share the date values given 01337, part:MIE, 09/20/2008, 09/22/2008, , 2314, , This row will only create one order without a due_date since it is blank
This next example illustrates having six encounter_order.order_id columns:
encounter_orders.pat_id, encounter_orders.pat_id_type, encounter_orders.completed_dt, encounter_orders.modified_dt, encounter_orders.order_id, encounter_orders.order_id, encounter_orders.order_id, encounter_orders.order_id, encounter_orders.order_id, encounter_orders.order_id, encounter_orders.comments 10019, part:MIE, 12/23/2009, 12/12/2009, 4341, 4165, 5132, 4578, 2234, 8874, Six orders here 01337, part:MIE, 09/20/2008, 09/22/2008, 4875, 6628, 2348, , , , Only three orders in this row
Example file with multiple order_id columns for four patients. Two of the patients will have their orders linked to the panel specified by the given panel_id File:EncOrdCom Example.csv