Paediatric models in motion: requirements for model-based decision support at the bedside

Abstract

Optimal paediatric pharmacotherapy is reliant on a detailed understanding of the individual patient including their developmental status and disease state as well as the pharmaceutical agents he/she is receiving for treatment or management of side effects. Our appreciation for size and maturation effects on the pharmacokinetic/pharmacodynamic (PK/PD) phenomenon has improved to the point that we can develop predictive models that permit us to individualize therapy, especially in the situation where we are monitoring drug effects or therapeutic concentrations. The growth of efforts to guide paediatric pharmacotherapy via model-based decision support necessitates a coordinated and systematic approach to ensuring reliable and robust output to caregivers that represents the current standard of care and adheres to governance imposed by the host institution or coalition responsible. Model-based systems which guide caregivers on dosing paediatric patients in a more comprehensive manner are in development at several institutions. Care must be taken that these systems provide robust guidance with the current best practice. These systems must evolve as new information becomes available and ultimately are best constructed from diverse data representing global input on demographics, ethnic / racial diversity, diet and other lifestyle factors. Multidisciplinary involvement at the project team level is key to the ultimate clinical valuation. Likewise, early engagement of clinical champions is also critical for the success of model-based tools. Adherence to regulatory requirements as well as best practices with respect to software development and testing are essential if these tools are to be used as part of the routine standard of care.

Introduction

There is a growing appreciation that pharmacometric approaches used to support drug registration, drug monograph information [1] and generalized dosing guidance can play an important role in the management of pharmacotherapy for children. In a drug development setting, modelling and simulation practices are inherently applied in a feedback loop constantly informed by further experimentation and experience. Likewise, the logical clinical utilization of such a framework is to employ a Bayesian approach reliant on the current best model with the intention of challenging model priors or indeed even the model structure as new data and clinical knowledge come to light. Ultimately, such an environment would provide a dynamic system that evolves based on the evidenced-based knowledge captured in these intelligent tools. The value for children should be obvious given both the current knowledge void that paediatric caregivers are presented with while trying to manage pharmacotherapy and the dynamic nature of particularly young children with respect to maturation and development. While much of the emphasis to date has been very pharmacokinetic (PK)-centric, pharmacodynamic (PD) and clinical outcome based response models have also been proposed [2] and are certainly the focus of several regulatory authorities (principally the FDA and EMA) [3] and the NIH [4].

Information technology (IT) is ubiquitous in the present health care industry. The electronic nature of health care information has meant quick and flexible access to data enabling health care professionals to access successfully patient records, though indeed the initial purpose of collecting patient level data was to facilitate billing. IT is constantly empowering health care providers by providing tools to more effectively care for their patients though it is clear that the primary emphasis behind the construction of electronic medical record (EMR) systems is not decision support [5,6]. The complexity of using patient information has become an increasing cause of concern among physicians and their IT vendors [7] although the potential to leverage EMR data to guide hospital practice is well appreciated [8,9]. Regulations outlined in the Health Insurance Portability and Accountability Act (HIPAA) of 1996 have contributed to concerns regarding using patient level data and represents a hurdle which must be taken into consideration when designing such systems.

This manuscript discusses current efforts and organizations engaged with the construction of models to guide patient care. A review of the critical issues involved with the construction of these models, interface with various software systems, hardware and data architecture issues as well as concerns regarding governance, testing and implementation are also provided. Emphasis is placed on models to guide paediatric pharmacotherapy and ultimately improve patient outcomes as this represents an especially challenging environment given the data scarcity and dynamics of the developing child. Experience building prototype model-based decision support tools at the Children's Hospital of Philadelphia (CHOP) is described with other collaborative efforts of similar purpose.

Methods

Current status: landscape for model-based decision support

The development of predictive models to manage drug therapy and guide medical procedures is not new though the advent of high performance computing has dramatically affected the nature and vastness of the underlying data and increased the complexity of the models that can be solved in a clinically meaningful time frame. Hence, the current environment for modelling and simulation provides an opportunity for real time processing, converting the model utility from research-based generalization to an opportunity for patient specific clinical guidance. Table 1 illustrates the diversity of patient-centred predictive models used to support an array of clinical decision making [10–16]. Table 1 is representative and certainly not exhaustive with all examples focused on clinical endpoints in adults.

Table 1.

