A future performance-based statement of objectives (PBSOO) will provide for final development, integration, testing, and implementation of the Document Engine/Dictation Interface for AHLTA. The following, however, is a list of basic requirements that should be incorporated into the project scope to ensure seamless integration into clinical workflow.
Document Engine - User Interface
- The Document Engine User Interface should be reconfigured as an AHLTA client module enabling providers to capture and manage documentation, including dictations from commercial transcription vendors.
- The Document Engine User Interface module should be adapted to obtain user authentication and privileges from AHLTA, not CHCS.
- The Document Engine User Interface module should continue to support review, editing, and saving of drafts. Depending on their privileges, users should be able to forward to staff providers for signature and/or electronically sign and submit the final document into AHLTA.
Dictations
- Providers should be able to utilize transcription services and their dictations should be categorized by work type as is the current practice. All outpatient jobs should be stored in AHLTA. All inpatient jobs should be stored in CIS using the Clinicomp HL7 Generic Document Interface. Certain inpatient work types (narrative summaries, consults, and operative reports) should also be stored in AHLTA to ensure access to vital documentation.
- Dictations utilizing a work type reserved for confidential material (for example mental health consults) should be stored in AHLTA as a privileged document with “break the glass” requirements for access.
- Dictation companies doing business with the MHS will be expected to utilize standard HL7 ADT/Order feeds provided by the Document Engine. Draft transcriptions will be returned to Document Engine which will ensure delivery to the dictating provider for signature. Transcriptions signed by proprietary software will be returned to the Document Engine for delivery directly into the CDR.
- Dictations will be filed in AHLTA as either a generic Clinical Note or within the encounter “Add Note” section if the documents relate to a particular visit.
Binary Documents
The Document Engine will also manage binary documentation in addition to text dictations.
- It will incorporate a TWAIN compliant scanner interface for capturing paper based information as multi-page TIFF images or pdf documents.
- It will allow Windows applications to “print” to the Document Engine using a virtual print driver as a way of capturing documents.
- It will intercept legacy medical equipment print jobs and convert them into multi-page TIFF documents using a simple parallel-to-serial port conversion cable.
- High Level Technical Overview
The figure below depicts the general architecture in relation to other central projects. It makes extensive use of existing software services, provides a great degree of future flexibility, and enables the MHS to maintain maximal configuration stability, all of which reduce time, effort and cost.
The following diagram illustrates a more detailed proposal for system configuration and workflow. Step one is to ensure that transcription companies are provided accurate demographic AND encounter information. The existing GIS interface within CHCS is thus configured to send a copy of AHLTA HL7 messages to the Document Engine. In addition, the data layer in the local Legacy Gateway Server will be modified to send an HL7 message whenever a new encounter is created. The Document Engine accepts and integrates both these message feeds into standard ADT / Order feeds (which can now include AHLTA encounter information) and retransmits them to vendors delivering documentation for AHLTA.
The transcription companies use these HL7 feeds to return dictations to the Document Engine with all the HL7 metadata required to accurately file them into the appropriate medical record system. Outpatient dictations whose HL7 messages include AHLTA encounter numbers will be filed into the CDR within the encounter “Add Note” section. Dictations without an encounter number will be filed in the Clinical Note section. In either case, the dictation work type will be used as the title of the note to facilitate later search and retrieval; the dictation work types must, therefore, be standardized across the MHS. The filing of a signed dictation by the Document Engine will be accomplished by invoking a new web service exposed on the Legacy Gateway Server; transmission back to the CDR will be handled by the existing long haul infrastructure. Furthermore, existing local cache fail over capabilities can be leveraged. All web service traffic will be SSL encrypted to meet existing security concerns.
All inpatient dictations received by the Document Engine will be submitted upon signature to the Clinicomp HL7 Generic Document Interface for inclusion into CIS. However, dictations work types that are important to the outpatient record (discharge summaries, consults, op reports, etc) will also be sent to AHLTA. Because the Document Engine is an interface AND a workflow engine, all that is needed is some standardization of work types and some simple rules to intelligently handle duplicative inpatient dictation filing. The implications for the quality and completeness of the outpatient medical record are significant.
The diagram also illustrates the configuration for binary documents such as scans or legacy equipment print jobs. In such cases, patient/provider/encounter context is established by the AHLTA client and passed into the Document Engine DOCUCAP, which handles the workflow associated with running a scanner or capturing a print job from a legacy medical device or application. In either case, the end result is a binary pdf or multi-page TIFF image that can be routed, signed, and ultimately submitted for filing using the afore mentioned Legacy Gateway Server web service. The major difference between the workflow for binary documents and text dictations is the way these documents are handled at the CDR. Text documents are small, light weight files easily stored within the CDR proper. Binary files are more akin to digital radiology images and are better stored in a digital asset repository system for obvious performance and scalability reasons. Thus, such potentially massive files will be stored outside the CDR, but linked to the encounter record or patient so that the AHLTA client can retrieve them on demand. Such a storage system is proposed in the AHLTA DFI project; the Document Engine workflow is entirely consistent with the DFI architecture.
- Conclusion
Incorporation of the Document Engine into the AHLTA infrastructure will deliver a proven application to the MHS repertoire, adding substantial functionality and flexibility to the desktop client. Civilian transcription companies will be able to interface with AHLTA simply by delivering their payload as HL7 messages to the Document Engine which will provide the user interface for the review, editing, and ultimate submission of dictations. Legacy medical equipment and Windows–based applications will be able to “print” to the Document Engine and have those jobs packaged and delivered to the provider for signature. AHLTA users will be able to control attached scanners in order to incorporate miscellaneous documents using a workflow that is efficient and uninvolved. Finally, the engine is a future-safe universal interface, capable of accepting delivery of patient documentation from virtually any application or data source using message processor plug-ins.
1. Scope
This project will integrate the Document Engine (DE) Government off-the-shelf (GOTS) product into AHLTA and thereby provide an interface for users to import documents from external vendors, other print-capable Windows software, and legacy hardware. It will also allow users to manage unsigned documents through a delegation, review, and signing workflow.
The Document Engine module (DEM) will provide a universal, standard interface for incorporating clinical documents into patient records. Comprehensive information capture is provided from the following:
- Clinical text Health Level Seven (HL7) messages,
- Print jobs from other Windows applications, and
- Print jobs via serial port data from legacy hardware devices.
1.1 Identification
This Software Requirements Specification (SRS) and Interface Requirements Specification (IRS) document applies to the processes and procedures that are employed to develop and test the current fielded version of AHLTA. This document is submitted to fulfill the requirements identified in the Contract Data Requirements List (CDRL) B001 and CDRL B002 as specified in the Statement of Work (SOW) from the Government for this project. Currently, the DE Integration project software is expected to be released as part of Build 844. However, the actual version, release, and build numbers are determined at the time of software delivery and are provided by the Northrop Grumman Information Technology (IT), Health Solutions (hereafter referred to as Northrop Grumman IT) Configuration Manager directly to the Clinical Information Technology Program Office (CITPO) Configuration Manager upon delivery of the software.
1.2 System Overview
1.2.1 General Nature of System
Figure 1-1 below illustrates the proposed integration plan for the GOTS DE system and its components. The DE system consists of a main Document Engine Server (DES), two database schemas to be located in the In-line Cache Database (ICD) on the Local Cache Server (LCS), an applet, and a Windows virtual print driver to be installed on each AHLTA Client Workstation. Dotted lines indicate where components or functionality will be implemented, while solid lines indicate current components or functionality.
Figure 1‑1: Proposed DE System Components
The DEM will provide a user interface link to enable users to add various documents to an encounter or patient record. The DE system consists of the following software components:
- Oracle HyperText Transfer Protocol (HTTP) Server: a component of the Oracle 10g Application Server handling HTTP web traffic to/from the DE application, DE Web Services, and LCS Web Services.
- DE Application: a Java web application running in an Oracle Containers for Java 2 Enterprise Edition (J2EE) (OC4J) instance of the Oracle Application Server 10g on the DES.
- DE Web Services: a set of Web Services on the DES providing data layer access to the DE database.
- Java Database Connectivity (JDBC): database driver and Application Programming Interfaces (APIs), providing connection and Structured Query Language (SQL) commands to access Oracle database.
- System Print Services: a set of software utilities, Operating System dependent, providing print capabilities to any network printers recognized by DES.
- HL7 Engine: a component of the Oracle Integration Business-to-Business (B2B) providing clinical data exchange using the HL7 standard.
- DE Database: persistent storage for all documents and metadata collected by the DE application. The DE application will be using these services to handle operations such as patient search, clinic search, provider search, and encounter information.
- Generic Interface Engine (IE): a set of Web Services on the Generic Interface providing data layer access to the Clinical Data Repository (CDR). The DE application will be using these services to store signed Clinical Notes.
- HL7 Database: persistent storage for all incoming and outgoing HL7 messages; used by the Oracle Business Integration Healthcare Adapter.
- LCS Web Services: a set of Web Services on the LCS providing data layer access to CDR data.
- Document Capture Driver: a redirection port monitor driver installed on the AHLTA Client Workstation. This driver redirects a special printer port output to the Document Capture Applet.
- Document Capture Applet: a Java applet installed on the AHLTA client workstation that provides the mechanism for data capture from legacy hardware devices and the Windows virtual printer.
Questions have been raised as to whether the DE application and its components could be deployed within the existing LCS to eliminate the need for a new hardware asset. The DE will involve significant data streaming from the Document Capture module and significant inbound/outbound HL7 traffic from the CDR and Transcription System (TS) to the HL7 engine.
Given the critical nature of LCS performance, which could be compromised by server load from the DE, it is recommended that the DE application and components use dedicated servers. This document will assume that the DE will run on a new server to be added to the baseline AHLTA/Military Treatment Facility (MTF) hardware. Its operations are dependent on the LCS; hence, both servers must be deployed together.
Both the LCS and DES are expected to reside inside the MTF network boundary. The TS may or may not be housed within the facility’s firewall.
1.2.2 History of Development, Operation, and Maintenance
AHLTA broadly provides views of a patient’s medical history and documentation tools for that history and for clinical encounters (visits) in the outpatient environment.
This AHLTA enhancement will facilitate the storage and retrieval of imported medical documents, making them accessible to other authorized AHLTA users. DE helps facilitate the completeness of the electronic medical record and the subsequent inclusion of these documents in AHLTA. It also leverages existing systems to maximize the productivity of Military Health System (MHS) specialty providers.
1.2.3 Project Sponsor, Acquirer, User, and Support Agencies
CITPO is the project sponsor and acquiring organization. The users are the uniformed, medical professionals of the Navy, Army, and Air Force Services. The support agencies consist of the Tri-Service Infrastructure Management Program Office (TIMPO), who supplies the network infrastructure, and the Defense Information Systems Agency (DISA), who supplies the housing and maintenance of the computer networks and the CDR.
1.2.4 Current and Planned Operating Sites
When this project is planned for fielding, all sites planned for the rollout of AHLTA will receive the ability to utilize this enhanced capability. There will be a beta testing period for this local caching capability with a selected subset of sites that will be determined.
1.2.5 Other Relevant Documents
All relevant documents for this project are identified in Section 2.
1.3 Assumptions and Dependencies
- While providing AHLTA the capability for interfacing with third-party systems, such the TS, this project does not specifically implement any interfaces with third-party systems.
- The GOTS DE is being integrated largely as-is. Enhancement recommendations to the developers of this product have been made. However, it is not the intent of this project to specify the details of the design of this product. Rather, the intent of this project is to specify and implement the integration of this product into AHLTA.
- It is assumed that the GOTS DE will fully support the HL7 v2.4 eXtensible Markup Language (XML) standard for communications to the transcription vendors.
- Third-party products and vendors must have the capacity to export documents in the HL7 v2.4 standard format, per CITPO technical guidance.
- Third-party products and vendors must identify the following information to associate with new medical documents:
- The provider’s name and identification (ID) number,
- The patient’s name and ID number,
- The AHLTA appointment Internal Entry Number (IEN) (if the transcribed documentation is associated with a scheduled appointment),
- The date of the dictated report, and
- The type of note being dictated.
- Providers reviewing newly transcribed documents on AHLTA will be responsible for verifying that the content of the report is associated with the correct online patient record prior to signing and releasing the document.
- There are no new or alterations to existing reporting requirements for this project.
- There is no additional AHLTA audit logging required for this project.
- There are no new alterations to existing Operational Requirements Document (ORD) timing requirements for this project.
- There are no new or alterations to existing performance monitoring (Application Response Measurement [ARM]) requirements for this project.
- There are no impacts to existing requirements for this project.
1.4 Document Overview
The purpose of this document is to provide the Government with a thorough understanding of the requirements and expected interfaces for the DE Integration project as it relates to AHLTA. The document is organized as follows:
Section 1 describes the scope of the project and includes an overview of the system and an overview of the document structure.
Section 2 identifies related referenced documentation.
Section 3 provides an overview of the requirements.
Section 4 describes Qualification Provisions, if they apply to the project.
Section 5 explains the details of the Requirements Traceability Matrix (RTM).
Section 6 contains the list of acronyms used in the document.
Appendix A contains the system requirements for this project.
This document is intended for use by CITPO, Government, and contract personnel only. Any other use, duplication, or distribution of this document without the express written consent of CITPO is strictly forbidden. Requests for use of this document can be made to the CITPO Task Manager as identified in the SOW for this project listed in Section 2.
...