Keywords

1 Current State

To understand the inherent challenges and potential of using pediatric EHRs for research, one must understand the extent to which EHR systems are used in various pediatric settings. Information on adoption of these systems in child health is best known for the United States, but trends are similar in other developed countries.

1.1 Adoption Rates

Child health providers—specifically, pediatricians—are thought to be slower than general practice providers in adopting electronic health record technology (Lehmann et al. 2015; Leu et al. 2012; Nakamura et al. 2010). Children’s hospitals, because they tend to be urban and academic, are often ahead in adoption as are institutions of larger size (Andrews et al. 2014; Nakamura et al. 2010). The reason for the slower adoption in pediatric practices probably relates to the difficulty of fitting child health needs into a product designed for general, adult care. In this way, current EHRs violate the pediatric adage that “children are not small adults.” If EHRs are not designed or cannot accommodate the unique needs of the pediatric population , healthcare providers are not likely to be quick adopters of such systems. A recent estimate of pediatric adoption of fully-functional EHRs in ambulatory practice are at about 6 % (Leu et al. 2012), although by now this is undoubtedly higher given recent trends (Lehmann et al. 2015).

The U.S. Meaningful Use program of the HITECH Act (Blumenthal and Tavenner 2010; HHS 2009) of the American Recovery and Reinvestment Act of 2009 intends to provide financial stimulus to physicians and hospitals to adopt EHR technology. There is a version of the program for Medicare (the the U.S. federal public payment system for the elderly) and for Medicaid (the U.S. state/federal program for the poor and disabled). Since pediatricians do not generally see Medicare patients, child health providers and hospitals usually qualify for the Medicaid program. In this program, individual providers may qualify for an incentive payment if they have a minimum of 30 % Medicaid patient volume, or, if they are pediatricians, 20 % Medicaid volume. This criterion covers about half of the office-based pediatricians in the United States (Finnegan et al. 2009) but does leave out a significant number with very low Medicaid volumes. These providers tend to practice in more affluent areas, but pediatrics is not a specialty with very high margins under the best of circumstances, so Meaningful Use will not directly affect the adoption rates for this large group. Member survey data from the American Academy of Pediatrics estimate that up to 2/3 of U.S. pediatricians may be eligible for some incentive payment (Kressly 2009), so the next few years may be a time of rapidly increasing pediatric deployment of EHRs.

1.2 The Pediatric EHR Market

The pediatric EHR market includes small pediatric practices of one or two practitioners all the way up to large, hospital-owned practices of hundreds of pediatricians. There is similar variability in the crowded U.S. EHR vendor market, where a given company specializes in offering its product to practices of a certain type or specialty area. In the early 1990s, almost all electronic medical record systems were of the home-grown variety. Today, several hundred companies in the U.S. market offer over 3000 different EHR systems (ONC 2016) and the services that accompany their deployment, customization, and maintenance. While there has been some vendor dropout and consolidation (Green 2015), the EHR marketplace is far from the point where only a few major companies service the majority of customers. Because of the small size of the pediatric EHR market, there have been very few companies that have succeeded in marketing a product that is specific to pediatrics.

1.3 Vendor Systems

EHR systems today are sold by software vendors attempting to gain a large enough customer base to sustain a business. While this model provides a more sustainable source for software than the home-grown model, it creates a problem for child health providers: Most customers are not pediatric, so most EHRs are not designed specifically for pediatric care. A further problem for child health researchers is that practically none of these systems are designed with research in mind. Instead, they are designed for patient care and the administrative tasks that support patient care. Figure 1.1 is a mock-up of an EHR screen that highlights these assumptions.

Fig. 1.1
figure 1

Elements of an EHR user interface that imply an exclusive orientation to adult patients. In the case of tobacco history for an infant, one would be interested in recording passive smoke exposure, which is not included in this display. In the education section, it is implied that one’s years of education are fixed and in the past, as they would be for most adults

Full size image

While these assumptions are not truly prohibitive of these systems’ use in a pediatric environment, they often force workarounds that affect the quality of data in the system. For example, when faced with the unavailability of an adequate field to capture a concept, one may feel forced to use a free-text field intended for some other purpose to store the information. In this case the data loses integrity (such as a conversion from structured to unstructured data) and it becomes impossible to apply computational methods to the data.

Child health professional groups have attempted to promulgate catalogs of functionality necessary for the care of infants and children (AHRQ 2013; CCHIT 2010; Kim and Lehmann 2008; Spooner 2007; Spooner and Classen 2009). Fortunately, vendors who sell systems to pediatric practices and children’s hospitals are gradually creating mature systems that respond to their customers’ pediatric-specific needs.

1.4 Homegrown Systems and Publication Bias

Despite the prevalence of vendor systems in the marketplace, the bulk of reported literature on the use of EHRs from the initial reports of the 1970s through most of the first decade of the 2000s is based on experience with home-grown systems (Friedlin et al. 2007; Gardner et al. 1999; Miller et al. 2005). The result is that the evidence on which to guide the implementation of EHRs is only partially applicable to most installed systems. Add to this the complexities of systems customized for pediatric care and the connection between the results of the adult-oriented, home-grown software and installed, vendor-provided systems is even more tenuous. This phenomenon makes the pediatric EHR environment ripe for research to be conducted on the systems themselves, but it also makes it hard to definitively answer questions about what works best. As such, reports in the informatics literature should be critically analyzed to determine the external validity of published results, in particular whether the system being tested or described is a vendor solution or homegrown application.

