THE MEDICAL IMAGING RESOURCE CENTER (MIRC)1 is the product of a Radiological Society of North America (RSNA)-sponsored initiative to enable medical institutions to share their digital educational and research content (images, text, and multimedia) by creating a distributed repository accessible from the Internet. The MIRC community consists of independent sites, “MIRClettes,” located at institutions worldwide. Each site can act as a “storage service,” by hosting the content to be shared; as a “query service,” by providing a user interface (usually a Web page) for performing a broadcast query of storage services selected by the user; or as both a query service and a storage service. Technical documentation on MIRC can be found on the RSNA MIRC site at: http://mirc.rsna.org/ .

A query service can interrogate a storage service in one of two ways. The first method is used when a storage service is a Web server with static content. In this situation an XML (extensible markup language)2 document called a “MIRCsiteindex” is generated by one of the tools available from the RSNA MIRC site. This document contains a searchable index of the content hosted by the storage service’s Web server. The document is then stored on the query service and is used when servicing any queries directed at the storage service.

Figure 1
figure 1

MIRC query/storage service architecture.

Full size image

The second query mechanism, illustrated in Fig 1, permits a query service to retrieve a dynamic index of a storage service’s content. This approach is most appropriate for database-driven storage services, such as the teaching file described in this article, and involves building a software layer, called a query interface, on top of the existing site to communicate with the query service. Communication between the query and storage services consists of the exchange of XML documents. The process begins with the user specifying a set of query criteria such as key words, age, gender, or image format.

This is usually done through a Web form such as the one pictured in Figure 2. Upon submission of this form, the query service sends each selected storage service a “MIRCquery” XML document via HTTP (hypertext transfer protocol) POST.3 The MIRCquery document contains the query criteria specified by the user. When the storage service receives the MIRCquery document it parses the contents, performs a search of its own database, and, using the same HTTP connection, sends back a “MIRCqueryresult” document. The MIRCqueryresult document contains descriptors, such as a title, abstract, and URL, for the content matching the specified search criteria. After receiving MIRCqueryresult documents from all the storage services, the query service collates the results and lists them in a Web page that it presents to the user (see Fig 3). The user then clicks on the link associated with each entry in the list to view the associated content (usually the full teaching file or research case). It is important to note that these links direct the user to the storage service itself; none of the content is hosted on the query service. Consequently links can point to any type of document that can be delivered via HTTP. Document types commonly used for education or research purposes include HTML pages, PDF files, Microsoft PowerPoint presentations, and DICOM or TIFF images.

Figure 2
figure 2

MIRC query page.

Full size image
Figure 3
figure 3

MIRC search results page.

Full size image

MATERIALS AND METHODS

This article describes the authors’ experience with implementing a storage service front end for the University of California San Francisco (UCSF) Department of Radiology’s electronic teaching file. One unique aspect of the UCSF teaching file is its close integration with the clinical PACS.4 Input of all new content takes place at the PACS display station using an embedded Web page. Images are entered using the PACS vendor’s “summary series” feature, which permits a radiologist to specify the key images within a study as well as the optimal presentation settings such as window/level and mirror/rotation values. Once a summary series has been created, the images within it are transmitted via DICOM to the teaching file server where they are converted to JPEG images using the specified presentation values. Having the images in JPEG format facilitates Web distribution because all major Web browsers support the display of JPEG images without requiring the user to install additional software. Because of its close integration with the radiologist’s workflow, the teaching file system is now used by all the sections within the department, and has completely replaced film-based teaching files. Approximately 12,000 distinct cases have been entered since the system first became operational in 1998.

The database engine underlying the teaching file is the 4th Dimension (4D) RDBMS (relational database management system) (4D Inc., San Jose, CA). It contains a built-in Web server used to provide access to the teaching file system from the Internet. 4D also contains an extensive scripting language that permits developers to create complete applications around the database engine. Additionally, 4D supports the use of “plug-ins,” software packages created by third-party developers, which extend the capabilities of the scripting language. Because 4D currently lacks built-in support for XML, the “Expat4D”5 plug-in was used to create the query interface. Expat4D is a free plug-in based on the open source, event driven, XML parser “Expat.” Expat4D was responsible for parsing the incoming MIRCquery documents to extract the search criteria used to query the database.

RESULTS

A working implementation of the interface required only 3 days of development time, with refinements taking place over several months. Most of that time was spent on three tasks. The first was mapping the MIRC query document elements to the teaching-file database schema. This process required very little time because most of the data elements were common to both systems and those that were not could be safely ignored according to the MIRC specification.

The next task, which required most of the initial three-day development time, was translating the MIRCquery document into the database’s internal query language. Because, the teaching file possessed its own Web front-end for performing queries against the database, it was decided the underlying code could be reused with appropriate modifications to handle a MIRC query. Fortunately the Boolean query syntax used by MIRC is very similar to the query syntax used to search the teaching file from its own Web interface, which meant that only slight modifications to the existing code were required.

The final issue, which was resolved over the months subsequent to the initial implementation, was the need to anonymize cases. Radiologists at UCSF extensively use patient identifiers, such as patient name, medical record number, or visit number, to access teaching files. These identifiers are then stored with a teaching file when it is created. In addition, radiologists occasionally entered patient identifiers into some of the free text fields such as the case narrative. To ensure HIPAA (Health Information Portability and Accountability Act) compliance, all access to the system is password protected and uses SSL (secure socket layer) encryption. Only individuals directly associated with the Department of Radiology at UCSF are given access, and all activity is logged and monitored. Because the teaching-file system did not initially support the ability to deliver fully anonymous data, a demo system containing 83 fully anonymized teaching file cases was used as a test bed. Flags were then added to the teaching-file schema to indicate whether a teaching file author wished to make a case available to MIRC and has therefore removed all patient identifiers from the free text fields of the teaching file.

DISCUSSION

MIRC’s reliance on HTTP and XML greatly reduced development time by allowing the author to use existing software components when building the network piece of the interface. Mapping of the MIRC XML documents to the storage service’s database schema was straightforward because both shared most of the same data definitions. Most of the development effort was spent mapping MIRC’s query syntax to the database engine’s internal query language and establishing safeguards for protecting patient identifiers.

Occasional updates to the initial interface were required to accommodate the evolving schemas of the MIRCquery and MIRCqueryresult documents. In response to feedback from the radiology community, the schemas of the original MIRC XML documents were expanded to include such fields as ACR codes, degree of difficulty, as well as the ability to designate a teaching file as public or private. A private teaching file is one that requires additional credentials, usually a user name and password, to access. Features the authors hope will be added in future versions of MIRC include the ability to rank search results based on query relevance as well as a single sign-on to access private cases.

CONCLUSION

This project has demonstrated the feasibility of implementing a MIRC interface on an existing teaching file server. Development of such an interface was aided by MIRC’s utilization of both XML and HTTP. The use of these two widely accepted standards allows a developer to leverage existing software tools when building a MIRC query interface, thereby lowering the barrier to entry into the MIRC community. Additionally, even though the XML schemas of the documents used by MIRC have stabilized, implementers must be willing to make changes to their MIRC interface, as MIRC is likely to continue to evolve over the next couple of years. For those sites without established teaching-file systems, MIRC intends to provide software to allow authors to upload their content to a storage service run by the RSNA. This should permit a multitude of sites with a variety of content to participate in MIRC, thus increasing the value of MIRC to the radiology community.