Summary Documents CSV API

The following page defines data and fields that may be imported into MIE systems (WebChart, Enterprise Health) to create structured text (HTML) summary documents using the Summary Documents CSV API.

Audience

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

Abstract

The Summary Documents CSV API imports non-discrete text data as an HTML document.
It is valuable to recognize the following terminology as it pertains to MIE systems:

• 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.
• 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.
• Free text refers to text that is entered free-form into a system and is not subject to any type of formatting or standards. 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.

Screenshots

The following screenshots show a simple CSV file, and the resulting summary document in an EH system. Example data is available on the tab “DB_Example” in the specification (see link in Specification section of this page).
The first several columns in the example CSV dictate some discrete metadata for the document, such as the Chart ID, (documents.pat_id) and External ID (documents.ext_doc_id).

Following the discrete fields, a Section Header (section_header) several Name Value Pairs (name_value.NAME), and a Narrative with Prefix(narrative.PREFIX) follow to create the body of a case summary.

Each column in the CSV above corresponds to a line of text in the resulting summary document. In this example, there are two section headers centered at the top of the document, several field name and value pairs, and at least one narrative block of text under each section header. These fields are all optional, repeatable, and may be ordered in any way to create a custom document to fit the needs of the client’s data. Keep in mind that any of the data in the body of the document composed of the section headers, field name and value pairs, and narratives are not discrete and not searchable.

The last screenshot displays a list of the Document Summary in EH. This is a listing of all of the documents in a patient’s (employee’s) chart. This view allows a user to see at a glance service dates, locations, document types, and the document title or subject of all of the documents on a chart.

Workflow Considerations

The following subsections outline situations in which summary documents are useful, and when they are not.

When to use Summary Documents

Summary documents are stored in EH as formatted text documents. They are most useful for storing notes (physician or nurse notes, emails regarding an individual, contact notes, etc.), or two-column structured content that is not used for reporting, such as lists of medications or injections.

Advantages of Summary Documents

Summary documents can be used to store any type of information relatively quickly. There is no mapping of discrete fields to MIE’s API or converting internal codes to MIE’s specifications, which is tedious in some applications. Use summary documents for quick conversions to create reference documents for use in the clinic.

Disadvantages of Summary Documents

The data in the body of a summary documents is not discrete. Only information in the document header (Chart ID (documents.pat_id), Service Date (documents.service_date), Location (documents.location), etc.) is stored as discrete data. The contents of the document body is not stored discretely and may not be searched or reported in EH.
Additionally, only text may be stored by this API. While documents in EH may be anything from images, PDFs, Word and Excel documents, or many other storage types, this API is only for structured text documents stored as HTML.

Discrete and Non-Discrete Data

The prior section on Disadvantages of Summary Documents gives an overview of the main drawback of using this import: the data in the body of the document is not discrete data. Some data is stored discretely on each document. Typically this data is useful for categorizing and quickly finding a summary document. As discussed later in this document, many of these fields are considered best practice to specify data.

