Software Requirements Specification

Release Information

Project: EGADSS
Internal Release Number: $Revision: 1.6 $
Attached worksheets:
Related Documents:

Introduction

This Software Requirement Specification (SRS) outines the requirements for the construction phases of EGADSS (see QA Plan for the project phases and timelines). 

The objective of this document is not only to define the product but also to communicate the intended system features to both developers and users.  The level of abstraction is intentionally kept high to accommodate a wide range of audiences such as software engineers, informaticians, clinicians, and other interested parties.   


Domain Analysis


The purpose of conducting the domain analysis is to identify, capture, and analyze relevant information realm in which the intended system will function.  This section summarizes the domain analysis by presenting relevant business processes as well as concepts pertinent to the clinical decision support.

Business Process Model

In order to design a particular system it is important to understand the underlying process and workflows that the system must support.  Figure 1 is a high-level illustration of a typical workflow for a patient encounter which involves decision making steps.  Note that this is a description of a general process and the flow of activities may vary depending on the context.  However this workflow helps in understanding the context for decision support in a clinical setting.  In order to identify specific portions of the process model that involve decision support functionality, we have graphically shown the boundary between the electronic medical record (EMR) system and EGADSS.


Figure 1.  Business Process Model.
process model


Business Concept Model

The business process model and the investigation of the clinical domain in general resulted in a number of relevant concepts.  Figure 2 presents a mind map that relates these concepts and helps us formulate a cohesive modeling domain that will be reflected in software artifacts at the later design stages.  It is important to note, however, that a concept model does not necessarily provide tight scoping of the problem being modeled.


 Figure 2.  Concept Model.
concept model

Use Cases

A number of use cases have been identified in order to describe the typical usage scenarios of the EGADSS system.  Actors are described in the user needs document and the use case suite lists all use cases in organized by the project phases and functional areas.

Functional Requirements

The specific functional system requirements have been systematized as a feature set list.

Non-Functional Requirements

  • Openness 
    •
Decision support and knowledge management in business can have very different objectives and strategies as compared to health sector, for example profit vs. quality.  It is very important to ensure that a decision support system gives a clinician an objective and independent advise with the best interests of a patient in mind.  To overcome the influence of financial interests we selected an open framework for EGADSS.  Our definition of openness includes open source code, content, documentation, and opportunities for collaboration.
    • Open Source Code
      •
      In order to draw the best ideas and practices from the software engineering domain, the EGADSS source code will be open and accessible to any interested parties.
    • Open Content
      •
      In the scope of the EGADSS project, open content implies disclosing the knowledge base that consists of clinical practice guidelines used by EGADSS. 
    • Open Documentation
      •
      The availability of the quality documentation for the system (including the architectural design, source code, etc) is an important part of the open philosophy.  Therefore, EGADSS project will release documentation  artifacts as open content.
    • Open Collaboration Opportunities
      •
      Collaboration is important not only within the system development group but also through the external channels.  Therefore it is the goal of the EGADSS development initiative to attract potential collaborators and generate synergy of ideas and efforts.  Encouraging collaboration will be both in terms of growing a community of developers and also through collaboration with academic groups to enhance and encourage research in decision support.
    • Performance
EGADSS should be responsive and expedite decision making and provide best practice knowledge within minimal time frame.  EGADSS must be designed as a system that will be active in real time at the point of care. Significant delays will negatively impact the utility of the system for clinicians.
  • Reliability 
    •
EGADSS must have a high level of reliability for the following reasons: EMR systems that will integrate EGADSS will rely on the accuracy of EGADSS for important - if not critical - decision making.  The two aspects are primary concerns of the reliability requirement:
    • System
      •

The system should be fully operational at any given time.  In case of faults, the system should degenerate slowly and gracefully.

    • Content
      •
      Content reliability is an important issue.  Not only the content should be accurate and safe, it also has to be reliable.
  • Integration with an EMR 
    •
EGADSS is expected to work in conjunction with a variety of EMR systems and provide complimentary value-add-on service of decision support.  EGADSS will be tested with the TAPAS platform, currently in development by the EGADSS group.  TAPAS will be an eMS compatible componentized clinical information system.
  • Standard Data Representation
    •
Standards compliance is important for creating any technological solutions that are intended to work with a wide range of health information systems.  The area of electronic clinical decision support does not have well-established standards; however appropriate general health informatics standards can be leveraged on the following levels: information modeling, standardized vocabularies, and structured knowledge encoding.  Where feasible, we will work with existing standards.

Environmental Requirements

What are the system hardware requirements?
  • CPU: Pentium 3 or higher
  • Memory: 512 MB recommended
  • Network connectivity: required
What are the system software requirements?
  • The EGADSS system should be agnostic of any particular Operating System.
  • Java Runtime Environment
What application program interfaces (APIs) must be provided?

SOAP API is required to enable the integration of EGADSS with EMR systems.  The following types of APIs are required:

  • Configuration API
  • Transaction API
  • Auditing API
  • Knowledge management API
What are the data input and output requirements?

The document-oriented paradigm is adopted for the interchange of medical data within EGADSS framework.  Document-oriented operation is one in which messages contain XML documents.  This choice was influenced by the traditional nature of information communication in health care where medical records are typically stored in charts, or documents.  In addition, modern Service Oriented computing such as Web Services provides full support for document-oriented messaging.

Details:

  • The system will input and output XML documents which will be validated against appropriate W3C Schema templates.
  • The format of the documents will be structured according to the HL7 Clinical Document Architecture (CDA).
  • The content of the input and output documents will be consistent with the templates defined by the clinical domain experts; see: "Patient Summary" and  "Results"
Company Proprietary
All text is available under the terms of the GNU Free Documentation License.

SourceForge.net Logo