Appendix G - LMS/EMS Interface

Appendix G - LMS/EMS Interface

Requirements Document

Document History

Approvals

Your signature below indicates that this document meets its objectives and is acceptable.

Table of Contents

Purpose of the Document

Acronyms

Executive Summary

Introduction

1.1Project Overview

Business Model

1.1.1Organizational Profile

1.1.2High Level ‘As-Is’ Process Flow

1.1.3High Level ‘To-Be’ Process Flow

Requirements Definition

1.2Overview

1.2.1Approach

1.3Detailed Requirements

1.3.1Business Requirements

1.3.2Input & Output Requirements

1.3.3Internal & External Requirements

Purpose of the Document

The purpose of this Requirements Document is to provide technical specifications for a Learning Management System to interface with the Pennsylvania Department of Health, Bureau of Emergency Management applications.

Acronyms

Table: Acronyms Used in This Document

Executive Summary

The LMS/EMS interface will facilitate data exchange, providing the Department with up-to-date information on the required Continuing Education courses that Emergency Medical Service personnel must take in order to maintain active certification. This interface and exchange of information is a critical component of the Department’s ability to track and certify Emergency Medical Service personnel as well as providing the EMS community a valuable resource that reduces administrative overhead. This interface and information exchange must be built, tested, and operational by July 1, 2016, or within 45 calendar days of the date of the purchase order, whichever is later.

Introduction

1.1 Project Overview

The LMS/EMS Interface is a part of the overall DOH LMS effort. This document is specifically to define the LMS/EMS interface and what the EMS interface requires of an LMS system.

Business Model

The current LMS provider interfaces with the EMS system via DOH-developed ASMX web services. Any information provided to the EMS system is in XML format. This model works well as-is.

1.1.1 Organizational Profile

The LMS/EMS interface will impact BIIT applications development staff who will have to work with the new LMS provider to ensure the systems communicate correctly. BEMS staff will be impacted only if the interface does not work as it does now, and the impact will be the loss of an automated process resulting in more administrative overhead (e.g. hand entering data into the BEMS ConEd system, coordinating with EMS regional councils and organizations to have their personnel record data in the BEMS ConEd system).

1.1.2 High Level ‘As-Is’ Process Flow

The ‘As-Is’ process operates as follows:

1. User registers with LMS system.
2. LMS system checks with EMS User Check web service to determine if the person is a registered PA practitioner currently in good standing as determined in the DOH EMS system. If the practitioner is in good standing and registered, the EMS User Check web service returns ‘Yes’ otherwise ‘No’ is returned.
3. If the PA practitioner is in good standing and registered, they will be allowed to complete account registration. The practitioner’s LMS account shall be marked as an EMS record from which information must be provided to DOH BEMS via DOH EMS Registry Web Service.
4. If the PA practitioner is not in good standing or registered, they will not be allowed to complete account registration and shall be directed to contact DOH BEMS.
5. For PA practitioners in good standing, the LMS system gathers relevant information on student, class, course as defined below and passes data in XML format to DOH EMS Registry Web Service without additional calls to the EMS User Check web service.
6. Any historical data (defined as data existing prior to contract award) in the LMS system for Pennsylvania users should be retained in the LMS system but not sent to the DOH EMS Registry Web Service.
7. In instances of a practitioner regaining good standing as determined in the DOH EMS system and attempting to register or continue registration in the LMS system, the LMS system shall follow the steps starting at Step 1 as defined in this section (1.1.2).
8. Any ConEd data recorded for a practitioner from the date of contract award forward shall be provided to DOH EMS via DOH EMS Registry Web Service regardless of standing in DOH EMS system. Standing determined as described above.

1.1.3 High Level ‘To-Be’ Process Flow

The ‘To-Be’ flow shall be similar to the ‘As-Is’ flow, so that the same DOH EMS Web Service is used to receive ConEd information for EMS personnel.

Requirements Definition

1.2 Overview

1.2.1 Approach

Requirements determined based on existing applications.

1.3 Detailed Requirements

1.3.1 Business Requirements

Business requirements are usually provided by the program area during the requirements gathering process. It is helpful to include the business goal linked to the requirement in order to provide the “why” of the requirement. For example, will this requirement fulfill a legislative mandate, the organization’s financial goal, or productivity goal?

1.3.2 Input & Output Requirements

This section describes all manual and automated input requirements for the software product (e.g., data entry from source documents or other applications). The source of the input and output requirements are identified and shall be as follows:

a) Reports: define the report(s) to be produced as indicated by the processing requirement. It includes a description of the function of the report(s), and the frequency, distribution, sequence of the report(s), as well as the list of data elements which are to appear on the report. Examples of the report(s) are to be included, if they are available.

b) Forms: This subsection defines the form(s) to be produced as indicated by the processing requirement. It includes a description of the function of the form(s) and the frequency, distribution, sequence of the form(s), as well as the list of data elements to appear on the form. Examples of the form(s) are to be included, if they are available.

c) Screens: This subsection defines the screen(s) to be developed. It includes a description of the function of the screen(s), pass-off rules, security requirements, and the list of data elements to appear on the screen. Examples of the screen(s) are to be included, if they are available

d) Files: This subsection defines the file(s) to be created by the processing requirement. It includes the file format required, data elements to be included, and the name of the system(s) that will be receiving the file. Identify the data elements and logical data groupings that will be created accessed, stored and processed by the software product. Identifying and grouping data begins during the Requirements Definition Stage and is expanded in subsequent stages, as more information becomes known. Data requirements may include the need for data purification, either as a conversion effort or as an ongoing activity, and additional issues such as data archival and purging.

e) Data Elements: This subsection identifies and describes in general terms each of the data elements within the scope of the new system. Initially, the data elements identified are those contained on the outputs, plus additional data elements required to support automated functions of the system. As the system project progresses into subsequent levels of detail, this list is refined and expanded as additional data elements are defined. The emphasis is on the characteristics of data elements rather than specific formats.

f) Data Structure: This subsection establishes a preliminary organization of the defined data elements into logical records and the relationships between these logical records. The data are organized in a way that facilitates the processing of inputs to generate outputs and satisfy other computational requirements. Generally, this is best accomplished by defining data structure that models the way in which data naturally occurs in the environment. As a part of this task, the project team organizes required data elements into logical records or schemas and develops an initial specification for these data element groups and group relationship. A data structure chart is then prepared to illustrate the logical relationships among the records defined above. Connecting lines may be used to indicate that one record can be logically accessed from another. In addition, a key is identified for each record that may be directly accessed. The objective of this task is to define a logical set of records and record relationships that satisfy the user-based requirements of the new system.

g) Files: This subsection defines the input and output file(s) required for the processing requirements. It includes a description of the function of the file, file layouts, and the list of data elements to be included.

1. Registered with the PA DOH EMS system.
2. Is in good standing in the PA DOH EMS system.

1.3.3 Internal & External Requirements

This section discusses the environmental requirements and how they are determined. It includes both internal and external interface requirements, operating constraints, policy change, and control requirements and shall be provided as follows: