Skip to main content
Journal of Digital Imaging logoLink to Journal of Digital Imaging
. 2014 Jan 17;27(3):331–336. doi: 10.1007/s10278-013-9668-6

REST Enabling the Report Template Library

Brad W Genereaux 1,, Don K Dennison 2
PMCID: PMC4026468  PMID: 24435562

Abstract

Structured reporting, created when a standardized template with organized subheadings is combined with relevant observations of a diagnostic study into a meaningful result, has the potential to raise both the quality and the predictability of the radiologist report, revolutionizing the workflow and its outcomes. These templates contain great value, as they carve a path based on best practice for the radiologist to follow, and thus should be shared, reviewed, and improved. Unfortunately, these templates are often not shareable today due to a lack of standards for describing and transporting templates. This paper outlines and discusses an appropriate and effective electronic method for transporting radiology report templates using of the style of representational state transfer (REST). Enabling a structured radiology report template library with REST enables just-in-time accessibility of templates, achieving efficiencies and effectiveness.

Keywords: REST, Ontologies, Structured, Reporting

Background

Many initiatives have been undertaken to drive better quality with diagnostic reports. One complaint amongst referring physicians is that the same set of diagnostic images can be reviewed and reported upon by multiple radiologists, which can result in substantive differences in reporting style, quality, and interpretation [1]. Structured reports and their accompanying templates have arisen as a possible solution to this problem. Standardizing the way reports are written allows for higher quality and more predictable documents regardless of author. For example, a patient can have the same diagnostic examination read by multiple radiologists and have reports written that all follow the same structure and format [2].

Structured reports are created by completing a template with relevant observations from the performed examination. These templates become valuable as they evolve over use and transform into reporting best practices for their respective domains. Great value can be realized from sharing these templates with others and, from this, to form international reporting template best practices.

The Radiological Society of North America (RSNA) reporting initiative created an online library of standardized structured report templates, called RadReport [3]. This library publishes templates across many examination types and modalities that are peer reviewed by experts worldwide. The intent is to allow interested parties to download and incorporate these templates into their own diagnostic study reporting applications. On its own, this service is quite powerful—but it can be taken even further by allowing systems to interact directly with these templates. With the rise of web technology and frameworks, styles such as representational state transfer (REST) [4] become an effective mechanism for this exchange, one that can be harnessed to achieve rapid adoption of structured reporting templates. This paper will explore, through the creation of a prototype that consumes the REST-enabled service, the strengths of this approach. This prototype simulates the reporting workflow and does not receive dynamic orders or save completed results, nor at any time did it connect into a live clinical environment.

Methods

A prototype has been created to demonstrate the possibilities of consuming a structured report template library. The model for this prototype follows the service-oriented architecture (SOA) framework, consisting of a server actor and a client actor. The server actor receives requests and provides results. RSNA’s RadReport service fulfills the role of the server, by providing a REST query interface [5], based upon API industry best practices [6]. This allows clients to query and consume radiology report templates. See Table 1 for a list of some of the most common templates queried for. Requests are made by providing criteria as query parameters. Matching templates are returned as a list in JavaScript object notation (JSON) format [7]. The client actor requests information and receives results; this role is fulfilled by the prototype.

Table 1.

Most common RadReport radiology report templates downloaded, up to May 23, 2013

Template Views
CR – chest X-ray 12,321
CT – brain 9,613
US – abdomen 8,661
MG – digital mammography 6,993
CR – chest X-ray (2 views) 6,420
MR – knee 6,079
MR – brain 5,775
MR – spine 5,492
CT – chest pulmonary embolism 5,387
CR – abdomen complete 5,035

For the prototype, or any application, to include the RadReport REST service, it must meet the following criteria:

  • Be able to communicate (directly or indirectly) with the template REST service over standard network infrastructure and protocols.

  • Be able to build and make a standard web request.

  • Know how to parse the response, available in JavaScript object notation (JSON), to understand what templates are available.

  • Implement logic to download and process the template in regular language for XML next generation (RELAX NG) [8] format.

For most development frameworks, standard libraries are available to facilitate making web requests and understanding standard formats.

The primary steps in using the REST service are discovering, retrieving, and rendering the templates. Discovery of templates is done by querying the REST service, demonstrated in Fig. 1, with a query for hip templates. The service returns matching templates in JSON format. Each response includes a uniform resource locator (URL) link to download the template. By following this link, the template can be downloaded, opened, and parsed. For the hip example, Fig. 2 shows a portion of the XML of the hip x-ray template that was downloaded. The portion showing is from the Findings section of the template. Figure 3 shows a rendering of the hip x-ray template rendered in the prototype and has been annotated to show how fields are referenced to respective ontologies.

Fig. 1.

Fig. 1

Query/JSON response portion of all hip x-ray templates

Fig. 2.