Representative model systems used to inform patient care

Citation	Model/patient population
Chu et al. [10]	Decision support to facilitate management of patients with acute GI bleeding
Schurink et al. [11]	Bayesian decision-support system for diagnosing ventilator-associated pneumonia
Rees et al. [12]	Physiological models and decision theory to select appropriate ventilator settings
Freedman et al. [13]	Wilkoff mathematical model to assess pacemaker chronotropic response
Picchini et al. [14]	Mathematical model of the euglycaemic hyperinsulinaemic clamp
Hann et al. [15]	Cardiac model of non-linear valve law to guide ventricular interaction dynamics
Jornil et al. [16]	Dose adjustment of nortriptyline based on activity of CYP3A4 and CYP2D6

The literature is filled with many such models described in great detail but with no follow-up in clinical practice, an opportunity unfulfilled. While demonstrated to be rigorous, perhaps also shown to promote positive or prevent negative outcomes, there is no evidence of their clinical application. Hence, clinical implementation is a goal but also an important metric for establishing the clinical proof-of-concept. There are a growing number of examples where such tools that front-end (part of an algorithm responsible for collecting input in various forms from the user) predictive models are, in fact, given an opportunity to provide clinical guidance. The internet provides a forum for many of these solutions. Table 2 provides a representative listing of various web-based forums that provide guidance to clinical caregivers [17–22]. In each case the web service provides an input form from which a user can enter patient specific data and obtain the desired clinical results based on varying degrees of model sophistication from a simple close form equation to a Bayesian forecasting algorithm. In most cases there is little documentation, there is no barrier to who can access the tool and there is no requirement that the user be a trained medical professional. There may or may not be reference material explaining the calculations derived behind the scene and there are varying degrees of simple disclaimers that presumably free the developer from any liability in guidance. Of course, none of these is likely to be used in a real-time setting. There are no summaries on frequency of use provided from these web offerings. With the current emphasis on traceability of decision making it is also difficult to imagine such output is added to any hospital-based EMR system.

Table 2.

Organizations providing web-based model predictions

Host and URL	Function
	Input	Output
American Joint Committee on Cancer Melanoma Database http://www.melanomaprognosis.org/Predictiontools.aspx	Enter patient characteristics (demographics, pathological questions)	Predicts 1, 2, 5 and 10 year survival rates from initial diagnosis (with 95% CI) for an individual patient.
Massachusetts General Hospital [17] http://www.massgeneral.org/about/pressrelease.aspx?id=1189	Medical history of patient experiencing ischaemic stroke; underwent brain scans	RRE-90 score (risk of having another stroke within 3 months by looking at stroke risk factors, such as history of mini-stroke, or TIA, age and type of first stroke experienced along with information from brain scans.
Archimedes Quantifying Healthcare http://archimedesmodel.com/indigo	Patient's laboratory results, diagnoses, medications, measurements and risk factors such as smoking and family history extracted from electronic sources (e.g. EHRs, data warehouses, or disease registries).	Individualized guidelines include person-specific risk of adverse events (e.g. heart attack, stroke, diabetes onset) and predicted health impact of interventions (e.g. medications / lifestyle changes to reduce risk.
PeraTrend for Pediatrics by PeraHealth http://www.perahealth.com/solutions/pediatric-collaborative/ PeraTrend is fully integrated with Epic, Cerner, Allscripts and McKesson	Patient's vital and laboratory data through the patent-protected Rothman Index.	Generates a graphical score that shows a patient's trended condition. Rothman Index can flag patient deterioration much earlier, facilitating a wide range of possible interventions and care options.
Pediatric Dose Calculator v1.2 http://www.rubbermallet.com/pedform.html	Patient's demographics and haemoglobin data.	Dosages for common anaesthetic agents, vital signs, tube sizes, fluid requirements and emergency drug dosages.
Mayo Clinic [19,20,22] http://www.mayoclinic.org/gi-rst/mayomodel1.html http://www.mayoclinic.org/gi-rst/mayomodel2.html http://www.mayoclinic.org/gi-rst/mayomodel3.html http://www.mayoclinic.org/gi-rst/mayomodel4.html http://www.mayoclinic.org/gi-rst/mayomodel10.html	Patient's laboratory results, diagnoses, medications, measurements, demographics.	Individualized natural history predictions for various liver diseases.
Warfarin Dosing Guidance supported by the Barnes-Jewish Hospital at Washington University Medical Center, the NIH, and donations [18] http://www.warfarindosing.org/Source/Home.aspx	Patient's demographics, relevant comedications, target and actual INR, genetic information (e.g., VCORC1 and CYP 2C9 genotype), liver disease and smoking status	Individualized, estimated dose to achieve target INR
Limoges University Hospital and Inserm Transplantation / Nephrotic Syndrome Patients [21] https://pharmaco.chu-limoges.fr/	Patient's demographics and PK data.	Output: Dosages for common MPA, CsA and tacrolimus via Bayesian forecasting routine and PK report.