1.5 Pediatric Versus General Environments

The main features that differentiate the pediatric environment from that of general adult care are:

  • Diseases And Conditions That Are More Prevalent In The Young ; Congenital disease and conditions related to abnormal growth and development are not usually part of adult care. Templates, data fields, terminology systems, and other clinical content in an EHR may therefore require customization to meet different clinical needs.

  • Parental/Guardian Proxy; In the pediatric environment parents (or guardians) are almost always involved in encounters and responsible for care decisions. While there are certainly family members of adults involved in the care of the patient, in most cases the patient is competent to make health care decisions. Siblings may receive care at the same encounter.

  • Physical And Developmental Growth; The pediatric patient is growing and developing physically and mentally at a fast clip. Weights change rapidly, especially in the first year of life. Developmental capability to participate in self-care increases with age. Because of children’s dependent status, social situation has a much greater impact on health than in most adult care.

1.6 Pediatric Subspecialties Versus the General Purpose EHR

If it were not difficult enough to apply pediatric assumptions to general-purpose systems, the difficulty is compounded in the case of pediatric specialties. Specialty care entails more detailed, less common, and often more granular, special requirements. There is also more variation of care practices at the subspecialty level as there tends to be less evidence available to standardize procedures and protocols. It is not uncommon for several physicians within the same group to have differing opinions on best practices when little evidence exists to guide the way. In many cases there may also be a paucity of pediatric research (as compared to adults), further complicating the issues of standardization.

In pediatric specialties, the very clinical content of the practice may be quite different from their adult counterparts. Pediatric cardiology, for example, is chiefly concerned with congenital disease, whereas adult cardiology focuses more on acquired cardiovascular disease. This shifting of focus on disease etiology and pathology disallows any loose extrapolation and adoption of adult data to the pediatric population .

1.7 Data from Natural Workflow vs. Research, Primary vs. Secondary Use of Data

As EHRs are designed to support clinical care, data that makes its way from the EHR into a data repository is of lower quality than what one might find in data specifically collected for research. Data validation, completeness, and standard processes are very much secondary to successful completion of clinical work. It is for this reason that most research from clinical environments is based on claims data, where some energy is expended to ensure data accuracy and completeness. Of course, claims data is at least one step removed from the important clinical details of the patient encounter.

2 Workflow and the EHR

2.1 Data Entry

The function of an EHR is not primarily to serve as a data-entry tool . Its purpose is to facilitate patient care for individual patients. In doing so it offers some opportunities for data extraction for other purposes (operations analysis, research, quality measurement). Since EHRs are not designed for research, analytics, or population management, there will always be a need to input research-specific EHR data into the data repository, as well as methods to extract it. The value of that data is directly related to the quality of the data entry. Missing values threaten the validity of any measures based on the data and data cleansing, a time and resource-consuming endeavor. For this reason, it is best to use data that is already captured reliably (like orders for tests) or to make workflow changes to increase reliable data entry. In a busy clinical environment where clinicians are already working at capacity to meet documentation guidelines for billing, there is little opportunity to make these changes. Clinicians will often ask for a “hard stop” reminder to enter data (or, more commonly, to get someone else to enter data), but the effectiveness of alerts is very limited (Strom et al. 2010) and hard stops are usually abandoned as annoying. Any effort to make sense of the quality and integrity of EHR data must take into account some knowledge of the clinical workflows that produced it.

2.2 Multiple Job Roles and Their Interaction with the Record

Like the paper record, the electronic record accepts input from people in multiple job roles: physician, advanced-practice nurse, physician assistant, nurse, medical assistant, and multiple clerical roles, among others. Effective data organization depends on clear job roles related to the record. For example, if it is not clear who is responsible for the accuracy of the patient’s medication list, the data extracted will be of low quality. When one puts together a plan for the use of EHR data, part of the workflow analysis should include the establishment of how clear the job roles are. Job roles, or “profiles” as EHR systems refer to them, usually define how data is viewed and input in the user interface . When this variation occurs, it is not unusual for data to be entered (or not entered) in multiple ways. Great attention should be paid in designing or customizing these screens and standardization of entry and viewing carried out whenever possible.

2.3 Special Pediatric Workflow Issues

Multiple Patients Per Encounter

Siblings within the same family are often seen together, especially for well-child care. In no other area of medicine is this type of multi-encounter a common experience. EHRs can be configured to allow access to multiple patient records at once, but data sharing between patients is not typically supported. In the pediatrics, there are areas of EHR data that ought to be shared between patients, like family history and social history, or guarantor information, but typically this must be entered separately for each patient.