Fig. 2

Portion of RELAX NG XML showing Findings section of a hip x-ray report template [9]

Fig. 3.

Fig. 3

Prototype screenshot showing rendering of Findings section of a hip x-ray report template

From a radiologist perspective, the impact of using this prototype in a structured reporting environment should not deviate from their usual workflow. The radiologist selects an examination for reading, and the system determines the most appropriate report template to download and render for completion. This would not be any different if the template was in their local environment or located remotely. The radiologist would complete the report and submit it to their reporting system for further workflow.

Where the process deviates, however, is on an architectural level. This prototype simulates the typical view of a radiologist worklist of examinations waiting to be reported. See Fig. 4 for an outline of the communication workflow. First, the radiologist opens a particular exam (1). For the purposes of the prototype, static mock examinations with anonymized patient demographic information are used, as it was not connected into a live clinical system. By providing study specific metadata that does not identify the patient (2), the prototype learns about available templates (3) and makes the best selection of a template to be completed. Alternative templates can be selected should several meet the criteria.

Fig. 4.

Fig. 4

Contextual flow of a client–server radiology report template request

Once a template is selected, it is requested, by its unique identifier, via the REST interface (4), downloaded (5), merged with any relevant study information, and rendered to the user (6). The template itself is formatted as RELAX NG XML, which describes the various data sections and elements within these sections. The data sections and controls indicated by the XML are instantiated as HTML5 standard controls (such as text fields and checkboxes). From here, a radiologist is able to complete the template with data derived from reviewing a study, and the results become a report document, such as a clinical document architecture (CDA) report that can be stored into a clinical document repository. The prototype simulates storing the report but does not actually connect into a live clinical system.

From a technical perspective, this prototype is a web application built atop a hypertext markup language (HTML) and JavaScript client platform, compatible with a reasonable set of modern Internet browsers, that simulates pulling anonymized diagnostic examinations from a database. No nonstandard plug-ins or standalone installations are used on the client. The prototype uses populated clinical data to formulate queries for templates into the RadReport template library service, communicating via REST using a standard JavaScript library called jQuery. A JSON with padding (JSONP) proxy service is added to the solution, used only to allay restrictions caused by same origin policy.

Results

The prototype demonstrates the benefits of using REST-based approach. By leveraging a web-based framework, the prototype simulates the radiologist drawing from expert-approved templates at the time of query, in real time. When a template is updated on the RadReport website, the changes are reflected in the prototype the very next time a report is generated.

By increasing the availability of templates into an organization and into reporting workflow, it should have the added effect of promoting consistency for the report stakeholders, as well as increase the opportunity to index them by their ontological references. In receiving consistent reports, referring physicians will be reassured that patients they send for exams will be reported upon with the same scrutiny and best practices every time, enabling them to better compare results across time, disease, and patient. Healthcare organizations with a stronger ability to index reports can better understand and serve their patient population.

Discussion

Many approaches are available for providing a rich service for systems to access templates. One such framework is the architectural style of REST, which offers a lightweight standardized approach to providing results. REST is actively being pursued through various standards bodies and defined standards, including:

  • Digital imaging and communications in medicine (DICOM)
    • •Web access to DICOM persistent objects by means of RESTful services (WADO-RS)
    • •Store over the web by means of RESTful services (STOW-RS)
    • •Query based on ID for DICOM objects by means of RESTful services (QIDO-RS)
  • Health level 7 (HL7)
    • •Fast healthcare interoperable resources (FHIR)
  • Integrating the healthcare enterprise (IHE)
    • •Mobile access to health documents (MHD)

REST is a set of guidelines and restrictions that utilize internationally recognized standards that describe how communication between systems flow, without specifically dictating the format of the result.