CsA, ciclosporin A; INR, International Normalized Ratio; MPA, mycophenolic acid; VCORC1, Vitamin K epoxide reductase complex subunit 1.

Finally, with respect to hospital-based EMR decision support, there are indeed efforts on this front that merit interest. Many of these rely on prediction engines available within the EMR systems themselves and are mostly focused on providing caregivers with guidelines derived from and/or through EMRs [8,23,24]. Likewise, while they may appear limited with respect to computing power and functionality, such computational tools are not warranted in many cases. This is mainly because any requirement for complex modelling is usually handled outside of the production environment during model development. In the implementation stage, the focus is on prediction and even rigorous Bayesian forecasting models can be utilized without much computational overhead. The broader challenge is dealing with ‘big data’ (generally refers to data sets so large and complex that it becomes difficult to process using basic database management tools or traditional data processing applications; exobyte data sets, 10¹⁸ bytes). Typically, these systems are transactional-based with data archival managed to keep the system responsive. An important aspect of the new generation of model-based tools is the ability to drill-down longitudinally within a patient's history or across patients perhaps over years of data collection as would be the occasion for rare diseases or infrequent medication utilization.

Environmental challenges

Regulatory considerations

One concern that typically arises during the development of model-based tools is the regulatory concern over such applications. This continues to be a topic of great interest and confusion. Most importantly, it is one of the primary reasons that many ideas and actual research efforts are stopped prior to the completion of a final product for implementation. In the US, the question is generally focused on the extent to which the FDA needs to review these tools and whether they constitute a device. FDA's Center for Devices and Radiological Health (CDRH) is responsible for regulating firms who manufacture, repackage, relabel, and/or import medical devices sold in the United States. Medical devices are classified into Class I, II and III. Regulatory control increases from Class I to Class III. The device classification regulation defines the regulatory requirements for a general device type. Most Class I devices are exempt from Premarket Notification 510(k), most Class II devices require Premarket Notification 510(k) and most Class III devices require Premarket Approval. Classification is risk based with the risk the device poses to the patient and/or the user the major factor in determining the assigned class. Class I includes devices with the lowest risk and Class III includes those with the greatest risk.

Regarding the designation of a product as a device, the FDA website provides the following guidance regarding the classification of devices (http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/Overview/ClassifyYourDevice/ucm051512.htm):

If a product is labelled, promoted or used in a manner that meets the following definition in section 201(h) of the Federal Food Drug & Cosmetic (FD&C) Act it will be regulated by the Food and Drug Administration (FDA) as a medical device and is subject to premarketing and post-marketing regulatory controls. A device is:

‘an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:

• recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them,

• intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or

• intended to affect the structure or any function of the body of man or other animals, and which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes.

While the FDA has classified and described over 1700 distinct types of devices and organized them in the CFR into 16 medical specialty ‘panels’ such as Cardiovascular devices or Ear, Nose, and Throat devices, none of these relate to software solutions per se.

