Clinical Transaction Repository EMR

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.
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.

Main Menu

See Also

Main Menu