• Chart ID (documents.user_id): A discrete identifier is used to connect the summary document to a specific chart.
• External ID (documents.ext_doc_id) and Interface: The interface name entered at the time of data import as well as the External ID(documents.ext_doc_id) (typically the autoincrementing or unique key from the source database or spreadsheet) is stored discretely, although it cannot be viewed from the front end of EH.
• Author (Originator) ID (documents.origin_id) and Entering User ID (documents.user_id): Both the creator of the content and the one who enters the data are stored discretely.
• Service Date (documents.service_date), Origin Date (documents.origin_date, and Enter Date (documents.enter_date) : These dates are all stored discretely for each document.
• Location (documents.location): The service location may be used to specify either a clinic location or the system from which the data came (EG: Medgate, OHM, and so on). If a clinical or service location readily available to map to a location in EH, that is typically preferred.
• Document Type (documents.doc_type): The document type classifies the contents of a document. This helps to quickly understand at a glance what kind of data may be found in the document. Additionally, classifying documents with document types creates the ability to search for and report on documents in the system. Examples of document types include insurance cards, patient photos, nurse notes, and so on.
• Document Title (documents_txt.subject): The title or subject of the document is short text field that is unindexed in the database, but it is stored separately from the body of the document. It is used for quick reference to specify the contents of the document from an EH list without actually opening the document. Thus, it is included as key piece of discrete data to quickly provide a preview of the document. The CSV Summary Document headers Section Header (section_header), Name Value Pair (name_value.NAME), Narrative (narrative), and Narrative with Prefix (narrative.PREFIX) are all used to build content for the body of the document. Any data included in the CSV under these headers is not discrete, searchable, or reportable.

Examples of Discrete and Non-Discrete Data
The first screenshot shows a list (listview) in EH. This can be seen by selecting the Document Summary tab from a chart. A list of documents is displayed showing dates, location, doc type, and title.

The second screenshot shows a document’s header, which contains much of the discrete data discussed above.

Document properties display discrete information about a document that is not available in the document header.

Documents may be searched using the following criteria in EH: patient name, entering user, authoring user, interface name, location, service date, creation date, revision date, subject, storage type (this API always creates HTML files), and Doc ID, which is an internally assigned identifier.

Creating Discrete Data from a Summary Document

Many clients have opted to create summary documents for their medications, injections, or other data that is discretely coded in EH. In the legacy systems that are converting to EH (Medgate, OHM, spreadsheets, etc.) data is often entered as free text, including typos, without a coding system, or with incomplete data. Clients may not want to take the time to map free text or incomplete data from the legacy system to MIE’s coding standards at the time of conversion. In those instances, the client creates summary documents for the data, since creating summary documents may be much quicker to create with EH’s API. Then the data is reviewed with the patient/employee during the first clinic visit after EH is in use. At that time, a clinician can go through the legacy summary document and quickly add the relevant data discretely using EH’s fast autocompleting fields and drop-down menus, ensuring proper coding, and facilitating reporting on the data.

Creating a Summary Questionnaire with Non-Discrete Data

It is sometimes valuable to import questionnaire data as a summary document. In this example, the Name Value Pairs (name_value.NAME) columns function as questions from a questionnaire with the responses listed in the corresponding column.

The questionnaire document is listed for the specified patient (Dolly Bacon).

Questions and corresponding responses are listed in the questionnaire summary document.

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 Summary Documents 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 Summary Documents CSV API specification. Additional details and considerations are provided here.

Required The following fields are required:

• Chart ID (documents.pat_id) and Chart ID Type documents.pat_id_type) are used to to correctly identify a chart.
• External ID (documents.ext_doc_id): Identifies a record in the original data source (i.e., this is often the primary or unique key on the table of the legacy database that is being migrated to the MIE system).
• Document Types (documents.ext_doc_id): Used to categorize documents, as mentioned above. All documents in EH have a document type. Note that the document type listed in the CSV must exist in the EH system (in EH, go to Control Panel > Document Types) or that line will be rejected. For further reading on document types, refer to the Enterprise Health online help titled Document Type Tab.

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:

• Service Date (documents.service_date): Shows the pertinent date for the summary document, and it is displayed in the document list view.
• Location (documents.location): Shows where the service took place. This piece of metadata may be used in reporting.
• Document Title (documents_txt.subject): Displays in the listing of documents in EH and helps identify a document quickly.
• Section header (section_header), Name Value Pair (name_value.NAME), and Narrative (narrative) are used to structure the contents of the document.

Optional Fields The following optional fields are needed to link the document to a patient encounter:

• Encounter External Identifier (encounters.ext_id)
• Encounter Interface (encounters.interface) Including the field encounter order_id will also create an encounter order of the identified in the field.

Multi-Line Documents For complex queries (one-to-many) that generate CSV content, you may concatenate multiple rows into a single document in EH. Documents are grouped by required fields. The screenshots below show an example that creates two documents.

The combined summary documents display on the patient’s chart.

Examples

Examples using sample data are provided on separate tabs in the specification.

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 and EH using the validation test script. Summary Documents CSV API Validation Test Script

Related Pages

• Data Import Master List