One example where linking of records could be helpful in both the adult and pediatric EHR would be to provide the capability to update and/or duplicate the family history section in related patients’ charts. For instance, if two siblings are taken care of by the same practice, family history in their direct ancestors would be identical. If the records were linked through an EHR social network, updated data in one sibling’s chart could offer a prompt in the other sibling’s chart that useful information needs to be verified and inserted into the record. This form of networking could also prove helpful in generation of genograms. In a more practical fashion, duplication of pregnancy circumstances and perinatal events in the charts of twins would reduce large amounts of manual data entry . There are a variety of medico-legal and ethical concerns with these kind of linkages that will not be addressed here, but the reader should be aware of the current paucity of this functionality and its implications in research data obtained from EHRs.

Multidisciplinary Clinics

The large number of rare disorders seen in pediatrics, coupled with the relative rarity of pediatric specialists with expertise in these disorders, creates the need to bring multiple specialists together into a single patient encounter. Arranging visits this way is a great convenience to the family, but also allows specialists to work together on difficult multi-organ problems that might otherwise take months to coordinate. In children’s hospitals, numerous clinics of these type are created or the constituents modified every year. EHR systems should support this kind of workflow, but since it is not typical in adult or non-specialty care, it is not a smoothly implemented, standard feature of most EHRs.

3 Special Functional Requirements and Associated Data

The following section describes some of the functionality and associated data requirements that are, for the most part, unique to pEHRs. We discuss both basic functionality that should be considered required, as well as optimal, ideal functionality that would greatly increase the data quality captured in EHRs.

3.1 Growth Monitoring (Including Functions of Interest Only to Specialty Care); Basic Growth-Chart Functionality

Perhaps the one clinical activity that distinguishes pediatric care from adult care is growth monitoring. While weights, skinfold measurements, and even height are measured in adult care and tracked, the assumption is that these are stable measures. Growth and development are fundamental processes in pediatrics, especially in the ambulatory setting. The rapid progression in both are carefully tracked in the longitudinal health records and constantly evaluated for normality or deviation from expected patterns. As such, it is expected that optimal EHRs have the ability to robustly track and identify both healthy and pathologic growth. In children, of course, there are growth patterns that constitute a wide range of normal, and growth patterns that signify disease. Some diseases, like growth hormone deficiency, affect growth directly. Others, such as inflammatory bowel disease, affect growth negatively through catabolic and energy-consuming inflammatory processes. Other abnormal growth patterns are part of inherited conditions like Prader-Willi syndrome (obesity) or Turner syndrome (short stature). In routine, well-child care, examination of the growth chart is standard practice. In the ongoing management of specific, growth-affecting conditions, growth chart analysis is similarly routine. EHRs that intend to support pediatric care must support display of these data in a way that goes beyond a simple time plot of the values. Critical to the functioning of a growth chart display is concomitant display of growth norms, in order to allow interpretation of patterns (Rosenbloom et al. 2006).

3.2 Data Found in Growth Chart

Weight and stature are the very basic data tracked in growth charts, but the concept of height for patients who cannot stand (or stand cooperatively) is usually conceptualized as length. Norms for young children (less than 2 years old) are typically separated from those of older children in this respect. In a typical EHR, there are growth charts for children 0-36 months old and for those over 2 years old. Data storage for the points that are plotted on the stature curves may therefore vary as to which is a height and which is a length. Growth percentiles of the same data point will also vary across different chart types, which can be particularly confusing in the 24–36 month age range. The same height or weight, for example, will often generate discrepant percentiles when a user alternates between views of different growth charts.

See Fig. 1.2 for examples of typical growth charts in use in an EHR. The essential function of the growth chart is to give the user a sense for where the patient falls within a similar age population , expressed as the percentile at that age. Values higher than 95 % or so or below 5 % or so are considered abnormal, but must of course be interpreted in the context of the child’s overall growth. For example, if a normal child happens to be small, owing to their genetic predisposition, they may never rise to a particular predetermined percentile. Their growth velocity may be considered normal as it hovers around the 2nd percentile throughout life. Such tendencies are referred to as “following their own curve”; in fact, departures from that curve into “normal” range may indicate an abnormal state for that patient. It is this complexity that makes growth charts irreplaceable by number-driven decision support . There does not appear to be a current substitute for a clinician viewing the curve graphically against a set of norms.

Fig. 1.2
figure 2

Mockup of a growth chart as deployed in an electronic health record system. The isobars represent constant age-specific percentile for the metric (in this case, weight). In this case the patient has crossed the 3rd, 10th, and 25th percentile isobars. This might represent an abnormal growth pattern (gaining too much weight) or recovery from chronic illness to a normal weight, depending on the clinical situation

Full size image

Head Circumference

is also essential for basic growth chart functionality. In standard growth charts used in general pediatric care, these charts go up through age 36 months. There are norms for older children and young adults (Nellhaus 1968; Rollins et al. 2010), but these are used only in specialty practices like oncology or neurosurgery to monitor head growth after radiation or tumor removal.

Body Mass Index

calculated from weight and stature, is also becoming a standard growth chart in pediatric practice. In adults, when BMI is used as an index of the severity of either obesity or malnutrition, the cutoff values to indicate abnormal body mass index are the same for all ages. In children, interpretation of BMI rests on the percentile value within the child’s current age. The U.S. Centers for Disease control publishes these norms (CDC 2012) so that graphs can be made and percentiles calculated.

Height Velocity

