Clinical Transaction Repository EMR

This article lacks information on the notability of the subject matter.
Please help improve this article by providing context for a general audience, especially in the lead section.

This article or section may contain original research or unverified claims.
Please improve the article by adding references. See the talk page for details. (September 2007)

First, what is meant by Clinical Transaction Repository (CTR) and how does it differ from a Clinical Data Repository (CDR)? A CTR stores transactions while a CDR stores results.

Additional recommended knowledge

Safe Weighing Range Ensures Accurate Results

Guide to balance cleaning: 8 simple steps

Weighing the right way

Transactions are captured by “listening” to the HL-7 stream from ancillary systems and capturing transactions to a database much like in a CDR. A simple CTR captures only those transactions with a result, e.g. finalized radiology report or completed lab test. A more complex CTR will store other transactions that do not have a "result" associated with them such as an ordered lab test or ordered medication. These transactions are captured because knowledge that a lab test or medication has been ordered is useful to care providers.

The CTR stores transactions in a database that "point to" the location of the result (report) of the transaction. Listed below is a record in the CTR database that demonstrates the simplicity of the design.

MRN ! Date/Time ! Category ! Description ! Physician ! Status ! Service ! Accession

"Service" and "Accession" identify the service called to retrieve a result and the unique identifier that is used to retrieve a specific result. Note that all records in the CTR database are the same no matter the type of transaction being stored. One must compare this design with the design of a CDR database to fully appreciate the difference in complexity between the two. The size and complexity of a CTR is about 10% of a CDR.

Results can be stored on an ancillary system, as XML files on a web server, or a combination of the two. Moving data from one system to another is done by copying files to a server and updating the “Service” field in the CTR database. The key point is no new database is created to store results, as is required with a CDR.

Summary list views of transactions do not require a query of an ancillary system as they do with a VDB EMR. Queries to ancillary systems occur only when a user specifically selects a transaction to view the details. This significantly reduces the load on ancillary systems as compared to the VDB EMR model.

Category: Medical informatics