Through the use of a REST-based service with structured report templates as resources, consumers of this service are able to enjoy many benefits, including:

  • Real-time discovery. When an examination has been completed on a patient, reporting software can automatically discover and extract the most relevant and up-to-date approved template, using the study description and modality as criteria. Only the most recent version of a selected template is available. If more than one template is discovered, each can be listed for the reporting radiologist to choose among, ranked based on criteria such as popularity, past usage, or with the help of additional metadata.

  • Select synchronization. Templates can also be synchronized between a reporting system and the centrally managed repository, not only for offline use but also to allow hospital administrators to choose which ones are best appropriate for their particular institutions and to allow for any additional site customizations. In order for this to be implemented, administrative features would have to be added in the reporting software to give department managers this ability. It would include, for example, manual synchronization of templates, differential reviews of changes between versions, site-based localizations (both clinically, like additional reporting fields, and administratively, like site logos), and approval functionality. Updates to templates can be detected by comparing the “date modified” value of a downloaded template and the template available online. Specifically for RadReport.org, the website used by this paper’s prototype, any changes made to downloaded templates cannot be published back via the API; rather, changes are submitted through a related site, called Radiology Report Exchange [10].

  • Traceability. Reports that refer back to the original template allow quality assurance personnel to ensure and demonstrate that they are conforming to industry best practices, even as the templates evolve and as new procedures and modalities are introduced.

  • Collaboration. Allowing experts to develop templates in their own realm of expertise and share them to the greater healthcare community drives continuous quality improvement. Experts can use feedback from their colleagues, locally and internationally, to improve the templates for a variety of purposes, including clinical efficacy, clarity, and better understanding population health. A REST platform provides the facilities with the ability not only to query and retrieve templates but to also create, modify, and delete them, if administrators allow it.

  • Pre-population. Templates that have ontological hooks, such as RadLex or SNOMED CT, have the increased ability to pre-populate content based on other artifacts in the diagnostic examination. Refer to Fig. 3 to see, for example, how RadLex codes are manifested. This allows reporting systems to perform merges of this data into the report, reducing manual transcription errors. Information can be gathered from an HL7 transaction, such as patient demographics, ordered examinations, reasons for examination, ordering physician information, and more. Information from DICOM objects could include measurements from a structured report, and date and time of image acquisition.

  • Post-processing. Further to pre-population, by utilizing standards rooted in ontologies, templates can help to facilitate better mining of data in a normalized fashion, reducing the need for natural language processing. These terms can then be grouped, rolled up, and abstracted for a more holistic, cross-sectional view of radiology report data.

  • Portability. Templates can be moved to other systems, when the need arises. For example, when the reporting system is upgraded or replaced, templates may need to be exported from the previous system and imported into the new system. Also, if the radiologist moves to a new healthcare organization and wishes to take their templates with them, this REST-based service can support that. Also, interacting with templates need not be done on the typical reporting client; they can be used on mobile tablets or other computing devices, should the need arise.

  • Seamless integration. Existing tools, such as dictation and transcription services that leverage speech to text, should function in the same way. Individual software applications that perform this service may need to adjust their program for the new style of template but otherwise should not be affected.

There are a number of caveats to consider when implementing this type of technology. Institutions may want to review and approve templates from a regional or national repository before considering them for use in their local environment. If a live repository is used, contingencies should be in place for when the network is temporarily unavailable; scenarios where radiologists are unable to report at all should be mitigated. With these considerations in mind, controls can be put into place whereby templates are locally cached to a location where network uptime is more predictable and content can be controlled and approved before use. A REST-based framework provides for an acceptable experience with these controls. Furthermore, one of the challenges associated with the prototype described above, requiring the use of JSONP to prevent same origin policy violations, would be mitigated by a local cache of templates, queried in the same manner. An alternative to a local cache and JSONP is to use an emerging browser standard called cross origin resource sharing (CORS).

Outside of REST, a number of other methods and frameworks can provide a similar level of functionality. Specifically, simple object access protocol (SOAP) is a common method of sharing content across a local area network (such as a private hospital network), by allowing interactions with remote objects via method calls. Because of bulky payloads, SOAP is less suited for wide area network deployments, such as the Internet. REST, on the other hand, is a resource-based framework adept at the handling of templates, providing the methods to query, retrieve, and store in a standard, intuitive way. Aside from SOAP, other methods, such as proprietary ones, could potentially work, but by not following a standards-based framework, these would be more complicated for integrators to leverage.

With regard specifically to the prototype developed for the analysis above, the next steps for an interested party are to implement it into their own clinical workflow and radiologist reporting tools. From there, a sample of radiologists can be consulted on the relevancy of using such reporting templates in their workflow, as compared to their existing tools.

Since 2012, IHE has been developing a profile called management of radiology report templates (MRRT) [11], which is approved for trial implementation at their Connectathon event in 2014. It formalizes the structure and the transport of radiology templates and defines effective use cases for the use of this profile. It uses a REST-based interface to allow for querying, retrieving, and storing templates. Templates themselves are built on a blended HTML5–XML structure. If adopted, template accessibility should be enhanced, enabling the benefits discussed.

Conclusion

By utilizing the principles afforded through REST and the advancements of web technologies and frameworks, the delivery and embedding of structured report templates is closer to being within reach of adoption. It will enable those in the radiological field to seamlessly include these templates—templates that have been reviewed and approved by experts in best practice—into their own applications, and strengthen the delivery of results to those who have ordered the examinations. This can lead to better or more solid patient care and can yield better outcomes at a lower cost. By following this framework, and as report templates, best practices, and technology evolve, the notion of sharing these templates will become ever more prevalent and will benefit those who adopt them.

Contributor Information

Brad W. Genereaux, Email: brad.genereaux@agfa.com

Don K. Dennison, Email: don@dondennison.com

References


Articles from Journal of Digital Imaging are provided here courtesy of Springer

RESOURCES