In specialized areas of pediatrics, where growth is the focus (e.g., endocrinology), there are normative curves, implemented much like the curves for primary anthropometrics, for the rate at which height changes over time. These curves are used to evaluate the severity of growth impairment and to monitor the use of drugs which might affect growth one way or the other. There are no published curves for weight velocity, although the current interest and prevalence of obesity in the U.S. may change that.

Other Anthropometric Values

Norms for chest circumference, skinfold thickness, and leg length have been developed, but are used infrequently. In any case, the techniques for display, where data are displayed against normative curves, remain the same.

Percentile/Z-Score Calculations

While plotting primary data against norms makes for an effective visual display to support clinical decisions, information systems can compute the applicable percentiles given a measurement and an age, provided the proper normative data are available for the calculation. The U.S. CDC provides tables for this data for the datasets they publish, and a process for computing the percentiles (CDC 2012) (see the WHO vs CDC subsection below). Most growth charts are published merely in graphical form, and the data required to perform the computation is not provided. The computation process calculates a z-score (number of standard deviations above or below the mean for an age) and then applies assumptions about the distribution to come up with a percentile within that distribution. For extremes of growth, the z-score itself may be more useful, since the difference between a weight at the 99.96th percentile may be hard to distinguish from a weight at the 99.99th percentile otherwise. Few EHRs provide the z-score directly, but it is a desired functionality for pediatric specialists who focus on growth.

3.3 Special Population Data

Up until now, we have discussed EHR functionality associated with normal growth. In this subsection, we address the topics of collecting and managing special population data.

Congenital Conditions

Disordered growth is a major feature of a variety of congenital conditions such as Noonan syndrome (Ranke et al. 1988), Laron dwarfism (Laron et al. 1993), and Williams syndrome (Martin et al. 2007). The measurements are the same, and the growth charts work the same way, but the normative data are different. EHR systems generally provide some of these normative curves that can be selected manually or automatically depending on clinical conditions.

Extremes of Growth

In conditions causing extreme failure to thrive or in obesity, the usual normative curves that express curves close to the 99th and 1st percentile may not be adequate. In these cases, the data points are so far removed from the highest and lowest curves that users find it difficult to describe patterns based on the curves. In these cases it is better to create normative curves based on z-scores, so that users can express the patient’s growth state relative to the position of these curves far outside the normal range.

Intrauterine Growth

Similar to post-natal curves, intrauterine curves, based on gestational age , combined with parameters measurable via ultrasound (crown-rump length for stature or biparietal diameter for head size) are useful for expressing growth patterns of fetuses. These sorts of curves are more often found in system designed for obstetric use, but may be useful in the immediate post-natal age.

WHO vs. CDC

The World Health Organization has published a set of growth charts for infants that are based on a sample of healthy, breast-fed infants (Grummer-Strawn et al. 2010) The motivation for creating these charts is to present a more physiologically accurate view of how normal infants should grow. Because the CDC growth data has been in use much longer, EHR system vendors have had to deal with the ambiguity of two widely accepted growth charts for normal infants. Researchers using percentile growth data from EHRs should be aware and take note of the source in order to make accurate comparisons.

Specialized Growth Analysis

Growth chart data must sometimes be temporally related to other physiologic events. For example, one may want to indicate on the growth chart a child’s sexual maturity rating, since advanced stages of sexual maturation are associated with cessation of normal growth. One might also want to indicate the “bone age” (an estimate of age based on the appearance of bones on plain-film radiography) on the growth chart in cases where the age of the patient is uncertain, as in some cases of international adoption. There are no standard ways of displaying these data within a growth chart, but practitioners who focus on growth cite this function as essential to full growth chart functioning (Rosenbloom et al. 2006).

Correction for Gestational Age

Infants born prematurely, because of their smaller size, require special growth charts (Fenton 2003; Fenton and Kim 2013). Outside the immediate post-natal period, though, practitioners generally use regular growth charts, and graphically indicate a correction factor for prematurity. The expectation is that premature infants will eventually catch up to other infants of the same postnatal age. Part of the analysis of growth charts in premature infants is the time it takes them to achieve this catch-up growth.

4 Drug Dosing

Given the inherently changing growth of children, prescribing the appropriate dose of medications can be difficult. What follows is a discussion of the practical and research implications of prescribing medications through an EHR.

Weight-Based Calculations

Medications in infants and small children are generally dosed by body weight. As body weight increases with age, children grow into the adult dose; the weight at which one can receive an adult dose varies by medication. Such weight dependence makes the act of prescribing medications to young people more complex. In addition to the act of prescribing , there are complexities related to the storage of the prescription and the decision support that might be provided to the user . EHRs used in the care of children should, at a minimum, provide the ability to calculate a given dose of a medication based on the actual weight (Kirkendall et al. 2014; Shiffman et al. 2000; Spooner 2007). More advanced functionality includes providing standard weight based doses, offering dose range checking, and providing dose ranges dependent on clinical factors, like diagnosis.

Weight Changes

