Returning to the Complete Medical Record
BRINGING TOGETHER ALL OF THE MEDICAL HISTORY PIECES INTO A SINGLE, MANAGEABLE RECORD.
It was complete when it was all paper and stored in one location. The medical record was divided into many piece-parts as hospital automation systems expanded to capture more and more medical record data. This situation usually results from the commonly-phased introduction of the automated medical record into hospital or practice settings where the overall effort is driven by budget constraints, workload requirements, culture shock, training barriers and many other issues that lead to a two-to-10-year path to a complete automated electronic health record.
Here’s how it happens. The automation effort in health care settings usually begins with the administration modules with the deployment of patient registration and demographics, admissions/ discharge/transfer, cost accounting, billing and appointing. At this point the clinical medical record is still intact. The next step is computerized physician order entry with the deployment of modules covering laboratory, radiology, pharmacy, results reporting, consult tracking and other ancillaries.
Some of this medical data may make it into the paper record, but most of it, by design, remains on the automated system unless it is printed from the automated system to be included in the paper record, as an extra step. At this time the patientphysician encounter is still captured on paper, along with a multitude of data from other non-automated or stand-alone medical tests and results.
Here is where a major split in the record occurs. The paper record contains the clinic encounter notes, but the automated ancillary data is primarily stored in the automated system. The health care provider now has to search at least two places and fuse the information for a complete picture of the patient’s health.
INTRODUCTION OF THE AUTOMATED CLINICAL NOTE
The next step in the automation development is the introduction of the clinical note entered by the physician, nurse or ancillary personnel. This step introduces a structured process that guides clinical practices, coding, as well as the capture of the subjective assessment, diagnosis and treatment plan for the patient.
Included in this phase is the capture of the patient health history and physical, clinical decision support, clinical practice guidelines, population health, patient self reporting, alerts and reminders, eligibility and enrollment, immunizations, outcomes management, role-based security, and more. But we still have all those noncomputable patient record components that don’t fit into the computable automated record, as well as other computable or automated records that, for the time being, are not shared with the current computerized patient record.
These piece-parts include documentation of care provided outside of the reaches of the automation umbrella. This could be care provided by other network providers, or care provided in out-of-network facilities, or specialty care provided by independent practitioners, or other data.
The complete medical record is now all over the place and in dire need of being brought back to whence we started: a single location for all patient-centric medical information. This medical data can be captured—whether it is organically electronic or paper-based—reformatted into a compatible electronic version, and linked via metadata into the electronic patient record. By capturing all of this other medical data, these documents, files and images (DFI) bring back to the health care provider the complete medical record through the integration of the automated order entry system, the automated clinic note and the DFI, into a single system.
ENABLING THE MILITARY HEALTH SYSTEM’S CPR SYSTEM
The Military Health System is embarking on a project to include DFI data with the already combined physician order entry system with their automated clinic note (AHLTA) offering health care providers a single source for all patient-centric data. This phased effort will begin with the upgrade of the automated clinical note with a DFI module that will be able to display DIF thumbnails, display detailed views, sort DFI, associate DFI with encounters and more. Pick lists will be used to offer the clinician the ability to choose which images from a particular encounter they wish to display on their clinical workstation.
A DFI management system will house the central DFI repository as well as the central DFI registry, allowing any provider within the enterprise to find and display DFI on their clinical workstation. Initially, the DFI effort will be focused towards the integration of digital radiology images from the picture archive and communication system (PACS) for the display of consultative images for health care providers.
ENHANCING THE MHS’S CPR SYSTEM
The enabled CPR will then be enhanced by expanding the capabilities of the DFI module into the clinical modules, and by including a local repository and registry at the medical treatment facilities (MTFs). Additionally, a commercial-off-the-shelf document management system will be included to offer the full range of DFI management system capabilities to the enterprise for clinical DFI.
The DFI registries will contain DFI metadata that will be displayed via the clinical encounter modules where the providers will be notified of available DFI, and via pick lists, they can then pull and display DFI on the clinic workstation. The local registry and repository will also be used as a cache for the local PACS, as well as to capture other local DFI as described above. PACS DFI will remain the initial focus of the enhanced CPR.
ARCHITECTURAL CONSIDERATIONS
The architecture to be used will be a combination of a centralized architecture for historic and/or very large DFI, and a federated architecture for locally captured DFI, best described as an edge-proxy architecture where the DFI is formatted in a standard way and ready for viewing or transmission throughout the enterprise. Because the practice of medicine is 80 to 90 percent local, the employment of a local registry and repository will use the high bandwidth capabilities found in the MTFs and not load the wide area network (WAN) with a lot of DFI traffic. It is expected that the DFI traffic that will ride the WAN will be from servicemembers that are transferring to another location where their providers are in need of viewing their previously captured local DFI.
This WAN DFI traffic can be prioritized and scheduled using the document management system so that the resulting load on the WAN will be minimized during times of heavy clinical usage. Additionally, this architecture will offer continuity of operations for periods when the MTF is disconnected from the WAN.
The document management system will be incorporated using Web-based services and a service oriented architecture to ensure flexibility in selecting and employing the COTS document management system. This architecture is rapidly expandable beyond managing only PACS DFI. It will be able to offer the scanning and capture of any and all other types of DFI data, to include documents from encounters provided by managed care support contractors, out-of-network care, sharing of data with the Veterans Administration, and certainly capturing the medically relevant historical paper medical record. Just how much historical paper record data is captured is a study in itself.
Documents, files and images, integrated with the order entry system and the clinic note system, brings back to the provider the complete medical record offering him or her the entire medical picture available from a single source. ♦