In Europe, EU legislation is also focused on the contention that software constitutes a medical device (http://ec.europa.eu/health/medical-devices/documents/index_en.htm) with the most recent 2007 amendment stating that software intended for medical purposes could be classified as a medical device. The excerpt from the regulations states the following:

‘medical device’ means any instrument, apparatus, appliance, software, material or other article, whether used alone or in combination, together with any accessories, including the software intended by its manu facturer to be used specifically for diagnostic and/or therapeutic purposes and necessary for its proper application, intended by the manufacturer to be used for human beings for the purpose of:

– diagnosis, prevention, monitoring, treatment or alleviation of disease,

– diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap,

– investigation, replacement or modification of the anatomy or of a physiological process,

– control of conception, and which does not achieve its principal intended action in or on the human body by pharmacological, immunological or metabolic means, but which may be assisted in its function by such means;

While there is no collective clarity here, there is no precedent either. For the paediatric in-patient setting, there is an implicit reliance on the governance regarding the use of medicines that is defined within a particular institution (e.g. Drug use evaluation and therapeutics standards committees or equivalent groups). This is well appreciated within the American Academy of Pediatrics through the Child Health Informatics Center (http://www2.aap.org/informatics/chic.html) and likely the broader international paediatric community as well.

Security and patient privacy

Security rules outlined in HIPAA require organizations that handle electronic health data to implement measures for controlling access to confidential medical information and protecting it against compromise and misuse. Integrated model-based decision support systems must therefore make every effort to ensure the protection of human subjects, as mandated by HIPAA. A separate Institutional Review Board (IRB) application is most likely required. At CHOP, IRB approval for our paediatric knowledge base (PKB) effort [25] was granted in 2005 and has since been renewed annually. As part of the IRB, all the members of the investigative team are required to complete the Collaborative Institutional Training Initiative (CITI) program, web based training for the protection of human subjects in research. The program is an institutionally driven course curriculum with user-friendly presentation modules and assessment tools. Each member of our team also completed a ‘potential conflict of interest form’ as instructed by our IRB. Hence, all reasonable precautionary steps were taken to protect the privacy and safety of the paediatric patients involved even at the planning and prototyping stage. It should be noted that the IRB approval is required for the research phase of the project only. Once the Therapeutics Standards Committee has approved the production version of the dashboard solution and successful production qualification has been completed, IRB review is no longer required.

One of the primary issues when working with patient data is the ability to de-identify records even during the prototype development. For the most part, this is easily accomplished by stripping the patient medical record number from the analysis dataset but birth date must also be removed. This can be accomplished after the calculation of elapsed age is performed. Data are stored only on secure, password-protected systems and accessed only by authorized personnel via user profile meta-data. This would also seem to be reasonable for web-based technologies as well when sharing the results of pooled EMR data. The Children's Hospital Corporation of America's (CHCA) data model used in the Pediatric Health Information System (PHIS) has similar controls in place (http://www.chca.com/index_flash.html).

Project design

Planning: scoping, team and governance

Project team composition is an essential element that drives the likelihood of project success. The PKB project team at CHOP was comprised of clinical, computational, pharmacometric, data management, programming, system architecture and quality assurance expertise. The efforts of the team were overseen by a steering committee that provided guidance with respect to clinical benefit, drug dashboard prioritization and the integration with the hospital EMR. A paediatric critical care physician and board-certified clinical pharmacologist and paediatrician, headed the Steering Committee which included the head of the IRB as well. The Steering Committee also included members from the pharmacy, IT and clinical pharmacology departments as well as hospital administration. The Steering Committee served as the project advocates for the PKB team during the presentation of the individual dashboards to the hospital Therapeutics Standards Committee (TSC) that has ultimate jurisdiction over the hospital formulary and the institution-specific drug and dosing guidance.

Figure 1 provides a schematic illustrating the idealized project team composition and governance for a model-based decision support system interfaced to an EMR system. It illustrates both the workflows, interaction between governing bodies and feedback to the project team. Project scoping prior to the definition of functional requirements is a critical first step and acknowledges the role of the clinician champion to speak for the eventual end-user community ensuring that tool functionality meets the needs of the target audience as well as the look and feel of the system including ease of operation. While there is an opportunity to educate caregivers on clinical pharmacologic principles, this cannot dictate the design of a system whose ultimate goal is to deliver pharmacotherapy guidance.

Figure 1.

Project team composition and organizational interface with governance infrastructure and workflow for development

Evaluation

Process: benchmarks, end-user satisfaction, validation

In order to ensure accuracy, quality and maintenance as well as complete coverage of the user requirements and compliance with federal regulatory policies of HIPAA and 21-CFR Part-11, user acceptance sign-off following formal system and user acceptance testing is essential. Our method for ensuring the quality and requirement completeness of PKB is via continuous process quality assurance embedded in each step of the development process coupled with a comprehensive acceptance and validation testing phase at the end of development.

Key process steps include:

• Development of formal user test cases from requirements

• Development of unit test and system test cases with each design specification

• Categorization of test cases into ‘Critical’ or ‘Nice to have’

• Development and maintenance of requirements traceability matrix

• Integrating unit testing with source code development

• Versioning source code and build packages to ensure consistency of software releases

• Iterative integration/deployment cycles to detect software defects early in the development phase

• Regression testing with every new point release (Note, in this context regression testing refers to the identification of software bugs, or ‘regressions’, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes have been made).

Key steps for acceptance and validation testing include:

• Test design, test plan and test case development

• Validation plan and identification of required documentation

• Review and approval by project team

• Test case execution and documentation of test results

• Defect reporting and retest results

• Issue of final testing and validation report

• User training

• Bug tracking and reporting on production usage

To fulfill the user testing phase, it is essential to identify a small user test group that collectively spans the full range of functionality with each user focusing on a specific area or sub-component of the larger system. A formal test design and test plan is first developed, reviewed and approved by the project sponsor and IT leaders of the project. In addition, a validation plan identifying required documents to support the effort will need to be developed and approved in collaboration with the QA and validation group. Once all approvals are in place, detailed test cases can be developed to cover functionality, as well as a separate set of test cases developed to cover issues arising from 21-CFR Part-11 compliance and HIPAA requirements. The resulting test cases will again be reviewed and approved by the user community and IT leaders as well as the project sponsors and stakeholders. Once all approvals are in place the testing and operational environments can be prepared with required documentation and signoffs.

Actual testing is executed by one or more persons (from end user and IT personnel) who are not part of the development team. The conduct of the tests is carried out in an isolated and qualified environment and audited by an outside reviewer, typically by a member from the QA or validation team. Qualification of the environment and application installation are verified by signed documentation identifying the events captured. Each test is marked ‘pass’ or ‘fail’ and a defect report produced. Any defects identified are subsequently corrected, repackaged and retested until all critical test cases have passed, ensuring reliable operation. Tests categorized as ‘Nice to have’ will not be required to ‘pass’ as long as acceptable work-around procedures can be identified to achieve the same result. After testing is complete, a final testing and validation report is issued before deploying the system into production. Documents can be archived and made available for review by internal and external audit personnel.

A key step in ensuring proper use of a newly deployed application is user training. User training is required of all users before granting access to the system. Evidence of satisfactory training and achievement scores should also be maintained. And finally, a bug-tracking system to track and report errors in production or improper usage should be instituted to monitor ongoing performance for quality improvements and identifying areas requiring additional training.

Implementation: production, maintenance, life cycle management

The operational and clinical performance and impact of the model-based decision support can be assessed by capturing utilization including physician acceptance measures and changes in prescribing practices relative to baseline. Questionnaires can be used to get direct feedback from the user community (prior to and post-launch). This should allow an assessment of the usability of the system and the critical data defining the path of decision making. Such data will have impact on the efficiency of current therapeutic practices relative to patient outcomes, the pharmacoeconomics of the formulary and an independent measure of patient safety based on pharmacotherapeutic intervention.

Periodic reports that summarize the usage of the system (# users, # site hits, duration of usage, etc.) can assist with the program maintenance as well as the life cycle management. By examining changes in drug utilization of targeted agents (e.g. individual drug dashboards) at finite time windows relative to baseline (pre-deployment), we can examine the effectiveness (or not) of the system. Specific dosing guidance provided by caregivers utilizing these model-based decision support tools relative to prescribing habits dictated by the standard of care (formulary) can easily be assessed relative to outcomes. Finally, surveying the end-user community, from which we can assess user friendliness, user satisfaction and perceived clinical benefit will drive satisfaction with the tools and ultimately dictate their value. This implicitly recognizes that teams exist as part of a long term commitment and evolve as necessary to changes in the underlying science (PK/PD knowledge, etc), practice and user feedback.

Results

The CHOP experience

We have been developing a PKB at CHOP in attempt to personalize paediatric pharmacotherapy by leveraging our EMR system. Such a platform would be able to: (1) provide dosing guidance consistent with formulary standard of care, (2) examine patient pharmacotherapeutic indices with respect to individual agent performance relative to historical controls derived from the hospital data warehouse, (3) explore treatment, diagnoses, drug correlation in conjunction with utilization and (4) educate physicians on clinical pharmacologic principles specific to population and drug combinations of interest. Static compendial information (Lexi-Comp, Physician's Desk Reference, etc) can be searched, indexed and summarized for easy viewing. Forecasting of relevant drug exposure or clinical markers (laboratory values, pharmacodynamics, adverse events) is made available in the ‘Drug dashboard’ modules. This concept has been discussed previously [25].

Two prototype dashboards (methotrexate and tacrolimus) have been constructed following the previously discussed paradigms although clinical validation has not been completed. Table 3 shows the general agreement between drug attributes and desired functionality for each dashboard developed by the project team from the initial scoping phase. Forecasting tools permit dosing scenarios to be explored via a user-friendly interface that front-ends a paediatric population-based PK/PD model. The model represents the current, best description of the dose–exposure relationship. The forecasting routine relies on the population priors in a Bayesian context to predict future events influenced by individual patient data. While there is no functionality at present to incorporate artificial intelligence into the system, the computational framework is there to do this if desired. Mock-up screens were developed largely from the feedback of the clinical champions and the end-user community. The details of the methotrexate model [26] and dashboard performance [27] have been previously presented. Supplemental materials (Table S1 and Figure S1) provide examples of the source materials used during the methotrexate dashboard prototype qualification. Tacrolimus is an immunosuppressive drug that is used after allogenic organ transplant to reduce the activity of the patient's immune system, thereby reducing the risk of organ rejection. The need for guidance in dosing tacrolimus is critical given the high variability in tacrolimus pharmacokinetics [28–30] in children making it difficult to predict what drug concentration will be achieved from a given dose adjustment. It has a narrow therapeutic window with a great need to avoid toxicities at higher concentrations and prevent rejection at lower concentrations [28]. The incidence of toxicity is 45% at plasma concentrations > 15 μg l⁻¹ with a 30% incidence of acute rejection at concentrations < 5 μg l⁻¹. Our initial prototype tacrolimus dashboard was constructed through collaboration with the nephrology department though future versions of the dashboard are planned to extend across transplant type and thus will be reliant on multiple paediatric population PK models.

Table 3.

Alignment of drug attributes with initial desired dashboard functionality for methotrexate and tacrolimus prototypes developed at CHOP

	Drug characteristics	Dashboard functionality
Methotrexate	• Anti-folate chemotherapeutic agent	• Views and predictions of:
	• Renal excretion; enterohepatic recirculation	– MTX concentrations, creatinine clearance
	• Toxicity at high or prolonged low exposure	– Time to reach threshold plasma concentration
	• Therapeutic failure at prolonged low exposure	• Guidance for dose titration
	• Highly variable PK	• Diagnosis of delayed MTX clearance due to acute nephrotoxicity
	• Patients receive MTX based on one of several CHOP / COG protocols	• Rescue therapy guidance
	• TDM guided adjustment
Tacrolimus	• Inhibits IL-2-dependant T cell activation; multiple transplant settings	• Provide predictions of:
	• Variable PK	– TAC concentrations
	• Wide range of oral doses (1–44 mg day−1) to maintain trough levels of 5–20 μg l−1	– Liver function
	• Toxicities related to exposure include nephro and neurotoxicity, infection and lymphoproliferative disease with over-immunosuppression	– Adjustments to maintain threshold plasma concentration
	• TDM: 12 h trough concentration	• Guidance for dose titration
		• Avoid toxicities at high levels; prevent rejection at low levels:
		– 45% toxicity incidence > 15 μg l−1
		– 30% incidence of acute rejection < 5 μg l−1

Figure 2 shows screen captures of the tacrolimus dashboard's view to clinical signs (laboratory values) that the clinician user has deemed essential to guide therapy including tacrolimus plasma concentrations. Historical data within and across patient subgroups (e.g. age, transplant type, bodyweight) can also be viewed. The dashboard also permits forecasting of plasma concentrations at select time points consistent with specific clinical protocols used to both limit and manage toxicity. The current dashboard prototype pulls in data directly from the EHRs. Annotation of ‘other’ events is possible however and the system captures the date/time stamp so that the audit trail can be maintained. The forecasting tool permits dosing scenarios to be explored via a user-friendly interface that front-ends a paediatric population-based PK model based on data collected from paediatric renal transplant patients.

Figure 2.

Screen captures of prototype tarcrolimus dashboard showing (A) overlays of tacrolimus concentration with user-selected biomarkers , TAC; , SRCR; , ALT and (B) concentration–time course relative to dose adjustments and the occurrence of adverse events. , TAC; , DOSE; , CLIN_EVENT

Other initiatives

It is hoped that a compilation of dashboards for a broader, global PKB will be possible through external collaborations. Such a strategy may be possible through a secure, web-based environment that accumulates relevant paediatric data in a secure, HIPAA-compliant informatics system. Similar work has been initiated at Cincinnati Children's Hospital [31,32], Seattle Children's Hospital [33], Uppsala University Hospital [34–36] and Children's Mercy Hospital [37] with others soon to follow. Equivalent work in adults has been initiated by many and the longstanding work of Dr Roger Jelliffe [38–40] is being continued by Dr Michael Neely [41] and soon to produce the next generation of model-guided dose individualization tools. Other web-based prediction tools focused on dosing requirements are under development by Drs Bruce Green (http://www.doseme.com) and Nick Holford (http://www.firstdose.org and http://www.nextdose.org). This review is not exhaustive as it most certainly does not capture early efforts where public knowledge is not as well informed or where proprietary issues are a concern. Nonetheless, it illustrates the global recognition of the effort as well as the basis for the approach.

Discussion

The promise of personalized medicine is to be able to deliver individualized pharmacotherapy to patients in a manner that recognizes their unique physical characteristics and disease status and acknowledges the various therapies, procedures and other medicines that are a part of a patient's past and current treatment plan. This ideal would seem to be best accommodated by personalized health records that maintain patient data in an analysis-ready format that is automated to project patient response to treatment and future outcomes based on the input of new data in real time. Such a system does not currently exist but it is hardly science fiction even today.

Children stand to benefit the most from such an environment and decision support system. They still represent an understudied population and are always likely to lag behind adults with respect to clinical investigation and availability of drug experience. Their growth and development present a challenge for dosing but one in which great strides have been made to accommodate enzyme ontogeny [42,43], maturation [44] and developmental [45,46] considerations. The greatest barriers to designing and implementing such tools and systems have little to do with clinical pharmacology, pharmacometrics or therapeutics. Poor application designs excluding the caregiver end-users, lack of multidisciplinary teams, lack of governance around the project planning and life cycle management and the social dynamics of patient care represent the ultimate challenges to development and actual implementation.

Regarding the importance of multidisciplinary teams, Collins et al. [47] provide an excellent example of the necessity of developed ‘tools’ to communicate with various team members and the failures associated with ignoring this involvement in the planning and design. Positive examples, team engagement, good communication and transparency are essential to ensure user acceptance and overall project success [24]. This has been our experience as well and will be critical to achieve the broader goal of engaging the global community to invest in the shared, systematic development of drug dashboards, that front-end model-based decision support systems.

While recent emphasis has been placed on EMR-interfaced designs, it may well be that web-based, hosted systems reliant on cloud solutions are more reliable and easier to manage. Data from pilot web-based systems are encouraging in terms of utilization [48] and education/adherence to guidelines [48]. There have been good examples where EMR-based solutions were transitioned to web-based platforms [49,50]. Several computerized physician order entry/clinical decision support (CPOE/CDS) systems have been implemented with great success and the review of longstanding systems [51] illustrates common practices which are consistent with the planning and design discussed herein. If we simply connect drug databases to EMRs [52], we will underachieve. A transparent, model-based environment that evolves based on evidence-based results is indeed a challenge but a worthy goal, especially when the governance of such a system pushes us to challenge the status quo. While the future of such systems may benefit from the input of patients and family to improve the quality of the underlying data further improving outcomes [53], it will also put a further burden on well-designed and governed systems. The collective wisdom of paediatric clinical pharmacologists, caregivers and IT specialists would be well served by this task.

Competing Interests

Dr Barrett, as the sole author, has completed the Unified Competing Interest form at http://www.icmje.org/coi_disclosure.pdf (available on request from the corresponding author) and declares no support from any organization for the submitted work, no financial relationships with any organizations that might have an interest in the submitted work in the previous 3 years and no other relationships or activities that could appear to have influenced the submitted work. His salary was supported in part by the NIH challenge grant, 1RC1LM010367-01, ‘Decision Support System to Guide Pediatric Pharmacotherapy’.

Supporting Information

Additional Supporting Information may be found in the online version of this article at the publisher's web-site: