Background

Active and proposed regulation including the Merit Based Incentive Payment System (MIPS), Meaningful Use guidelines, Physician Quality Reporting System (PQRS), and Imaging 3.0 radiology initiatives [1,2,3] are changing the practice of radiology and creating a demand for data driven decision making to prove value. In the past, radiology struggled to implement quality mandates like PQRS given the lack of generalizable outcome measures within radiology [4]. The new MIPS program combines PQRS, payment modifier, and electronic health record (EHR) program into a single program against which eligible health care providers are evaluated.

In an attempt to comply with regulation and avoid payment penalties, several initiatives are being developed and implemented including providing guidance on appropriate requests for radiology tests using the American College of Radiology (ACR) Appropriateness criteria, quality control during performance of a study (including contrast and radiation dose management), and improving the radiology report (using multimedia reports with embedded radiology images, structured reporting and reporting decision support tools like the ACR assist™) [5]. Additionally, registries have been identified to be crucial to support radiology practices to show value. For example, to receive compensation for computed tomography lung cancer screening, providers must submit data to the lung cancer screening registry, thus linking payment to quality monitoring [6].

Multiple registries exist across radiology. For example, the ACR coordinates the RADPEER® and Dose Index Registry (DIR) as well as several others housed under the National Radiology Data Registry [7]. Given high levels of variability in the radiology report structure, unique codes are utilized to link the finalized report to the registry and prompt data extraction. Moreover, these registries are based on a set of specified structured data that can only be updated with a new release of the registry software. Participation in ACR registries has been a voluntary opt-in basis, until the introduction of lung cancer screening with CT, where registry participation is a requirement. This new requirement underscores the importance of the ability to create new informatics tools to support participation in national registries. This article describes a new methodology of registry design that minimizes the barrier to organize clinical data into useful information to derive knowledge using clinical registries. Our approach is mirrored along the daily workflow of radiology practices integrating structured reports, standardized dictionaries, and multidisciplinary governance by integrating a learning registry that mirrors and supplements the radiology workflow.

Methods

Needs Assessment/Functional Specification

Our department has a well established program for treating patients with primary liver cancer and hepatic metastatic disease using Yttrium 90 radioembolization (RE) with over 1000 RE treatments having been administered. We selected the interventional radiology section to serve as our pilot center for this project given the section’s eagerness to set up an interventional oncology registry for patients treated with RE. An existing Excel™ based registry quickly became insufficient to support thousands of patients with multiple data points, changing data needs, supporting data entry by multiple users, report queries, and expansion to collect longitudinal patient records.

A team led by the Director of Interventional Oncology (DIO) and Director of Informatics was constituted to lead the registry efforts. We mapped the workflow of patients in the department from point of referral, including the number and type/purpose of subsequent visits. We also reviewed several radiology reports to extract data elements captured at every visit. We then conducted a literature review of landmark studies on use of RE for cancer treatment specifically reviewing the methodology and result section of published literature [8].

These data were used to populate our data collection schema and to develop data entry forms. At the end of this step, we had a total of five forms that represented every patient visit type including initial encounter, planning arteriography encounter, RE encounter, return visit, and an event form to collect data on incidental events like patient admission. All data elements on the paper forms were reviewed by a terminology specialist from Intelligent Medical Objects [9], an organization providing interface terminology linking clinical language and coding systems for accuracy and appropriateness.

Our specification document addressed required functionality, data sources, form mappings, and registry use cases for research and Interventional Oncology (IO) program quality improvement.

Platform Selection

Based on our functional specifications, we reviewed several options including existing Excel™ database, Redcap™, and a vendor system provided by the research department. Our search found two main classes of registry solutions, one where software is provided as a service (e.g., the ACR hosted registries) and software platforms that allow customization and self-hosting of the registries. We were interested in a solution that was customizable and hence preferentially selected open source solutions for our pilot. For each solution, we evaluated the open source license terms, main programming language, a community of users to support our implementation, availability and documentation of integration end points, and date of last software update.

Based on our functional specification document, our system of choice needed to support management of controlled terminology/common data elements, form management, messaging including Health Level 7 (HL7) capability, and RESTful application program interface (API) to support programmatic access and integration. We searched for open source registry repositories on Github™ and publications referencing open source software to create a list of potential options for use. We opted to use a registry platform that would allow us to be flexible in meeting the needs of our users. This flexibility was not provided by the ACR registry system that collects disease and task specific data like dose information. For example, in our case of Y90 RE, we wanted to determine the clinical predictors of overall survival including laboratory, RE distribution, and clinical staging. Moreover, a subsequent registry implementation-expansion project was focused on collaboration between the interventional radiologist department and the gastroenterologists to track outcomes of transjugular intrahepatic portosystemic shunt (TIPSS) among patients with end-stage liver disease.

