Purpose of the Document .us



Appendix G - LMS/EMS InterfaceRequirements DocumentPrepared by:Brandon ShawProject #:Submitted to:Bob ChilcoteDate submitted4/29/2016Document version:V1.0Document HistoryVersionDateAuthorStatusRevision Descriptions0.112/3/15Brandon ShawInitial Draft0.212/22/15Brandon ShawSecond DraftAdded User Check web service information.1.04/29/16Brandon ShawPublishedAdded clarifications, removed unused sections.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 _Toc449688560 \h 4Acronyms PAGEREF _Toc449688561 \h 5Executive Summary PAGEREF _Toc449688562 \h 6Introduction PAGEREF _Toc449688563 \h 71.1Project Overview PAGEREF _Toc449688564 \h 7Business Model PAGEREF _Toc449688565 \h 81.1.1Organizational Profile PAGEREF _Toc449688566 \h 81.1.2High Level ‘As-Is’ Process Flow PAGEREF _Toc449688567 \h 81.1.3High Level ‘To-Be’ Process Flow PAGEREF _Toc449688568 \h 9Requirements Definition PAGEREF _Toc449688569 \h 101.2Overview PAGEREF _Toc449688570 \h 101.2.1Approach PAGEREF _Toc449688571 \h 101.3Detailed Requirements PAGEREF _Toc449688572 \h 101.3.1Business Requirements PAGEREF _Toc449688573 \h 101.3.2Input & Output Requirements PAGEREF _Toc449688574 \h 101.3.3Internal & External Requirements PAGEREF _Toc449688575 \h 17Purpose 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. 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.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 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.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.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.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.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).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.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, BEMSBR03HighThe LMS system shall provide the ability for DOH BEMS personnel to disable a practitioner user account. When a practitioner user account is disabled, the LMS shall not transfer data from that practitioner account to the DOH EMS Registry Web Service.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, BR02 ................
................

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

Google Online Preview   Download