Numerous sources of clinical, research, and administrative data exist across paediatric cardiovascular medicine, but are in a constant state of creation, transformation, and disappearance – for example, a physician studying a certain patient subgroup may carefully collect data from patients meeting specific criteria, and then build a detailed spreadsheet saved on a single PC not accessible to others studying the same patient group. Similarly, detailed data submitted to national registries may be difficult to organise and integrate with other important data for research at the very centre that submitted it. A dedicated computer in regular use in a clinical area may hold valuable patient data without any automated connection to the electronic health record or any ability to browse its contents. An inventory of procedures kept in a medical device can be lost or rendered obsolete after an “upgrade”.
In many congenital heart centres not one but all of these unfortunate situations unfold simultaneously. Data sit in disconnected “silos”, resulting in clinical, administrative, and research activities that may be duplicative, inefficient, and at times inaccurate. The electronic health record, despite its costs and complexity, is not able to easily adapt to local circumstances or aggregate data across sources for these purposes. With this in mind, our congenital heart centre set out in 2010 to construct a unified system to facilitate data capture, integration, and analysis. The purpose of this review was to describe our methodology, key considerations, and successful use cases. The lessons learnt may be useful for other heart centres and programmes outside paediatric cardiology as well.
Methods
Overall goals
The overall goals of the project were to better capture and integrate information across the congenital heart centre to support efficient clinical, research, quality improvement, and administrative activities. This included the following: integrating information from separate existing data sets (for example, clinical patient logs, local clinical registry data collected for submission to national data sets, research data sets, the electronic health record, etc.); creating a web-based application consisting of modules for each clinical subsection or user group to facilitate capture and aggregation of data not available in existing sources; streamlining data entry and automating common searches and reports; providing “super-users” the capability to query all data sets; and adopting an established nomenclature and diagnostic coding structure across the heart centre.
Data are integrated within an overall congenital heart centre data warehouse (Fig 1). Tables 1 and 2 display important preliminary steps and keys to success in establishing a comprehensive congenital heart centre data solution, and the details are discussed in the following sections.
Structure of the heart center data system.
Preliminary steps to establishing a congenital heart centre data solution.
Keys to success.
Personnel and funding
Beginning in 2010, a database team was formed involving collaboration of the Pediatric Cardiology, Cardiac Surgery, and School of Information faculty at the University of Michigan. School of Information students working with collaborating faculty also participate in the project and play a key role in data programming activities as a part of their degree work and also as part-time employees. The development team currently consists of two part-time programme developers who are graduate students at the School of Information. In addition, three physician advisors and two research data specialists also attend weekly work meetings. Financial support for the project is provided by a combination of funds from the Departments of Pediatrics and Cardiac Surgery, Division of Pediatric Cardiology, research grants, and philanthropic funds.
Creation of the web-based application
In order to facilitate routine capture, integration, and analysis of data not captured elsewhere or previously housed in isolated data sets, we developed a novel web-based application that interacts with the overall congenital heart centre data warehouse (Fig 1). The goal was to provide an intuitive platform for standardised data entry and access, linkable to other data sets by key fields.
The project proceeded with sequential migration of individual data sets – previously kept in stand-alone spreadsheets, paper logbooks, Microsoft Access databases, etc. – to the integrated platform. “Module” was the term used for the data solution for a single clinical group or area within the congenital heart centre. New modules were also created in areas where there were no existing data sets. Although the “modules” were initially one-off applications launched from a common URL in the first version, the programming team designed a modular structure that leverages reusable, adaptive software components to quickly develop new modules that utilise common processes.
It was recognised that the optimal source of data was often the clinical provider whose time and patience for data entry tasks were limited. Therefore, wherever possible, the programming team aimed to keep constant or reduce clinician effort required for their previous workflow. The application is interfaced with the electronic health record to allow auto-population of demographic and other fields in order to avoid duplicate data entry.
Standardised nomenclature is an essential aspect of paediatric cardiology, and the International Paediatric and Congenital Cardiac CodeReference Franklin, Jacobs and Krogmann 1 was selected, as it is in common use, is publicly distributed in related long and short lists, contains diagnoses, procedures, and complications, and addresses cardiac abnormalities with a practical but not exhaustive granularity.
The web application is written in ASP.net, with data primarily in Oracle. Data are either primarily stored in the data warehouse’s dedicated server, locally batch copied, to optimise performance, from certain linked sources such as the electronic health record, or accessed from linked systems. Early versions of the database had a conventional relational structure. This was subsequently converted to the entity-attribute-value data model, which stores each data entry transaction in a single large table,Reference Chen, Nadkarni, Marenco, Levin, Erdos and Miller 2 and allows for greater ease in expansion and modification of saved elements, essential to keep up with the rapidly changing academic clinical environment. All elements in the database are catalogued and can be displayed in a data dictionary, which itemises their source, data type, and expected range of values. Where possible, data elements conform to accepted terms and definitions.Reference Anderson, Weintraub and Radford 3
Querying capabilities and data extraction
The web-based application provides a rich data reporting function to support the generation of standard reports that need to be routinely prepared. Data fields to be included and the report format can be easily customised. The system can also automatically generate the reports and e-mail them to the requesting clinical group on a defined schedule. A multi-field search is also integrated in the web application, displaying results on screen with an option to export to common spreadsheet formats. In addition, a Google-like, free-text search engine is available to users; this allows the catheterisation team, for example, to search for mention of the word “stent” or for a specific device in all reports. Finally, data analysts or “super-users” may query the data tables independent of the web application. This allows more complex searches involving multiple data sets to be incorporated in the congenital heart centre data warehouse – for example, searches across local clinical registry data, the web application, and the electronic health record, etc.; Figure 1.
Backup, safety, and privacy
Security and privacy are of utmost concern when creating a data solution for a clinical environment, and were carefully addressed from the project’s outset. Creation and modification of data are comprehensively logged in the system, allowing auditing and recovery in the event of loss of data – for example, accidental deletion. Each clinical or user group only has access to their specific module; access to the modules belonging to other groups must be requested and approved. Institutional review board approval was obtained for the administrative operations of the data system. Individual research or quality improvement projects using the data require separate approvals. Accessing the system requires the same level of password authentication as that required for using the electronic health record. The system is deployed in servers residing behind the institutional firewall, with remote access permitted through encrypted virtual private network tunnels. Backup of the application and data to an off-site facility is performed routinely at 15-minute intervals.
Results
At present, the web-based application consists of 10 integrated modules serving different areas of the congenital heart centre: cardiac MRI, echocardiography, Holter monitoring, electrophysiology, cardiac catheterisation, neurodevelopment outcomes, surgical longitudinal follow-up, transplant, extracorporeal membrane oxygenation, and fetal cardiology. As described in the preceding sections, the application is also integrated with local clinical registry data collected for submission to national data sets, research data sets, the electronic health record, and health system data warehouse (Fig 1).
Each module has a dedicated user interface, although all modules have a similar “look and feel”. Content and complexity vary depending on user needs and workflow (Fig 2). In certain modules, the majority of data presented to the user are automatically obtained from other sources. The catheterisation laboratory component, for example, displays a chronological catalogue of cases with linked procedure notes and data from the haemodynamic recording system; users enter and confirm only a small number of fields related to complications and procedure classifications, to assist quality improvement activities. In other clinical modules, the majority of fields are user-entered.
Selected examples of user interface; (a) Fetal module, with maternal and fetal data combined for a given pregnancy, accommodating multiple gestations and joining fetal data to a medical record number once born; (b) Neurodevelopmental follow-up module showing one one assessment scale; (c) Holter monitor physician worklist showing unverified reports for the current user.
Use cases
Cardiac MRI
The cardiac MRI group – consisting of two physicians – historically maintained a log of performed studies and pertinent data for clinical, research, and administrative purposes. This was entirely physician-entered data and was originally housed in Microsoft Access on a single computer. The database team selected this data set to be the first of the overall project. It was convenient to begin by meeting the needs of just two users, and the physician leads were willing to provide feedback about the new platform. As this first module developed, there were several early programming challenges. As each was overcome, however, users gained new capabilities. The MRI data were accessible from any computer, at offices, home, MRI suite, etc., data entry effort was decreased as the link to electronic health record automatically imported all demographics and the final MRI report, and a reporting function was created such that annual case volumes and other relevant data could be more efficiently reported when needed. In addition, data analysts were able to integrate data from the MRI module with, for example, local data from our local surgical registry for research projects. Development of this initial module established the “look and feel” of the application for all future users. The MRI module remains the tracker of case volumes and trends, a useful browsing tool for longitudinal comparisons, and the source for identification of cases for retrospective research.
Ambulatory electrocardiography (Holter)
For more than a decade at our centre, 24-hour electrocardiographic recordings (Holter monitors) had been reported using an application written by a local clinician. Advantages of this initial application were that it was designed around our centre’s particular workflow, and provided both clinical reporting and a database of all Holter reports dating back years. It also transmitted finished reports reliably to the electronic health record; however, it necessitated installation of a client programme on users’ desktops, which was inconvenient and became incompatible with modern Windows (Microsoft Inc., Seattle, Washington, United States of America) operating systems.
The essence of the previous application was preserved in a re-written version on the web-based platform. New features – physician reminders, a work queue for readers, display of electrocardiogram images, and billing summaries – were added. Diagnostic coding was standardised to the International Pediatric and Congenital Cardiac Code used elsewhere in the system. The resultant application was not only more suitable for search, administrative functions, and research but also resulted in faster turnaround of Holter reports, from a mean of 17–9 days (Fig 3).
Turnaround time of Holter monitor result from order to report completion 2 years before, 1 year before and after the implementation of the Holter database module. The y-axis represents mean number of days from order to signed Holter report. Data are presented as mean ±SEM.
Surgical longitudinal follow-up programme
Our centre recently incorporated annual follow-up with families and collection of patient-/parent-reported outcomes data into routine care, in order to improve our understanding of longer-term outcomes and quality of life in children undergoing congenital heart surgery. The programme initially involved contacting patients undergoing any of the “benchmark” operations defined by the Society of Thoracic Surgeons by phone on an annual basis.Reference Jacobs, O’Brien and Pasquali 4
Nevertheless, as the number of eligible patients continued to grow, it was recognised that it would be difficult to maintain phone follow-up as the primary mechanism of communication. In addition, many families expressed preference for communication by e-mail. A module was created in order to address these needs including interoperability with baseline surgical registry data and the electronic health record, collection of patient/parent e-mail addresses to support electronic communication, and collection of the longitudinal follow-up data. The module is populated on a daily basis with census data from the electronic health record. This provides an easily searchable listing of admitted patients for care coordinators who discuss the programme with hospitalised patients and families and collect information on their preference for contact by phone or e-mail. The module is also integrated with our local surgical registry data in order to use this standardised information to identify eligible patients who have undergone one of the benchmark operations, and to facilitate future analyses incorporating both the baseline surgical information and the longitudinal follow-up information. The data entry portion of the module allows easy entry of the longitudinal follow-up data by the programme coordinator, as well as the option to send out a secure link to annual surveys for families preferring to communicate via e-mail.
Since this programme began in January, 2015, we have successfully collected information on nearly 1000 patients undergoing surgery since 2010. Additional work being done in collaboration with the Children’s Hospital of Philadelphia and private IT partners aims to further automate the process. This use case demonstrates the value of integrating information across existing data sets, as well as the value of the web-based platform in supporting efficient data collection.
Fetal cardiology
In fetal cardiology, the medical records of fetal “patients” exist in the mother’s chart. It is valuable to be able to connect the fetus to its postnatal medical record when possible, whether a single fetus or multiple gestation, and whether related to the mother’s first or a subsequent pregnancy. In order to address these needs, the fetal module was created to include related tables of mothers, pregnancies, and fetuses, and it includes a tool to assign fetal records to medical record numbers for all pregnancies that have reached term. Users select patients to be added from a display of the day’s fetal echo schedule, and as in other modules full-text searching of the reports is possible and data fields requiring user entry are limited to those unavailable in the electronic health record. Ongoing practical uses of the module include the following: automatic generation of a weekly list of planned deliveries and known fetal patients for on-call physicians; summary statistics for administrative purposes; tracking of discrepancies between fetal and postnatal studies; and organisation of data submissions to a national fetal registry.
Discussion
We have presented a summary of the methodology, key considerations, successful use cases, and lessons learnt in developing an integrated data platform to serve our congenital heart centre. It is an example of one viable solution to the needs not met by the electronic health record alone, or other pre-existing resources in the academic environment.
With the increasing volume of data now collected in numerous sources in paediatric cardiovascular medicine, it has become necessary to develop better mechanisms to integrate and analyse this information in order to best utilise these data to support clinical, research, quality improvement, and administrative activities.Reference Pasquali, Jacobs and Farber 5 Within the research realm in particular, this has been recognised as an area in need of attention and innovation across centres, and the National Heart, Lung, and Blood Institute recently sponsored a working group that discussed the development of a strategic vision to support an integrated data network for CHD research.Reference Pasquali, Jacobs and Farber 5 In addition, the Pediatric Heart Network has also recently formed the Integrated CARdiac Data and Outcomes Collaborative, which aims to leverage available data sources to aid in efficiently planning, implementing, and conducting studies across the spectrum of clinical investigation; support more widespread data standardisation, integration, and sharing across sites and data sources to conduct collaborative research not possible within isolated data “silos”; and mentor young investigators in these areas.
Nevertheless, multi-centre efforts will not succeed without strong local data capture, management, and integration capabilities. These local solutions will likely require active engagement of heart centre resources and personnel. System-wide electronic health records are not the ideal data solution; they are primarily designed to show clinicians information on one patient at a time, changes to their systems are generally time consuming and expensive, and data extraction capabilities are limited.Reference Weng, Appelbaum and Hripcsak 6 In addition, the limitations of the International Classification of Diseases system regarding CHD diagnoses and procedure codes, and lack of standardised definitions in the electronic health record for other important variables, such as complications, etc., are additional important limitations in the CHD population.Reference Pasquali, Peterson and Jacobs 7 Thus, the capture and integration of more granular clinical data are necessary. As evidenced by our experience, collaboration with experts in the information technology and data science fields is critical in designing efficient, flexible, and user-friendly systems.
Finally, local data systems will also need to incorporate newer sources of important data. These include real-time monitor and sensor data, genetic and biomarker data, as well as patient-reported outcomes and data obtained through social media and mobile technology, among others.Reference Schumacher, Stringer and Donohue 8 , Reference Sullivan and Fairchild 9 Flexibility in data platforms to support integration, analytics, and real-time reporting of these types of data will be important as data systems continue to evolve.
Conclusion
An integrated congenital heart centre data system is achievable and can foster efficient clinical, research, quality improvement, and administrative activities. Collaboration between clinicians and data scientists is key, and mechanisms to support flexibility and expansion are critical in ensuring that the platform can not only meet the needs of today but also the challenges of the future as the volume of paediatric cardiovascular data continues to expand.
Acknowledgements
The authors would like to acknowledge the contributions of the M-CHORD research team and students in the Health Informatics program at the University of Michigan in the development of this data solution.
Financial Support
This research received no specific grant from any funding agency or from commercial or not-for-profit sectors.
Conflicts of Interest
None.