As infants grow, their body weight changes rapidly enough that they may “grow out of” a medication at a given dose. Providers who care for infants on chronic medications know to re-prescribe when body weight changes, but a sufficiently sophisticated information system can help to support the decision to re-prescribe, or at least to make it easier by carrying forward weight-based dosages to subsequent prescriptions. Data structures used to store prescriptions must therefore retain the weight-based dose (e.g., 40 mg/kg/day) as data.

Dosing Weight

It is not always the case that actual body weight is the best datum to use in calculating weight-based prescriptions. In very young neonates, who lose significant amounts of weight as they adjust to life outside the womb in the postnatal period, one may prefer to use a “dosing weight” to keep prescriptions consistent. Similarly, patients who gain weight due to edema will need a more appropriate weight upon which to base dosing decisions. EHR systems need to take into account different methods of storing and using weight in support of prescribing .

Daily vs. Single-Dose Reasoning

In dose-range decision support , there are limits for single doses and for total daily doses, both of which must be accounted for in decision support. Pediatric prescribing guidelines are usually written in mg/kg/day divided into a certain number of doses. This format takes into account the per-dose and daily dose parameters, although EHR dosing rules may provide these two parameters separately.

Power-of-Ten Errors

In providing small doses to small people one of the most common and most dangerous dosing errors is the situation where the dose is higher by a factor of 10 or 100, due to confusion between the volume to administer (e.g. 2 mL) and the mass to be administered (20 mg), faulty multiplication, or the migration of a decimal point (Dart and Rumack 2012). In adult care, doses tend to be standard, so there is no way for practitioners to recognize the “usual” dose, since there is no usual dose. Dosing decision support in EHRs is mainly intended to mitigate these kinds of errors.

Physiologic Variation with Development

A subtle factor that affects some pediatric prescribing is the effect of maturation of organ systems in the immediate post-natal period that affect drug clearance rates. In order to provide adequate decision support for these dose variations, the ideal system would need to be able to compute different ideal doses at ages measured in days or even hours, and to take into account prematurity. For example, for the antibiotic gentamicin, which is commonly prescribed to neonates in the intensive care setting, one common guidelines is that a premature neonate weighing less than 1000 g at birth would get 3.5 mg/kg/dose every 24 h, but a term neonate less than 7 days old and weighing more than 1200 g would get 2.5 mg/kg/dose every 12 h, but the same infant over 7 days old (but less than 2000 g at birth) would get the same dose every 8–12 h (Taketomo et al. 2011). It’s easy to see how such complex rules can be difficult to model in a prescribing system, and difficult to present to users in an intelligible way.

Off-Label Use

Vendors of drug-dosing decision support databases, commonly used in EHR and e-prescribing products, offer guidelines for dosing that are used in decision support . Because many of the drugs used in pediatrics are not actually approved for use in children under a certain age, it can be seen as controversial for a vendor to provide a non-FDA-approved dose range. Because of the absence of FDA-approved dose ranges, local variation in these ranges is common. Such variation makes it even more difficult for drug-dosing decision support database vendors to provide this decision support confidently. The result is a database with incomplete data, where users of EHRs that use these data must fill in the blanks. Across data from multiple institutions, tremendous variation is seen in the dosing rules that are brought to bear on these prescriptions.

Metric vs. English Controversy

Because of the dependency of changing body size on therapies, pediatric clinicians are in the habit of using metric-system measures for weight, height, temperature, and other measurements. Dosing guidelines are typically in milligrams (of drug) per kilogram (of patient’s body weight) per day, and liquid concentrations are expressed in milligrams (of drug) per milliliter (of constituted drug product). The American public, however, has not taken up the metric system, so child health providers find themselves converting weights from kilograms to pounds, and doses of liquid medicines from milliliters to teaspoons. This conversion offers opportunity for error in the communication between physicians and families. It also offers a source of error in the data that is recorded for prescriptions. Systems in an academic medical center will typically adhere carefully to metric units, but systems in community settings are more likely to store dosing guidelines and prescription records in terms of these imperial units. Merging data across sources must therefore take into account this conversion.

Compounded and Combined Medication Forms

Owing to the inability of young children to swallow pills and the impracticality of the pharmaceutical market to provide liquid forms for all conceivable drugs, a small but significant number of medications must be converted to liquid form by a compounding pharmacy. Because the formulas for these compounded medications are not standard, the records for these drugs embedded in the EHR are not standard. Even within an institution, there can be multiple instances of compounding of the same medication that make comparison of prescribing data complex. Combination preparations, where more than one drug is in a preparation, are particularly common among compounded medications. Decision suppor t aimed at one component of a combination medication may not be appropriate for the other components of the preparation, and users may be uncertain as to which component is the target of the decision support. The data model for the data in any analysis has to take these complexities into account.

Extra Requirements for Decision Support Rules

Rules put in place to guide prescribing decisions in child health need to take body mass and age into account. As with any factor that makes decision rules more complex, the maintainability of the corpus of rules quickly outstrips the ability of any organization to maintain these rules. An effective general strategy for managing this complexity remains an unsolved conundrum (Conroy et al. 2007).

5 Immunization Management

5.1 Decision Support to Determine Currency of Immunizations

