The Patient Recording System will modernize the existing system by changing methods of data collection and replacing manual data input of paper records with a fully automated electronic data capture.
The system supplies future data requirements of the Fire Service Emergency Cover (FSEC) project, Fire Control, fundamental research and development. Fire and Rescue Services (FRSs) will also be able to use this better quality data for their own purposes.
The IRS will provide FRSs with a fully electronic data capture system for all incidents attended. All UK fire services will be using this system by 1 April 2009.
Creation of a general-purpose medical record is one of the more difficult problems in database design. In the USA, most medical institutions have much more electronic information on a patient’s financial and insurance history than on the patient’s medical record. Financial information, like orthodox accounting information, is far easier to computerize and maintain, because the information is fairly standardized. Clinical information, by contrast, is extremely diverse. Signal and image data—X-Rays, ECGs, —requires much storage space, and is more challenging to manage. Mainstream relational database engines developed the ability to handle image data less than a decade ago, and the mainframe-style engines that run many medical database systems have lagged technologically. One well-known system has been written in assembly language for an obsolescent class of mainframes that IBM sells only to hospitals that have elected to purchase this system.
CPRSs are designed to review clinical information that has been gathered through a variety of mechanisms, and to capture new information. From the perspective of review, which implies retrieval of captured data, CPRSs can retrieve data in two ways. They can show data on a single patient (specified through a patient ID) or they can be used to identify a set of patients (not known in advance) who happen to match particular demographic, diagnostic or clinical parameters. That is, retrieval can either be patient-centric or parameter-centric. Patient-centric retrieval is important for real time clinical decision support. “Real time” means that the response should be obtained within seconds (or a few minutes at the most), because the availability of current information may mean the difference between life and death. Parameter-centric retrieval, by contrast, involves processing large volumes of data: response time is not particularly critical, however, because the results are used for purposes like long-term planning or for research, as in retrospective studies.
In general, on a single machine, it is possible to create a database design that performs either patient-centric retrieval or parameter-centric retrieval, but not both. The challenges are partly logistic and partly architectural. From the logistic viewpoint, in a system meant for real-time patient query, a giant parameter-centric query that processed half the records in the database would not be desirable because it would steal machine cycles from critical patient-centric queries. Many database operations, both business and medical, therefore periodically copy data from a “transaction” (patient-centric) database, which captures primary data, into a parameter-centric “query” database on a separate machine in order to get the best of both worlds. Some commercial patient record systems, such as the 3M Clinical Data Repository (CDR) are composed of two subsystems, one that is transaction-oriented and one that is query-oriented. Patient-centric query is considered more critical for day-to-day operation, especially in smaller or non-research-oriented institutions. Many vendors therefore offer parameter-centric query facilities as an additional package separate from their base CPRS offering. We now discuss the architectural challenges, and consider why creating an institution-wide patient database...
Please join StudyMode to read the full document