Data Acquisition

Harkening back to the simple principle that information needs should mirror organizational purpose, there must be focus in developing databases. In many ways, this is what separates electronic health records (EHRs) from operational databases.

At the operational level, databases are built with thoughtfully identi­fied key topics, which are supported by fields. Database fields are categories of information that are stored—these must be organized for easy retrieval. A field represents a character, group of characters, or series of numbers that defines a person, place, or thing.⁹ In health care databases, fields comprise the individual categories of information which are combined beneath the umbrella of a single encounter. Examples of encounters in a transport data­base might represent a single trip (trip #071452), with fields permitting the establishment of demographic data, operational data, clinical data, and ulti­mately, quality improvement data (Table 16.1).

Table 16.1: Categories of Patient Data Recommended for a Comprehensive Database

1. Demographic data: Case identification, patient age, referring facility identification and location within the facility and classification (can be preprogrammed for routine referral sources with prepopu­lated fields, although needs to be amendable if changes are needed), and referring and primary care physician identification.

2. System data: Mode of transport, staffing levels, use of specific personnel and equipment during trans­port, date and time of the transport and pretransport and intratransport times, and communication attempts and successes between medical control and referring hospital with times.

3. Clinical and outcomes data: Chief complaint, provisional diagnosis (InternationalClassification of Diseases, Ninth Revision, Clinical Modification [ICD-9-CM]), procedures (Current Procedural Terminology [CPT]), reason(s) for transport, clinical status (eg, intubated, pressors required), adverse events, discharge diagnoses (ICD-9-CM), and disposition. Uniformity of coding will be facilitated by storing extracted lists

of ICD-9-CM and CPTcodes for diagnoses and procedures frequently encountered during transport and critical care.

4. Quality improvement: Specific prospective or quality improvement monitors should be incorporated into the database. To understand the true effect of certain events or occurrences, these monitors should be capable of relating designated events to specific outcomes.

Credit: Hamilton Schwartz, MD, MPH, FAAP, and Michael T. Bigham, MD, FAAP, FCCM from Cincinnati Children's Hospital Medical Center. the calculated result. For reference, a sample of database fields for a single­center custom database is represented in Table 16.2. This is the model whereby metrics are derived for analysis from discrete data fields—similarly stated data are facts, and information is the result of processing those facts to reveal its meaning.⁹

With the exception of only the most highly technically integrated orga­nizations, databases often are still dependent on some indirect method of populating data fields. At the simplest level, databases can be effectively populated by pen and paper methodology. Data entry into simple electronic databases can also be accomplished easily, although electronic databases ben­efit from data validation to reduce data entry error and permit more accurate data extraction. An example in which data validation might be important is when a patient's date of birth and weight are entered into discrete database fields. An algorithm might be programmed that limits the allowable weight of an 11-month-old child from 5 kg to 20 kg. This would prevent entry with 10-fold errors (ie, erroneously entered weight of 100 kg for a 10-kg child) and possibly entries using pounds rather than kilograms. More advanced electronic databases extract information to populate fields from an exist­ing EHR, thus, reducing some or all requirements for manual data entry. Similarly, there are overlapping interests in existing databases that might inform transport databases and lessen the overall efforts around patient out­comes if these are adequately tracked in an existing or parallel database. For example, a temperature measured at the conclusion of a neonatal transport will likely be tracked on both a transport database and a neonatal intensive care quality database.

Table 16.2: Sample Custom-Built Database Fields for a Clinical and Operational View of a Single Pediatric/ Neonatal Critical Care Transport Team