University Electronic Health Record Requirements Specification Evan Gray Advisor: Professor Taylor September 27, 2013 Submitted in partial fulfillment of the requirements of CMPS 490 Computer Projects 1
Abstract This document contains the requirements specification for a university electronic health record to be used by any university that wishes to electronically document student and staff medical records through a dynamic web application with database support. The system will allow clinical staff to document patient encounters, issue prescribed medications to a medical chart, query extensive patient history, and communicate with other healthcare providers to ensure quality care. The staff will be able to use the system for scheduling purposes, clinical documentation during a visit, follow up actions, and archiving patient history. This document presents the system model, the functional and non-functional requirements, user interface specification, and assumptions of system evolution. 2
Table of Contents Introduction... 4 System Model... 5 Functional Requirements... 6 Services Provided Clinician Account... 6 Services Provided Patient Account... 7 User Interface Specifications... 8 System Evolution... 8 3
Introduction Starting in early 2015, the Health Information Technology for Economic and Clinical Health Act (HITECH) will begin imposing penalties on health practitioners who have not implemented some form of an electronic health record. To avoid these penalties, healthcare organizations must show that they are meaningfully using some form of a certified electronic health record. When it has been proven that these information systems are improving the quality of healthcare, organizations can claim incentive payments. Most people don t realize that electronic health records do a lot more than create and update health records. EHRs are cross-functional enterprise systems driven by integrated applications and modules. They also include decision support modules and executive management information system components to help managers make the most effective and efficient decisions to achieve their goals. EHRs improve billing processes and create financial stability. When a procedure in a clinic or hospital is ordered and completed, charge capture functionalities within the EHR automatically update the patient s bill in real-time. This gives an accurate view of the variable and fixed costs for the healthcare organization. I propose creating a similar web application that has specifically tailored functions for a small wellness center such as the one here at the university. The system could be created in such a way that it can easily be modified to serve any university throughout the country with little effort. This would eliminate the cost constraints that hinder implementing current electronic health records. These wellness centers and clinics would be able to enjoy many of the documentation benefits that EHRs can provide. 4
System Model The web application is created using the Google Web Toolkit following the model-viewpresenter software pattern. The model-view-presenter is a graphical user interface design pattern that improves the separation of concerns in presentation logic. The model defines the data that is to be displayed. The view is a passive interface that displays the data received from the model. The view contains all of the code that creates the user interface. The presenter acts as the middleman between the view and presenter. It retrieves the data from the model and prepares it for display by the view. The figure below visually demonstrates the MVP structure. The Google Web Toolkit will automatically convert the Java code into HTML and JavaScript to create a dynamic user interface driven web application. The application will communicate with a PostgreSQL database to query the necessary information and serve as the model data. GWT employs asynchronous remote procedure calls that are executed on the web server. 5
Functional Requirements When following the model-view-presenter software pattern, it is necessary to create many pairs of views and presenters. Each of these constructed pairs provide the user with a different service within the web application. A central application controller will handle the control flow. Several of the features that will be included in the web application are listed in the subsection below. Services Provided Clinician Account The university electronic health record will provide the following services listed below: Register new clinician (unique to a specific clinic) Log in to the system as clinician Create general clinical categories General encounters (checkups, follow-ups, etc.) Lab tests (blood work, blood sugar, pregnancy test, etc.) Pharmacy (prescriptions, over-the-counter medications, etc.) Modify/edit all created categories Create specific sub-categories for each general clinical category View specific information submitted from patient accounts Issue follow-up tasks specific to encounters for patient accounts 6
Services Provided Patient Account After the clinician sets up their categories for patient documentation, the settings are saved in the database. From that point forward, whenever a patient comes to the clinic, the clinician will enter in the student's user name and Royal number and log in to their account to document during a visit. If the patient is not registered to the system, the clinician can setup a new patient account. Register new patient (unique to a specific clinic) Log in to the system as patient Enroll patient to clinical provider Update clinical information based on categories setup by clinician Receive update tasks from clinician or progress notes Store historical medical information 7
User Interface Specifications The user interface will be dynamic and fully interactive by making use of the tools in the Google Web Toolkit. Most of the input will be entered by keyboard. Several of the view/presenter pairs will utilize drop down menus which a user will select from. I will also be using the Google Web Toolkit date picker for scheduling purposes. This feature will present the user with a visual calendar in which they can select a date from. The output will be shown on the screen once the input is saved or if data is queried from the database. Most saved data will have editing functionality so that the information can be changed if needed. System Evolution The system is being created with evolution and future upgrades in mind. I am dividing up the system into packages that can be quickly modified to change features within the application. If additional functionality needs to be added in the future, someone can easily create a new package and slightly modify an existing view/presenter pair to meet their needs. I am also creating the application using a generic model so that if it were to be used by multiple universities, very few things would need to be modified to get the application up and running quickly. If that type of situation arises, the database would need to be populated with site specific data and the website layout would need to be changed. The functions within the code would need to be changed very little, if at all. 8
Glossary Control flow Electronic health record Google Web Toolkit Model-view-presenter Software package the order in which the individual statements, instructions or function calls of an imperative or a declarative program are executed or evaluated. an evolving concept defined as a systematic collection of electronic health information about individual patients or populations. open source set of tools that allows web developers to create and maintain complex JavaScript front-end applications in Java. derivative of the model view controller (MVC) software pattern, also used mostly for building user interfaces. a software component for accomplishing a particular thing; a mechanism for organization. 9
Alphabetical Index database...2, 5, 7p. electronic health record...4 Google Web Toolkit...5, 8p. model-view-presenter...5p. Model-view-presenter...9 System Model...5 10