Purpose of the Document .us



Appendix G - LMS/EMS InterfaceRequirements DocumentPrepared by:Brandon ShawProject #:Submitted to:Bob ChilcoteDate submitted12/22/2015Document version:V0.2Document HistoryVersionDateAuthorStatusRevision Descriptions0.112/3/15Brandon ShawInitial Draft0.212/22/15Brandon ShawSecond DraftAdded User Check web service information.ApprovalsYour signature below indicates that this document meets its objectives and is acceptable.SignatureSignatureNameNameTitleTitleDateDateSignatureSignatureNameNameTitleTitleDateDateTable of Contents TOC \o "1-3" \h \z \u Purpose of the Document PAGEREF _Toc440542245 \h 4Acronyms PAGEREF _Toc440542246 \h 5Executive Summary PAGEREF _Toc440542247 \h 6Introduction PAGEREF _Toc440542248 \h 71.1Project Overview PAGEREF _Toc440542249 \h 7Business Model PAGEREF _Toc440542250 \h 81.1.1Organizational Profile PAGEREF _Toc440542251 \h 81.1.2High Level ‘As-Is’ Process Flow PAGEREF _Toc440542252 \h 81.1.3High Level ‘To-Be’ Process Flow PAGEREF _Toc440542253 \h 8Requirements Definition PAGEREF _Toc440542254 \h 91.2Overview PAGEREF _Toc440542255 \h 91.2.1Approach PAGEREF _Toc440542256 \h 91.3Detailed Requirements PAGEREF _Toc440542257 \h 91.3.1Business Requirements PAGEREF _Toc440542258 \h 91.3.2Input & Output Requirements PAGEREF _Toc440542259 \h 91.3.3Internal & External Requirements PAGEREF _Toc440542260 \h 161.3.4Archive & Purge Requirements PAGEREF _Toc440542261 \h 161.3.5Audit Requirements PAGEREF _Toc440542262 \h 171.3.6Security & Privacy Requirements PAGEREF _Toc440542263 \h 171.3.7Usability & User Interface Requirements PAGEREF _Toc440542264 \h 171.3.8Personnel Related Requirements PAGEREF _Toc440542265 \h 181.3.9System Environment Requirements PAGEREF _Toc440542266 \h 181.3.10Computer Resource Requirements PAGEREF _Toc440542267 \h 181.3.11Performance Requirements PAGEREF _Toc440542268 \h 201.3.12Data Conversion & Migration Requirements PAGEREF _Toc440542269 \h 211.3.13Logistics Related Requirements PAGEREF _Toc440542270 \h 221.3.14Disaster Recovery and Back-up Requirements PAGEREF _Toc440542271 \h 221.3.15Other Requirements PAGEREF _Toc440542272 \h 22Purpose of the DocumentThe 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 DocumentAcronymDefinitionLMSLearning Management SystemEMSEmergency Medical Service(s)PAPennsylvaniaDOHDepartment of HealthBEMSBureau of Emergency Medical ServicesBIITBureau of Informatics and Information TechnologyConEdContinuing EducationExecutive SummaryThe 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.IntroductionProject OverviewThe 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 ModelThe 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. Organizational ProfileThe 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).High Level ‘As-Is’ Process FlowThe ‘As-Is’ process operates as follows:User registers with LMS system.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.If the PA practitioner is in good standing and registered, they are allowed to continue to complete training to be used towards their EMS required ConEd needed to renew/obtain their EMS certification. If the PA practitioner is not in good standing or registered, any training taken in the LMS is not passed to the DOH EMS Registry Web Service until the practitioner registers with the DOH EMS system.For PA practitioners in good standing, the LMS system gathers relevant information on student, class, course as defined below.LMS system passes data in XML format to DOH EMS Registry Web Service.High Level ‘To-Be’ Process FlowThe ‘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 DefinitionOverviewApproachRequirements determined based on existing applications.Detailed RequirementsBusiness RequirementsBusiness 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?IDPriorityRequirements StatementSourceBR01CriticalLMS system shall pass EMS personnel training information to the DOH EMS systemsBIIT, BEMSBR02HighLMS system shall check with the DOH EMS systems to determine if a registered PA provider is in good standing.BIIT, BEMSInput & Output RequirementsThis 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: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. 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. 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 availableFiles: 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.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.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.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. IDPriorityRequirements StatementAcceptance CriteriaSourceBR IDIO01HighThe LMS system shall provide information to the DOH EMS Registry Web Service, ProcessConed method.The Web Service is available at: system can access DOH EMS Registry Web ServiceBIITBR01IO02HighThe LMS system shall be provided a secure GUID to be used to access the DOH EMS Registry Web Service.LMS provider is provided a secure GUID, DOH EMS Registry Web Service configured to allow access to submit data based on provided GUIDBIITBR01IO03HighThe LMS system shall provide data in XML format to the strXML parameter of the ProcessConed method of the DOH EMS Registry Web Service. Each call to the DOH EMS Registry web service shall transmit information about one individual taking one class.The XML shall be formatted as follows:<CONEDRAW>? <TABLE>????? <HEADER></HEADER>????? <DOB></DOB>????? <VALID></VALID>????? <OLDCERT></OLDCERT>????? <LEVEL1></LEVEL1>????? <REGION>07</REGION>??????<COURSE></COURSE>????? <CLASS></CLASS>????? <HOURS></HOURS>????? <DATEFINAL></DATEFINAL>????? <SSN></SSN>????? <REMED />????? <COUNTY></COUNTY>??????<LASTNAME></LASTNAME>????? <FIRSTNAME></FIRSTNAME>????? <MI></MI>????? <SUFFIX></SUFFIX>????? <SPONSORID></SPONSORID>????? <SPONNAME></SPONNAME>????? <TEMP></TEMP>????? <ERRORS></ERRORS>????? <MESSAGE1></MESSAGE1>????? <MESSAGE2></MESSAGE2>????? <MESSAGE3></MESSAGE3>????? <SEND />? </TABLE>? <Constraint>????? <Securitystring></Securitystring>? </Constraint></CONEDRAW>The XML schema can be provided as needed.Field Definitions:Field NameDescriptionIs Required?HEADERLMS provider record identityYDOBDate of Birth of the individual receiving the training.YVALIDIndicates a valid recordYOLDCERTPA EMS certification numberYLEVEL1EMS Certification Level/TypeYREGIONEMS Region the practitioner lives inYCOURSETraining course numberYCLASSTraining class numberYHOURSNumber of hours the class counts towards certification/re-certificationYDATEFINALDate class was completed.YSSNSocial Security Number of the individual receiving the trainingNREMEDN/ANCOUNTYPrimary county the individual receiving training resides inYLASTNAMELast name of individual receiving trainingYFIRSTNAMEFirst name of individual receiving trainingYMIMiddle Initial of individual receiving trainingNSUFFIXSuffix of individual receiving trainingNSPONSORIDID of sponsoring EMS providerYSPONSORNAMEName of sponsoring EMS providerYTEMPN/ANERRORSN/ANMESSAGE1N/ANMESSAGE2N/ANMESSAGE3N/ANSENDN/ANSecuritystringGUID, see IO02YLMS provider submits data to the DOH EMS Registry Web Service provided in IO01 in the format specified.BIITBR01IO04HighThe LMS system shall check with the DOH EMS User Check web service to determine if the practitioner is:Registered with the PA DOH EMS system.Is in good standing in the PA DOH EMS system.The LMS system shall use the CheckUser method of the DOH EMS User Check web service. The DOH EMS User Check web service can be accessed at the following URL: system can access DOH EMS web service.BIIT, BEMSBR02IO05HighThe LMS system shall be provided a secure GUID to be used to access the DOH EMS User Check Web Service.LMS provider is provided a secure GUID, DOH EMS User Check Web Service configured to allow access to query data based on provided GUIDBIITBR01IO06HighThe LMS system shall use the CheckUser method of the DOH EMS User Check web service. The CheckUser method takes the following parameters:Parameter NameDescriptionIs Required?strSecurityGuidGUID provided by DOH BIIT, referenced in IO05YintCheckTypeValid value is either 1 or 2. Use 1 for an initial check, 2 for any follow up checks.YstrCertNumberPA EMS certification numberYstrLevelEMS Certification Level/TypeYstrRegionEMS Region the practitioner lives inYstrDOBDate of Birth of the practitionerYstrCountyPrimary county the individual receiving training resides inYThe CheckUser method returns a ‘Yes’ if the provider is both registered with PA and in good standing. Otherwise, a ‘No’ is returned.LMS provider is able to submit data as specified to the CheckUser method, and appropriately determine LMS workflow based on returned value.Internal & External RequirementsThis 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: IDPriorityRequirements StatementAcceptance CriteriaSourceBR IDIE01HighThe LMS system shall use the existing DOH EMS Web Services ‘As-Is’.The LMS provider modifies their system to consume and provide data to the existing DOH EMS Web Services without DOH needing to make modifications to existing applications.BIITBR01, BR02Archive & Purge RequirementsThis section includes the requirements concerning the disposition of data on system database(s), files, and other media, which are no longer essential to the core functions of the system. Specific requirements include length of retention, the specific data elements, the access and retrieval requirements, and final disposition of the data.IDPriorityRequirements StatementAcceptance CriteriaSourceBR IDAudit RequirementsThis section defines the audit provisions and capabilities to be included in the system. IDPriorityRequirements StatementAcceptance CriteriaSourceBR IDSecurity & Privacy RequirementsThis section specifies the system requirements, if any, concerning with maintaining security and privacy. The requirements shall include, as applicable, the security/privacy environment in which the system must operate, the type and degree of security or privacy to be provided, the security/privacy risks the system must withstand, the required safeguards to reduce those risks, the security/privacy/accountability the system must provide, and the criteria that must be met for security/privacy certification or accreditation.[Insert table of applicable requirements here.]IDPriorityRequirements StatementAcceptance CriteriaSourceBR IDUsability & User Interface RequirementsUser interface requirements describe how the user will interact with the software product (including references to any pertinent user interface standards) and explain how information will flow between the user and the software product. IDPriorityRequirements StatementAcceptance CriteriaSourceBR IDPersonnel Related RequirementsThis section specifies the system requirements, if any, included to accommodate the number, skill levels, duty cycles, training needs, or other information about the personnel who will use or support the system. Examples include requirements for the number of work stations to be provided and for built-in help and training features. Also included shall be the human factors engineering requirements, if any, imposed on the system. These requirements shall include, as applicable, considerations for the capabilities and limitations of humans, foreseeable human errors under both normal and extreme conditions, and specific areas where the effects of human error would be particularly serious. Examples include requirements for adjustable-height work stations, color and duration and comprehensiveness of error messages, physical placement of critical indicators or buttons, use of auditory signals, training devices, user documentation, training materials, and Computer Based Training (CBT) to be included in the system.IDPriorityRequirements StatementAcceptance CriteriaSourceBR IDSystem Environment RequirementsThis section specifies the requirements, if any, regarding the environment in which the system must operate. These include, at a minimum, the computer hardware and operating system on which the software must run.IDPriorityRequirements StatementAcceptance CriteriaSourceBR IDComputer Resource RequirementsThis section identifies the computer resources that constitute the environment of the system (as for a software system) or components of the system (as for a hardware-software system). Computer Hardware Requirements: This subsection shall specify the requirements, if any, regarding computer hardware that must be used by, or incorporated into, the system. It includes, as applicable, number of each type of equipment, type, size, capacity, and other required characteristics of processors, memory, input/output devices, auxiliary storage, communications and/or network equipment, and other required puter Hardware Resource Utilization Requirements: This subsection shall specify the requirements, if any, of the system’s computer hardware resource utilization, such as maximum allowable use of processor capacity, memory capacity, input/output device capacity, auxiliary storage device capacity, and communications/network equipment capacity. The requirements (e.g., percentage of the capacity of each computer hardware resource) shall include the conditions, if any, under which the resource utilization is to be puter Software Requirements: This subsection shall specify the requirements, if any, regarding computer software that must be used by, or incorporated into the system. Examples include operating systems, database management systems, communications and/or network software, utility software, input and equipment simulators, test software, and manufacturing software. Computer Communications Requirements: This subsection shall specify the additional requirements, if any, concerning the communications media that must be used by, or incorporated into, the system. Examples include geographic locations to be linked, configuration and network topology, transmission techniques, data transfer rates, gateways, required use times, type and volume of data to be transmitted/received, time boundaries for transmission/reception response, peak volumes of data, and diagnostic features. Communication requirements further define connectivity and access requirements within and between user locations, and between other groups and applications. Consider the following factors when defining communication requirements:Communication needs of the user and customer organizations.User organization’s existing and planned communications environment (e.g. telecommunications; LANs, WANs, and dial-up).Projected changes to the current communication architecture, such as the connection of additional local and remote sites.Limitations placed on communications by existing hardware and software including: user systems, applications that will interface with the product and organizations that will interface with the anization, government, and industry standards that define communication requirements and constraints. IDPriorityRequirements StatementAcceptance CriteriaSourceBR IDPerformance RequirementsWith the user’s information needs defined, it is now possible to specify in exact terms what the system should accomplish - its performance goals which measure the extent to which the system operates or performs as expected. System performance is usually determined by such things as: The extent to which the system meets organizational goals, such as system response time (i.e., how long does it take for the computer to respond to users during peak processing times), reliability, security procedures, etc.The quality of the information or output of the system, such as legible screen displays or document appearance.Achievement of performance goals is easily measured, but the benefits of achieving them are usually more difficult to ascertain in the short term. These benefits, however, are often extremely vital to the long-term success of the organization.Generally, it is too easy to think of the end results of a system entirely in terms of the reports that are generated. When this is done, evaluations of success and/or system efficiency/effectiveness stop short of ascertaining that the outputs or results of the system are actually used to control and improve business operations. It is, therefore, important that the current end products for any present system be stated in business management terms and that, during this step, reviews include evaluations of whether the present system meets the business objectives established for the user organization.Estimate Volumes and Projected Growth. It is also important to estimate volumes and projected growth. The purpose of this task is to provide the data required for assessment of equipment (e.g., personal computers, servers, etc.) required, network requirements, system processing time, and other technical items. The peak and average volume estimated include input transactions, inquiries, reports and other outputs and record volumes for permanently stored records. These volume and growth estimates are normally recorded on the input, output, and record documentation described above.Volume increases may occur more rapidly in the first few operating cycles following the pilot implementation until a steady state of the new system is reached. There are several reasons for this: Growth in volumes often occurs as additional modules of the system are implemented.Growth in volumes often occurs as the system is implemented for additional units of the organization.The system may maintain history for a fixed period of time (e.g., three years) causing record volume increases due to a buildup of historical data for the entire fixed period.Volume estimates may also be required for conversion data. Any purification efforts required should be planned and initiated in light of these conversion volume estimates.IDPriorityRequirements StatementAcceptance CriteriaSourceBR IDData Conversion & Migration RequirementsThis section specifies all of the data conversion and mitigation requirements for each functional area that must be converted.IDPriorityRequirements StatementAcceptance CriteriaSourceBR IDLogistics Related RequirementsThis section specifies the system requirements, if any, concerned with the logistics considerations. These considerations may include system maintenance, software support, and impacts on existing facilities and equipment.IDPriorityRequirements StatementAcceptance CriteriaSourceBR IDDisaster Recovery and Back-up RequirementsThis section specifies the system requirements for any disaster recovery efforts. In addition, this section should include the back-up requirements for daily use as well as for disaster recovery.IDPriorityRequirements StatementAcceptance CriteriaSourceBR IDOther RequirementsThis section specifies additional system requirements, if any, not covered in the previous sections. Examples include requirements for system documentation, user procedure manuals, instructions, if not covered in other contractual documents. IDPriorityRequirements StatementAcceptance CriteriaSourceBR ID ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download