While adults receive immunizations according to schedules and risk factors, the complexity of the decision-making about which immunizations to give at what time is an order of magnitude greater. This is partly due to the higher number of targeted pathogens in immunization preparations, but also to the greater number of vaccine products on the market, the changing nature of vaccine guidelines, and the complexity of the temporal reasoning required for effective immunization administration. In addition, administration rules may change over time, presenting yet another challenge for accurate decision support. Below are the guidelines for administering the rotavirus vaccine. These rules illustrate the complexity that must be supported in an information system designed to give decision support for the administration of these medications. It is also illustrates the common observation that some of the concepts used in the decision support are not computable from available data (“whenever possible,” “clinically stable”).

Rotavirus vaccine administration rules (Cortese et al. 2011)

  • For Product 1, there are three required doses, to be given at 2, 4, and 6 months.

  • For Product 2, there are two required doses, to be given at 2 and 4 months.

  • The series should be completed with the same product whenever possible.

  • The minimum age for administration of the first dose of either product is 6 weeks 0 days.

  • The maximum age for administration of the first dose of either product is 14 weeks 6 days; if this deadline is missed, the vaccine should not be administered.

  • The minimum interval between administrations of either product is 4 weeks.

  • There is no maximum interval between doses, but the maximum age for administration of the final dose of either product is 8 months and 0 days

  • Rotavirus vaccine may be give concomitantly with DTaP vaccine, HiB vaccine, IPV, hepatitis B vaccine, and pneumococcal conjugate vaccine

  • Preterm infants can be immunized at the same schedule as term infants, based on the preterm infant’s chronological (post-delivery) age. The preterm infant should be clinically stable, and should be given no earlier than the time of discharge from the neonatal intensive care unit or nursery.

5.2 Decision Support to Schedule Immunizations

The decision about what immunizations to deliver today is different from the decision about when the next doses are due. A convenient way to simplify this decision-making has evolved by way of the recommended schedule of well-child visits (Haggerty 1987). When new vaccines are introduced, their schedule conforms to this schedule in order to make it easier to administer. The rotavirus vaccine cited above, for example, conforms to the standard pattern of “well-baby checks” at 2, 4, and 6 months familiar to most parents . If a patient is able to stick to the prescribed schedule, there is little need for decision support to for what ought to be given at the visit and when to return for the next immunizations. Unfortunately, the real-life ability to adhere to this schedule is low (Selden 2006) so child-health providers are left with a great deal of decision making that they expect their information systems to help with. Only a minority of current EHRs do so (Kemper et al. 2006). This deficiency is due to the complexity of the logic required for sensible recommendations and the dependency on that logic on manually entered data.

5.3 Immunization Registries and Information Exchange

One solution to the problem of missing immunization data and recommendations for current or future doses lies in the technology of immunization registries, now more widely known as immunization information systems (IIS) (Yasuda and Medicine 2006). Because of the state-based organization of public health programs, and the state-based organization of the Medicaid program, these IIS are usually established to operate within a specific state or a region within a state. The state-based nature of these systems presents challenges to usability in populations that live near state borders. It also means that resources available to administrators of these systems are as constrained as any state-funded program (Blavin and Ormond 2011). The case for IIS is that since each patient typically receives immunizations in a variety of settings (doctors’ offices, public health clinics, immunization fairs, schools, pharmacies) a unifying system will allow all providers to make decisions about who needs immunizations, and public resources can be directed to improve immunization rates in the highest risk areas. Standards exists for the transmission of immunization information (ref: HL7 v. 2.5.1 Implementation Guide for Immunization Messaging ) but are usually customized in a way that makes interoperability between systems difficult. The U.S. federal Meaningful Use program (HHS 2009) at Stage 1 requires providers to conduct a test of data transmission to a public health agency; one choice in the menu of items aimed at this goal is the state immunization registry . While this is a far cry from requiring full interoperability , it is a step in the right direction toward encouraging the development of mature data sharing . In the meantime, providers who implement EHRs are faced with the dual challenge of getting local logic set up to support improvements in immunization rates while providing data to state IISs using manual methods and batch uploads.

6 Patient Identification

6.1 Newborn -Infant Transition

Newborn infants must be registered with a new medical record number (MRN) and a suitably distinctive name at the time of birth to allow normal clinical workflows . Typically these infants are assigned a name based on the mother’s name, as is “Boy Jane Smith” or “Jane Smith Twin A.” While the infant retains his or her MRN after this temporary name is changed to the child’s given name, the MRN remains unchanged, but clinicians tend to assign more salience to a name than to a number. This change can make it challenging to integrate information across the perinatal period, especially when the venue of care changes (e.g. from the nursery to the doctor’s office). EHRs used in the care of newborns must allow users to track patients based on either name. This is functionally similar to the tracking of adults who change their names after marriage, but in this case it happens to practically all individuals. At stake in this identification process is the newborn screen results, sent in for analysis in the first few days of life, but whose results come back to the outpatient provider well after the baby’s given name is established.

6.2 Fetal-Newborn Transition

The rise of techniques useful in the diagnosis and treatment of fetal problems presents special problems for healthcare record-keeping. Typically, patients do not receive a distinct record in the system until after they are born. Records maintained on fetal procedures are usually stored in the mother’s chart, as is appropriate at the time of the procedure. Tying the information about fetal procedures to the record of the infant after birth requires at least a linkage between the mother’s chart and the baby’s. Ideally, there should be a way to split out information from the mother’s chart into the infant’s chart, in a way that preserves the usual privacy standards (just because it is clinically appropriate for one to access one person’s chart does not mean it is appropriate to access another’s). Currently in EHR systems this kind of fine access control is not technically possible. The clinician is left with the task of manually extracting information from the mother’s chart into the baby’s, pending development of systems that take fetal care into account.

6.3 Maternal-Fetal/Infant Linking

There is one circumstance where access to one person’s chart entails some access to another’s. In newborn care, there are elements of the mother’s perinatal chart that are just as clinically relevant to the baby as the mother: Group-B Strep colonization status of the mother at birth, HIV status of the mother, medications given to the mother around the time of delivery, and so forth. While one can tie charts together in some EHR modules specifically designed for perinatal care, the movement of this information into the baby’s chart in a way that would make this information extractable for analysis or available for decision support does not exist in general purpose EHR systems. Manual abstraction or a workaround using an external system is usually what is needed to support these data functions.

6.4 Pediatric-Adult Care Linking

Another instance where charts need to be linked across venues is when a pediatric patient “graduates” to adult care (Cooley 2011). Currently, from the information system perspective, the best practice is to transmitting a subset of the clinical data in the form of a care summary using the Continuity of Care Document (CCD) format. In current technology there is no practical way to transmit the entire corpus of information on a particular patient.

7 Developmental Monitoring

A central feature of health supervision is screening for developmental delays. These delays in speech, motor function, or other abilities may indicate primary neurodevelopmental disease or be secondary to systemic disorders or socioeconomic factors. In any case, it is in the domain of the primary-care child health provider to screen for delays and to refer to needed services, like audiology, speech pathology, or neurology (ref: AAP Counc Child Disab 2006). The best practice for this activity is to use standardized developmental evaluation instruments—questionnaires—that can be filled out by the clinician or in some cases the parent . From the data perspective, the problems to be solved include how to marry parent -entered data into the medical record of the child, how to share developmental screening data for public health purposes, and how to track a very diffuse referral and follow-up process to ensure that no patients’ needs go unaddressed. In addition, most of the developmental screening tools available are proprietary, which makes widespread implementation costly if not impossible.

7.1 Newborn Screening

Another screening process performed on practically all newborns in industrialized countries is newborn screening for congenital disorders. Often called “metabolic” screening , because of the emphasis on such metabolic diseases as phenylketonuria and hypothyroidism, most newborn screening programs now include screening for hearing loss (albeit not via a blood sample). Since these programs are state-run in the U.S., each state has a slightly different panel of disorders that it screens for. Challenges in the management of data for newborn screening include correct identification of the infant as he or she changes names, correct identification of the follow-up provider, presentation of the data in a way that can be stored and acted upon, and interoperability between state databases and provider EHRs. In the current environment, there is not widely implemented technical solution for any of these problems.

7.2 Well-Child Care

Applicable Guidelines

The American Academy of Pediatrics has published recommendations for well-child care according to a schedule for many years (refs). State Medicaid programs expect that this schedule of visits (typically at birth, 1–2 weeks, 2, 4, 6, 9 and 12 months, then 15 and 18 months, then at 2 years and annually thereafter) be provided to their beneficiaries. The immunization schedule is arranged around the assumption of this schedule of visit, as are other guidelines for screening (anemia, developmental delay, lead poisoning, etc.). In addition to the timing of these visits, the AAP recommends what clinical events should occur at these visits: measurements, sensory screening , lab tests, and advice for parents . The Bright Futures guidelines (http://brightfutures.aap.org) provide more detail on the content of these visits.

Required Data

Insurers and State Medicaid agencies set standards for the content of these well-child visits. In Medicaid programs, these requirements are embodied in the Early and Periodic Screening, Diagnosis, and Treatment program (EPSDT). Audits enforce these standards, but some agencies are requiring reporting of the actual data collected in these visits, such as the records of immunizations given, screening test results, and diagnoses. A messaging standard has been developed for this reporting (ref California EPSDT format). Quality measures for pediatric primary care are built on the assumption that this schedule of well-child visits is occurring.

8 Terminology Issues in Pediatric EHRs

Like all specialized areas of health care, pediatrics uses terminology differently from other areas. While there are special terms used in patient histories and exams, those terms general live in free-text portions of the record. Terminology specializations are most obvious in the regions of the EHR that focus on diagnoses (such as a problem list, past medical/family/social history, or billing section). For a diagnostic terminology system to be usable in child health, it must:

  • Allow detailed descriptions of family historical risk factors

  • Be descriptive of specific congenital syndromes and their subtypes

  • Have detailed descriptors of anatomic anomalies that may lie outside of syndromes

  • Allow description of chromosomal anomalies

  • Describe patient behaviors that represent risk factors for undiagnosed behavioral disorders

  • Describe family stressors that may affect child health and development

  • Describe maternal conditions that affect the infant (e.g., “Maternal Group B Strep colonization”)

  • Describe developmental , educational, or anthropometric states (none of which may be a disorder per se) throughout the lifespan

9 Pediatric Quality Measurement and the EHR

Quality measurement has been an important part of EHR implementation for adult care providers for many years (McColm and Karcz 2010) but the maturity of quality measures applicable to children is far behind that of adults. Part of this is due to the fact that outside of asthma and attention deficit hyperactivity disorder , chronic disease in children consists of small populations , in contrast to the large adult populations entailing diabetes, coronary artery disease, congestive heart failure, osteoporosis, and other high-prevalence adult conditions. For these numerous smaller populations, there are few simple proxy measures available to measure outcome, as one can do with diabetes (through the hemoglobin A1c percentage blood test) or process (as one can do with osteoporosis with data on the timing of bone-density studies). Nevertheless, there is increasing interest in pediatric measures that can be extracted from EHR data (Fairbrother and Simpson 2011; Kallem 2011) and the U.S. Federal Meaningful Use program is included more pediatric measures in its Stage 2 program (CMS 2012). As with any other measure, reliable data entry is prerequisite, so any data entry outside the normal workflow of ordering procedures, receiving lab test results, or prescribing medications is apt to be invalid. Special improvement programs aimed at data collection quality would usually be necessary to get to an acceptable level of validity if clinician data collection is expected.

Most quality measures are computed from claims data, owing to claims data’s higher quality requirements as compared to EHR data. Those higher quality requirements are met in large part because the data requirements for claims are far simpler. The lack of detail in these simpler data sets fails to express the full complexity of care, so current efforts to develop more meaningful quality measures are taking EHR data into account, with some success (Angier et al. 2014; Bailey et al. 2014).

One phenomenon that tends to hamper the spread of pediatric quality measures is that all quality measures require sufficient numbers of patients to offer power to detect differences and to provide meaningful population estimates. While a large, tertiary children’s hospital, may see enough patients with, say, testicular torsion in a year to afford a decent sample of patient outcomes data, the same is not true for general hospitals and community practices. It is therefore difficult to build momentum for quality measurement for most pediatric conditions. One recent study (Berry et al. 2015) noted that even among U.S. children’s hospitals, few institutions had sufficient quantity of data to detect a drop in care quality for sickle cell disease, appendectomy, cerebrospinal fluid shunt surgery, gastroenteritis, heart surgery, and seizure of a reasonable amount over the 3-year timeframe of the study.

10 Registries and Population Management Within the EHR

The word registry can mean different things in the context of health information technology . Classically, a healthcare registry is a carefully curated set of data maintained for a specific analytical purpose, like tracking the current state of patients in a geographic region with a particular chronic disease (e.g, cystic fibrosis (Sanders et al. 2015; Sykes et al. 2016)) or undergoing a particular kind of care (e.g., surgery for congenital heart disease (Husain et al. 2014; Pasquali et al. 2014)). In this form of registry , data from the electronic health record is usually extracted, reformatted to match the definitions of the registry , and uploaded through a standardized process. With the increasing prevalence of EHR systems in physicians’ offices and hospitals, some curators of registries are crafting more direct, less expensive methods of identifying candidates for registry inclusion (Sarkar et al. 2014) or populating data directly into registries (e.g., The American Academy of Neurology’s AXON registry (Goldenberg 2015)). Extracting data directly from the EHR places a burden on clinical users to assure high data quality (Kern et al. 2006); it remains to be seen whether direct connections to these kinds registries will truly obviate the labor-intensive data-formatting process of more traditional registry data loading. Inevitable variance between the data models of the EHR and the registry may require changes in either the EHR or the registry in order to facilitate seamless loading of data from one to the other (Merrill et al. 2013).

Registry in another sense refers to functionality found within the EHR system itself, in which patients are identified as being part of a group that is managed according to a plan of monitoring and outreach (Navaneethan et al. 2011). Typically, the inclusion and exclusion of a patient in a given registry is at least in part determined by criteria recorded in the EHR as part of routine care, like diagnoses. Once in the EHR registry , data on patients’ disease state or risk stratification can be viewed to allow clinical workers to identify patients most in need of services. EHR registries typically facilitate the tracking of outreach activities (phone, email, letters, etc.) and the results of disease-modifying interventions. Decision support focused on the members of the registry can be implemented for only those patients, thereby helping to narrow alerts and reminders to the appropriate population . Because the registry provides a well defined denominator, the system can better compute meaningful measures of process and outcome, typically displayed in a dashboard-style display designed to drive clinical activities. Likewise, registry membership provides a validated way to identify populations for research studies and for the computation of metrics that require defined denominators, like immunization rates or measures of disease activity. Membership in a registry within the EHR is usually tracked with a data element (flag) that can be manipulated manually or computed from other data. Researchers using EHR data will need to use these flags to assure fidelity between clinical and research findings.

11 Conclusion/Summary

EHRs used in the care of infants, children, and adolescents must support different functionalities than systems designed for adult care. Adaptations to these systems to accommodate pediatric clinical work will affect the type of data available. Those who seek to use data from pediatric EHRs should examine how well the specialty workflow is supported by the EHR in order to be able to interpret the system’s output. Use of pediatric healthcare data for secondary uses such as quality reporting and registries must take all of these factors into account in order to be effective.