We selected an open source platform called OpenMRS® (http://openmrs.org) that has been previously used as a global health medical record system. The base platform provided basic HL7 functionality, patient registration and patient matching functionality, and form creation tools based on Xforms and HTML. The platform provides a RESTful (Representational State Transfer) interface for programming, integration, and extension of existing functionality. OpenMRS is a Java application with a MySQL database (with option for PostgreSQL database). OpenMRS is a vibrant open-source project supported by a robust, mature developer community. Clinical data are saved as individual rows in a single-observation table which provides flexibility for future coded concept updates, as well as native support for longitudinal records.

Configuration

As a starting point, we used the Columbia International eHealth Laboratory (CIEL) interface terminology dictionary. The CIEL dictionary is mapped to various standard terminologies including ICD-10, SNOMED CT, LOINC, and RxNORM. We augmented CIEL with RADLEX terms and completed mapping of our forms to the terminology service. We had developed common data elements required for data collection based on our clinical workflow. These were mapped to the CIEL interface terminology. For example, a search of Y90 (Fig. 1) shows three concepts that can be used to capture the Y90 activity, the Y90 procedure report, and a convenient set to capture artery and segment injected and Y90 activity (Fig. 2). Using our fixed terminology, we generated a form schema (Fig. 3) for each of our five encounter forms. The form schema is made using a form curation tool that allows you to search for common data elements in the registry represented as a tree with main nodes and sub nodes based on data to be collected. The form schema was imported into the Xforms tool which parses the form schema using xml into web components like textboxes, checkboxes that allow for visual improvements to be made before completing form design. Automated calculations to improve data integrity were incorporated into the form authoring system including calculations of the Barcelona Clinic Liver Cancer (BCLC) stage and Child’s Pugh Score. Field type validation, date validation, and mandatory fields were used to ensure quality of collected data.

Fig. 1
figure 1

Screenshot of the CIEL interface terminology search for Y90 common data elements to begin generating a form schema

Full size image
Fig. 2
figure 2

Screenshot demonstrating the detailed appearance of a selected concept/data element. In this example, the view is for a convenient set that allows grouped data collection of artery injected, segment injected and Y90 activity during RE procedure

Full size image
Fig. 3
figure 3

Form schema for the initial encounter form with tree of common data elements to be captured during data collection

Full size image

Using the OpenMRS locale functionality, we were able to support American styles for dates, addresses, and medical record numbers. An estimated investment of 48 h was used to set up this system to support patient registration and data entry using created forms. (Fig. 4). We created two options for extracting data from the registry system. One option provides preconfigured reports for example, number of patients aggregated by their status of alive or dead (Fig. 5). The second reporting interface allows users to generate combination queries for data extraction, for example query for all patients with bilirubin values below a specified threshold (Fig. 6). We developed a module that allowed us to use our institution’s active directory single sign-on for user authentication. User authorization was performed by assigning each user a role within OpenMRS. Users unknown to OpenMRS were denied access to the system.

Fig. 4
figure 4

Patient dashboard with a list of all forms available for data collection and previously saved data

Full size image
Fig. 5
figure 5

Reporting option supporting pre-configured report generation. In this example, a user selects to view the number of days a patient has been in treatment and the number of RE treatments received

Full size image
Fig. 6
figure 6

Reporting option that supports user queries. In this example, the user is performing a query of number of dead patients with a BCLC stage of C. Possible options are linked to the form schema and concept dictionary used for forms. Users can perform queries without any SQL or programming skills

Full size image

Distribution

Given modular architecture of the registry, we packaged the registry into a development platform using puppet and vagrant and automated the above steps. This code is provided under an open-source Mozilla Public License with detailed documentation on getting started available at https://github.com/judywawira/openmrs-vagrant-puppet. This simplified the process of implementation after developing functional requirements. We host the project on github where a user can access the platform to get started with the system using a single command (‘vagrant up’) after cloning the repository.

Registry Pilot

Once the technical development was completed, we implemented a pilot registry to track the RE patients. Ethical approval to support research from the registry was obtained from the Institutional Review Board (IRB protocol ID 1210009841). Working with the IT department managing the infrastructure for the radiology enterprise, we were allocated a server running a Linux-based system. The registry committee and the security team completed the HIPAA paperwork requirements and set up backup protocols.

We selected a sub cohort of patients with cholangiocarcinoma and metastatic colorectal cancer for the pilot. The first step involved migration of these patients from the existing Excel registry, with concurrent collection of any missing data from the electronic medical record and Picture Archiving and Communication System (PACS).

Results

Table 1 summarizes our evaluation of open-source platforms for registry management. The United Kingdom (UK) renal registry provided one of the best models of successful registry deployment. The registry is used in 71 adult and 13 pediatric renal centers and is mandated by the National Health Service National Service Specification. The python-based system provides comprehensive data collection and reporting tools for renal disease from diagnosis, monitoring, vascular access, and complications. Moreover, the registry has a strong community support with organized national meetings to discuss research data.

Table 1 Summary table of open-source platforms available for deployment/customization including source code, license type, community support, and date of last code update
Full size table

From our implementation of a customized function of OpenMRS, we have two outputs, a general purpose registry platform and a pilot implementation. Our registry is distributed as an open-source project with basic informatics functionality including an interface terminology, patient registration, HL7 and FHIR capability, reporting functionality, form authorship tools, and modular architecture to support platform customization. The registry data model supports expansion of data collection as all data elements are saved in single rows as observations. In the early months of the implementation, we focused on RE patients. We subsequently expanded the same registry by extending the cohort feature and grouping visits to collect outcome data on patients who have transjugular intrahepatic portosystemic shunt (TIPSS) placement for management of portal hypertension. Since we had all our common data elements in the system, the addition of the second cohort only required forms configuration and report generation without a need to deploy a new instance of the system with new HIPAA paperwork. Our registry now tracks 202 patients treated with RE and 182 TIPSS patients as of 30 January 2017. In a qualitative review of the usability of the platform, we report ease of use due to single sign on integration with improved user management.

We conduct monthly data quality reviews, where we identify missing fields and need for additional data collection. As the forms are version controlled by the platform, we are able to update forms without interfering with the collected data. This approach allows for rapid expansion of the registry to meet new use cases. To support prospective data entry, we have incorporated standardized reporting based on the registry forms that will populate the registry automatically on batch processing of all generated radiology reports every night.

Discussion

As the demand for proving value in radiology continues to increase, there is a critical role of implementing registries that mirror our workflow. Traditionally, the radiology systems run parallel to other systems in the health care enterprise due to the difference in workflow. At our institution, documentation occurs in the PACS system whereby procedure reports are dictated and saved to an accession number with zero images. We had multiple data needs to document outcomes for interventional radiology procedures at different time points and hence needed a flexible registry system with minimal overhead cost for maintenance and setup, as well as a streamlined workflow that did not increase burden of data collection for our providers. The open-source registry systems reviewed were either disease specific, for example focused on comprehensive data tools for diabetes or renal disease. Based on our functional specification document, these systems would not be applicable for our needs.

Our platform choice allowed for integration of multiple applications as open web apps, common data elements, form design and versioning, and cohort tools that allows us to dynamically meet new needs for data tracking with the same infrastructure. Using a single database, we are tracking two cohorts of patients treated with RE and TIPSS. Since we mirror the structured reporting templates used for dictation of radiology reports, we do not have to rely on extra additional support to deal with a new workflow for data entry to the registry. The platform design now allows us to work on the next phase of the project to integrate natural language processing to automatically populate the registry after reports are signed off. This new functionality will support our future plans to provide just in time decision support to enrich the registry data.

Radiology remains at the core of multidisciplinary care, and hence functional requirements gathering and specifications provide a strategy for the radiology department to take ownership of tracking patient outcomes. National registries such as the ACR have a critical role in securing the future of radiology especially when linked to payment like in the case of CT-lung cancer screening. However, there is still a role of local institution based registries that can be responsive to the immediate needs for assessing patient outcomes without immense pressure for new infrastructure and management of multiple systems. For the future, medicine needs to build registries that allow for real-time assessment of care delivery and outcomes as detailed in the National Radiation Oncology Registry [10]. We believe that a structured-registry platform, built on open-source technology with flexible architecture is required to be a leader in clinical care and research in the future. Our pilot experience was well received by users collecting data as well as radiologists using the structured templates.

We recognize that a current limitation is implementation of this platform at a single institution. We cannot therefore generalize the application of the database across multiple institutions with different workflows. We welcome other institutions to join in open-source development of our platform and further refinement of terminologies important to radiology by downloading our platform.

Conclusion

Imaging registries built based on clinical workflows support better data generation and secondary data use for evaluating clinical outcomes, facilitate research, and enable compliance with regulation guidelines like MIPS and PQRS from a single system while reducing the overhead of maintenance of multiple single purpose registries. Such registries require a development platform supporting with terminology support, form management, reporting, interoperability (HL7 or FHIR enabled), and a flexible data model that allows for changes without corrupting existing stored data. As radiology evolves to value based care, the need to continuously measure performance across multiple systems will increase. Designing scalable clinically driven registries with flexible customizations can reduce the burden of data collection to support quality assessment, research, and real-time monitoring.