Core Data Requirements

Core Query Data Requirements

Purpose

This is the initial core set of data that will be translated from the EMR to the End Point and be accessible from the Hub to be queried against. This document will describe the core data in clinical / business terms and this will translated and mapped to E2E and, ultimately, the EMRs.

This document is meant to describe the data requirements in clinical / business terms and will need to be confirmed and mapped to the E2E specification as part of the design / development work.

The focus is on coded elements as that will be usable in the network, at least initially, to be questioned against. E2E exporters may include additional elements and may include free text, but this is not the focus for the network.

This data set will be expanded over time.

Patient Data Sections

(Described in more detail below)

1. Demographics
2. Appointment History
3. Billing History
4. Laboratory Results
5. Medications and Prescription History
6. Problems and Conditions
7. Observed Measurements

Attachments are not of interest to us at this time (potential exclusion: billing attachment, which is structured - see below).

Demographics

Aspects of demographics will be of interest to question answering. Not to identify patients but to identify groups of patients.

Initial Demographics will include:

• Birthdate
• Administrative gender
• Postal Code (first three digits only)
• Patient's Language

Appointment History

There can be zero to many encounters per patient. Encounters could be multiple types of interactions about a patient, the most typical being a face to face visit, but could also include phone calls and others.

The encounter will contain the following data:

• Start Date / Time
• End Date / Time (or could be length)
• Reason for Encounter, if known
• Encounter Type (fact to face visit, phone call, home visit, etc)
• Provider(s) involved by type (e.g. family physician, RN, etc)
• Appointment creation date / time

Billing History

Currently the E2E specification relies of an MSP file and has not specified further. Work here needs to be considers. For now, see MSP billing file specification.

NOTE: E2E does not currently allow for other billing to be documented (e.g. 3rd party billing)

Will want to query against the following concepts:

• billing service code
• billing diagnostic codes (up to three)
• billing date of service
• date submitted

Laboratory Results

Laboratory Results are a key element to question against for a range of questions and data quality probes to assess other areas of the record. A host of content could be queried from the structure of the laboratory results and much of this is standardized, to a degree, from the resulting laboratories.

Will want to question against the following concepts:

• Ordering Provider
• Result Observation Code
• Result Name
• Result Date/Time
• Result Value
• Interpretation Code (Abnormality Flag)
• Reference Range
• Specimen Collection Date
• Resulting Organization

Lab order / results matching is not considered at this time

Need to consider how to handle non-numeric results liker a TSH of <0.01 or a HIV Viral Load of <40 that are resulted as text not numbers when the rest of the results are numeric

Medications and Prescription History

There are several early questions that will be focusing on medications and prescribing. Thus, it will be important to have this area well defined for questioning.

Conceptually, E2E divides medications into two several components, including: Medications and Prescription History

Medications

This is the list of medications that are linked to the patient record. They may or may not be prescribed and, if prescribed, they may or may not be prescribed within the EMR (i.e. they may be prescribed by another provider at another location).

• Drug Code(s) (which may also contain class information)
• Strength
• Currency status (i.e. is the medication current)

Prescription History

Prescriptions are linked to the medication. These are the discrete events of prescribing (note we could also model dispensing and administration events, but they wouldn't be reliably captured).

• Start/Stop Date
• Prescriber (to cluster if needed for a question)
• Coded prescription instructions
  • Dose / Dose range
  • Strength
  • Route
  • Frequency
  • PRN status

Problems and Conditions

Problems / health conditions are coded elements tagged to patient. For example, diagnoses of chronic diseases. These can be broader than diagnoses, of course. Key is that they are not specific to an encounter and they are coded. We will collect all documented problems and not be limited to a subset. If the EMR supports SNOMED CT, we will support SNOMED CT, otherwise we will support ICD 9. Problem list elements will have the following elements:

• Diagnosis code (SNOMED CT)
  • Diagnostic Code
  • Code System
  • Original Text
• Onset date
• Date resolved
• Problem status
• Diagnosing Provider
• Diagnosis billing Code (ICD9)
• Diagnosis Date

Observed Measurements

Observed measurements will, over time, contain many items that come from the physical examination of the patient and are documented in a structured form in the EMRs. The current set will include the following:

• Blood Pressure
  • Date / Time
  • Systolic
  • Diastolic
• Body Temperature
  • Date / Time
  • Method
• Heart Rate
• Weight
• Height
• Waist circumference