Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Functional Requirements - Excel by liuqingyan

VIEWS: 53 PAGES: 16

									                                    Definitions/Abbreviations/Acronyms
     Acronym/Term                                                           Meaning
Account Executive          The Representative appointed by the Contractor who is responsible for the daily management and
                           administrative functions of the Contract from the Contractor's perspective
BAFO                       Best and Final Offer
CEU                        Continuing Education Units
COMAR                      Code of Maryland Regulations available on line at www.dsd.state.md.us.
Contract                   The Contract awarded to a successful Offeror pursuant to the RFP. Please refer to attachment A in
                           the RFP.
Contract Administrator     The State Representative for the project designated in Section 1.8 and who is primarily responsible
                           for Contract administration functions.
EMAIS® -                   electronic Maryland Ambulance Information System
EMS                        Emergency Medical Services
EMSOP                      a jurisdictional EMS operational program approved under COMAR 30.03.02 or an institution,
                           agency, corporation, or other entity that is licensed by MIEMSS as a commercial service under
                           Education Article § 13-515, Annotated Code of Maryland
EPINS                      Electronic Provider Identification Number System
IT                         Information Technology
MAIS                       Maryland Ambulance Information System
MIEMSS                     Maryland Institute for Emergency Medical Services Systems
MBE                        Minority Business Enterprise certified by the Maryland State Department of Transportation under
                           COMAR 21.11.03.
MESSR                      Maryland Emergency Service Student Registry
MPPR                       Maryland PreHospital Provider Registry
NEMSIS                     National Emergency Medical Services Information System
Offeror                    An entity that submits a proposal in response to this RFP
Procurement Officer        The State representative designated in Section 1.7, who is responsible for the Contract, determining
                           scope issues, and is the only State representative that can authorize changes to the Contract.
                           MIEMSS may change the Procurement Officer at any time by written notice to the Contractor.

System                     For the purpose of the requirements document, the term "System" refers to the software,
                           applications, databases)), necessary utility programs and toolkits that provide the required
                           functionality, and which the offeror is authorized to sell and license to customers.

                           It excludes software that the vendor cannot license to the customer or other software already owned
                           by the customer and which is not part of the vendor product offering.




     Request for Proposals: Purchase and Implementation of an Electronic Patient Care Reporting System for the State of
                                                        Maryland
                                                      Page 1 of 16
                                                Statewide Human Resources Information System
                                       Attachment I - Functional, Technical, Reports and Forms Requirements




                                                 Requirements Matrix – Introduction
The purpose of this document is to provide Offerors a detailed list of requirements necessary to support future EPCR System functions and
processes. The terms below are used through the matrix and are defined below to ensure the correct intepretation for the purposes of this
document.
"Shall vs. Should" - The State uses the word "shall" to refer to must have requirements, and "should" to refer to desired functionality.

System - For the purpose of the requirements document, the term "System" refers to the software, applications, database(s)), necessary utility
programs and toolkits that provide the required functionality, and which the offeror is authorized to sell and license to customers.
It excludes software that the vendor cannot license to the customer or other software already owned by the customer and which is not part of the
vendor product offering.

Notify refers to the ability to produce notices and submit via mail, electronic mail and workflow. Notifications sent to employees, candidates,
contractors or other persons track in the database must include the ability to mail hard copy.

                                                                   Instructions
Outlined below are specific instructions on how to complete each requirement.

1 Please check row heights on the worksheets to insure you can read all the text contained in each cell. Resize row heights if necessary.
2 Do not change the order of lines within the spreadsheets.
3 Limit your response to 255 characters per cell.

Requirement# - This column indicates the State’s unique identifier for each requirement. The letters indicate the functional area and the number
indicates the number within that functional area.

Function - This column indicates the broad functional area of functional or technical requirements into which requirements are grouped.

Basic Functions - Responses in this section should reflect the Offeror’s ability to provide a basic set of criteria to establish a functional statewide

Operational and Reporting Features - The Offeror shall describe their reporting capability and operational features as specified.

Security - The Offeror must respond to following mandatory Security Requirements.

MPPR - Maryland Pre-Hospital Provider Registry (MPPR) and Maryland Emergency Service Student Registry (MESSR). This section describes

EPINS - EPINS (Electronic Provider Identification Number System) This section is applicable only if MIEMSS elects to purchase the MPPR
component. EPINS is an online computer system that provides the official, universal method to assign seven digit Provider ID numbers in
Maryland. This number is also the provider’s ID number in the licensure and education system of MIEMSS and the Maryland Fire and Rescue
Institute (MFRI). Through an online application page, information is collected about the applicant and a seven digit provider number is issued,
verifying non-duplication by use of the applicant's social security number. After a Maryland Provider Number is generated, it is then the applicant's
provider number for their entire career as an emergency services provider in Maryland.
EPINS’ primary role is to issue Maryland provider numbers to those who are not licensed or certified EMS providers within the state of Maryland.
The EPINS number will then become their identity in any ePCR reports generated by that provider. The EPINS number will also be used to identify
the provider in any ePCR as part of the crew, and/or on scene of an incident.
The EPINS provider database interfaces and references with the Maryland Provider Registry (MPPR) to ensure non-duplication of provider
numbers should a provider with an existing EPINS number become EMS licensed after the issuing of the EPINS number. However, the MPPR
does not allow for the insertion of non-EMS provider information.


Description – This column documents the State’s detailed requirement.


Offerors must respond to each requirement by placing and "X" in the appropriate column. Any explanation, and requested details
should be supplied in the comments section of the matrix. If you require additional space, you should reference the appropriate
attachment number in the comments section.

Out of Box – The software achieves this requirement without making ANY modification to it. Users need only use standard features or choose
from a range of defined parameters to achieve the functionality.
                                                 Statewide Human Resources Information System
                                        Attachment I - Functional, Technical, Reports and Forms Requirements




Configuration – The software achieves this requirement by requiring that some configuration (but not customization) is done. Configuration is
defined as using the vendor’s toolset to tailor the system (e.g., adding/moving one or more fields, defining rules or using APIs). This configuration
does NOT involve creating an external application, customized code or system exit to meet the requirement; No periodic maintenance is required
to keep this functionality working when maintenance packs/future release sets are applied.

Independent Module or Third Party – The Offeror’s software meets this requirement through a separate module integrated with the core
application written by either the Offeror or a Third-Party vendor but supported by the Offeror. Please indicate the 3rd Party Software Vendor, the
software and version being provided in the comments column.

Planned Capability and Timeframe – The Offeror’s software does not currently meet this requirement; however, the Offeror is currently
developing this capability within their software. Supply the date by which the Offeror will make this capability available within its software.

Modification (Estimate Effort Level in Comments) – The Offeror’s software does not meet this requirement; however, the Offeror knows that
they can meet this requirement through a modification. Provide an estimate of the number of total man hours required to meet this requirement in
the comments column.

Not Met – The Offeror’s software does not meet this requirement.

Comments – Any notes or comments the Offeror feels are significant and important for the State’s evaluation of their ability to meet a requirement.
Functional Requirements                                                                                                                         To Be Completed by Offeror
                                                                                                                                                                                            Modification
                                                                                                                                                                                           (Estimate the
                                                                                                                                                     Independent          Planned        Level of Effort by
                                                                                                                  Delivered out of                      Module           Capability         hours in the      Not
Req.#     Function                                              Description                                           the Box        Configuration    or 3rd Party     and Timeframe        Comments)         Met   Comments
FR.1 1) Basic Criteria      The system shall have achieved and maintain a status of NEMSIS Gold
                            Compliance, and accept the Maryland EMS Dataset.
FR.2   1) Basic Criteria    The system shall provide data export to the Maryland Registries (Trauma, Burn,
                            Stroke, STEMI, etc) for pre-populating pre-hospital data elements in the Trauma
                            Registry, linking patient outcomes with ambulance service trauma responses,
                            and providing an integrated Trauma Module for data collection and reporting
                            compliant with the National Trauma Data Bank (NTDB) National Trauma Data
                            Standard.
FR.3   1) Basic Criteria    The system shall have an electronic patient care reporting (ePCR) component
                            that MIEMSS can freely distribute to Maryland licensed EMSOPs as they choose
                            to implement an ePCR.
FR.4   1) Basic Criteria    The system shall allow all electronic EMS data reports to prominently display on
                            each patient care report an unique [11] character report identifier in which:
                            a) The first three characters shall show the unique identifier assigned to the EMS
                            operational program by MIEMSS;
                            b) The fourth and fifth characters shall show the year of the event reported on;
                            and
                            c) The remaining 6 characters shall show the EMS operational program
                            sequential report number which shall be reset to zero for the first event reported
                            on each calendar year.


FR.5   1) Basic Criteria    In order for any field provider to login and use the ePCR application, the provider
                            must enter their Maryland EMS Provider Number (7 Digits) and a password.
                            Upon entry of this information, the application shall verify the EMS Providers
                            current license and certification, and jurisdiction affiliation against the MPPR.

FR.6   2) Security        The System shall render individually identifiable health information to be
       Requirments        unusable, unreadable, or indecipherable to unauthorized individuals when such
                          information is transmitted in the nationwide health information network or
                          physically transported outside of the secured, physical perimeter of MIEMSS or a
                          health care provider so that it shall not be unsecured health information under
                          13402(h)(1) of the Health Information Technology for Economic and Clinical
                          Health Act of 2009.
FR.7   3) System          The System shall provide easy to use help tools with key word search capability
       Requirments        (wild card searches are not considered user friendly.)
FR.8   4) Operational &   The system shall have an on-line help ―user’s guide‖ implemented with the
       Reporting Features System.

FR.9   4) Operational &   The system shall contain an integrated method of communication between
       Reporting Features system administrators and end users within Maryland.

FR.10 4) Operational &   The system shall log a non-received (or non-answered) communication
      Reporting Features message in the real time records management system as undelivered and alert
                         administrators to that condition.
FR.11 4) Operational &   The system shall be able to quickly, easily, and securely access and
      Reporting Features appropriately display previously stored data from the central EMS database in a
                         real-time capacity.
FR.12 4) Operational &   The system shall allow for dynamic and customized analysis without additional
      Reporting Features programming (flexibility in analysis).




                                                               Request for Proposals: Purchase and Implementation of an Electronic Patient Care Reporting System for the State of Maryland
                                                                                                                     Page 4 of 16
Functional Requirements                                                                                                                        To Be Completed by Offeror
                                                                                                                                                                                             Modification
                                                                                                                                                                                            (Estimate the
                                                                                                                                                      Independent          Planned        Level of Effort by
                                                                                                                 Delivered out of                        Module           Capability         hours in the      Not
Req.#      Function                                       Description                                                the Box        Configuration      or 3rd Party     and Timeframe        Comments)         Met   Comments
FR.13 4) Operational &   The system shall contain one or more tools for data mining capability for
      Reporting Features administrative level users.

FR.14 4) Operational &   The system shall allow approved users to generate statistical information from
      Reporting Features the aggregate EMS data, through an Internet-based query tool. MIEMSS shall be
                         able to determine user levels for this query tool without the need for additional
                         programming
FR.15 4) Operational &   The system shall allow provide both standard reports as well as ad hoc
      Reporting Features reporting.

FR.16 4) Operational &   The system shall have a performance improvement (PI) component capable of
      Reporting Features being used at the individual EMSOP level. The System must allow user
                         customization for QA/PI projects, Review patient documentation, Perform call
                         reviews, Multi-level user levels specific to PI (i.e. peer review, agency leadership,
                         and medical director), and have the ability to document and report PI within the
                         System.
FR.17 4) Operational &   The system shall allow a capability for both standard and ad hoc reports at both
      Reporting Features the agency level and the statewide level based on log-in access.

FR.18 4) Operational &   The system shall allow for the development of new standard reports by MIEMSS
      Reporting Features without having to engage the vendor for such report development.

FR.19 4) Operational &   The system shall allow for multiple methods of incident reporting within the same
      Reporting Features incident, such as point and click, pull down menus and narratives.

FR.20 4) Operational &   The ePCR application shall provide anatomical diagrams for incident tracking
      Reporting Features and reporting.

FR.21 4) Operational &   The system shall be easily navigated, such that a paramedic can complete a
      Reporting Features Patient Care Report, including Advanced Life Support documentation, within an
                         average of a twenty (20) minute time limit.
FR.22 4) Operational &   The ePCR application must be able to maintain Joint Commission compliance
      Reporting Features for electronic data interchange with healthcare facilities.

FR.23 4) Operational &   The ePCR application must be able to be track and allow access to users based
      Reporting Features on Maryland Provider number, Jurisdictional affiliation, and current certification
                         status.
FR.24 4) Operational &   The ePCR application must be able to track patient care reports by time of
      Reporting Features completion, specifically those with a time span in excess of 24 hours between
                         the completion of the incident and the submission of the ePCR.
FR.25 4) Operational &   The ePCR application must be able to link reports for round trip transports on
      Reporting Features the same patient and auto populating repetitive patient data.

FR.26 4) Operational &   The ePCR application must be able to accept Maryland Protocols.
      Reporting Features

FR.27 4) Operational &   The system shall allow for support documentation to be printed on demand.
      Reporting Features




                                                                Request for Proposals: Purchase and Implementation of an Electronic Patient Care Reporting System for the State of Maryland
                                                                                                                      Page 5 of 16
Functional Requirements                                                                                                                        To Be Completed by Offeror
                                                                                                                                                                                             Modification
                                                                                                                                                                                            (Estimate the
                                                                                                                                                      Independent          Planned        Level of Effort by
                                                                                                                 Delivered out of                        Module           Capability         hours in the      Not
Req.#        Function                                            Description                                         the Box        Configuration      or 3rd Party     and Timeframe        Comments)         Met   Comments
FR.28 4) Operational &     The administration tool must include the capability to activate/inactivate each of
      Reporting Features the fields that will be used in the System. The administration tool must include
                           the capability to modify the dataset above/beyond the NEMSIS dataset without
                           compromising NEMSIS compliance.
FR.29 4) Operational &     The System shall ensure that patient care documentation can be provided to the
      Reporting Features receiving hospital at the time of transfer of care. Detail how this will be
                           accomplished with the System being offered and describe any resources that the
                           state will need to provide to achieve this objective.
FR.30 4) Operational &     The System shall provide capability for a knowledge base, reference articles and
      Reporting Features FAQ pre-populated with information about the System. These capabilities shall
                           be extensible so that MIEMSS can add additional KB entries, articles and FAQs
                           to the System.
FR.31 5) EPINS             Intentionally Blank
FR.32 6) Licensing and     The system shall interface with or incorporate the requirements of EPINS
      Certification (MPPR) (Electronic Provider Identification Number System) as detailed in Technical
                           Requirements.
FR.33 6) Licensing and     The system shall track student progress through EMS courses (initial or
      Certification (MPPR) recertification) with instructor input. Once completed and certified, providers are
                           certified and eligible to use the ePCR application.
FR.34 6) Licensing and     The system shall track certified providers' continuing education. It should accept
      Certification (MPPR) input in a variety of formats and align with the current Learning Management
                           System (LMS) application.
FR.35 6) Licensing and     The system shall track provider certification records and dates, all of which must
      Certification (MPPR) be viewable via the web. The certification records Web interface must provide
                           the capability for provider’s to change their address and personal profile
                           information.




                                                                Request for Proposals: Purchase and Implementation of an Electronic Patient Care Reporting System for the State of Maryland
                                                                                                                      Page 6 of 16
Functional Requirements                                                                                                                            To Be Completed by Offeror
                                                                                                                                                                                               Modification
                                                                                                                                                                                              (Estimate the
                                                                                                                                                        Independent          Planned        Level of Effort by
                                                                                                                     Delivered out of                      Module           Capability         hours in the      Not
Req.#        Function                                          Description                                               the Box        Configuration    or 3rd Party     and Timeframe        Comments)         Met   Comments
FR.36 6) Licensing and     In order to perform EMS services in Maryland, all providers must be currently
      Certification (MPPR) certified. As each provider completes their training, a review is made for any
                           compliance issues. Providers with compliance issues are currently stored in an
                           Access database. When a provider completes a MESSR form (a form used to
                           capture vital information for each applicant), there are three questions (related to
                           some type of criminal history), if which are answered ―correctly,‖ flags the
                           provider in the MPPR/MESSR system with a compliance issue. Any provider
                           flagged with a compliance issue is forwarded to the MIEMSS Compliance
                           Officer. The MPPR/MESSR capability must incorporate the following data points
                           in the MPPR/MESSR database while automating a number of current manual
                           processes:
                           a. Compliance reported date and reason
                           b. Date letter sent
                           c. Response received (from applicant)
                           d. Incident Review Committee
                           e. Provider Review Panel
                           f. EMS Board
                           g. Non-Compliance Notice (public document – not posted)
                           h. Case Conference
                           i. Hearing Scheduled (Office of Administrative Hearings)
                           j. Appeal
                           k. Public Order, which should also automatically set the ―Public Order‖ check box
                           on the main MPPR/MESSR provider screen
                           l. Settlement Agreement
                           m. Confidential Settlement Agreement
                           n. Compliance Resolved
                           o. Only users with the appropriate rights would have access to the Compliance
                           section, which is maintained with the existing ULS application. All users would
FR.37 6) Licensing and     see a pop-up window withthe ability to ―Contact Compliance office for more
                           The system shall provide the phrase approve administrative rights for
      Certification (MPPR) jurisdictions.

FR.38 6) Licensing and     The system shall provide the ability to provide interactive on-line continuing
      Certification (MPPR) education (e.g. protocol updates) with testing and user feedback.

FR.39 6) Licensing and     The system shall provide the ability to allow providers to change their address,
      Certification (MPPR) view Continuing Education records, and change/add/delete affiliations pending
                           jurisdictional approval.
FR.40 6) Licensing and     The system shall provide the ability to generate the necessary letters for any
      Certification (MPPR) request that requires correspondence from MIEMSS.

FR.41 6) Licensing and     The system shall provide the ability for allowing providers to register for classes,
      Certification (MPPR) seminars, conferences, obtain exam results, renew certifications (with automatic
                           jurisdictional notification), and apply for reinstatement and reciprocity in real time.

FR.42 6) Licensing and     The system shall provide users with a receipt for any on-line transactions.
      Certification (MPPR)

FR.43 6) Licensing and     The system shall provide the ability for paperless practical examinations, with
      Certification (MPPR) results automatically entered to the student record from the testing site, and to
                           allow remote processing of a class.




                                                                  Request for Proposals: Purchase and Implementation of an Electronic Patient Care Reporting System for the State of Maryland
                                                                                                                        Page 7 of 16
Technical Requirements                                                                                                                         To Be Completed by Offeror
                                                                                                                                                                                           Modification
                                                                                                                                                                                          (Estimate the
                                                                                                                                                    Independent          Planned        Level of Effort by
                                                                                                                 Delivered out of                      Module           Capability         hours in the      Not
Req.#     Function                                             Description                                           the Box        Configuration    or 3rd Party     and Timeframe        Comments)         Met   Comments
TR.1 1) Basic Criteria     The system shall support additional user definable data elements as seen
                           necessary by MIEMSS or EMSOPs (Patient Priority, Trauma Category,
                           Exceptional Call, etc.).
TR.2   1) Basic Criteria   The system shall be capable of being provided as: a fully hosted system, using
                           dedicated lines, dedicated hardware, a fully in-house (Statewide internal
                           network) system or any combination of these systems. Describe how your
                           System meets this requirement.
TR.3   1) Basic Criteria   The system shall be a standard commercial software product that uniquely
                           integrates all of the underlying functionality to minimize development and
                           customization considerations.
TR.4   1) Basic Criteria   The system shall be a web based data collection, analysis, and reporting tool
                           accessible by multiple levels of users based on assigned role codes.
TR.5   1) Basic Criteria   The system shall have the ability for its owners to access data by open data
                           base connectivity (ODBC), standard reports, and ad-hoc reports. The canned
                           reports feature should be able to be updated, at a minimum, by MIEMSS.

TR.6   1) Basic Criteria   The system shall allow users (EMSOPs) to have independent access to their
                           own data (i.e. data they have submitted to the System.)
TR.7   2) Security         The system shall have the following authorization requirements:
       Requirments         a) An automated process to ensure that individual user sessions either time out
                           or initiate a password protected screen saver after a period of thirty (30) minutes
                           of inactivity;
                           b) A documented process to ensure that access rights reflect changes in
                           employee/contractor status within twenty-four (24) hours of the change;
                           c) A documented process to ensure that physical and logical access is
                           immediately disabled upon a change in employment status where appropriate;
                           d) An automated process to ensure that user ids are disabled after sixty (60)
                           days of inactivity unless they are extended through the explicit approval of the
                           Information Custodian (Note: Functional ids may be exempted from this
                           requirement);
                           e) A documented process to ensure that all default access capabilities are
                           removed, disabled, or protected to prevent unauthorized use;
                           f) A process/system to ensure that access privileges are traceable to a unique
                           user id;
                           g) An automated display, after a successful logon, showing the date and time of
                           last successful logon and the number of unsuccessful logon attempts since the
                           last successful logon.




                                                              Request for Proposals: Purchase and Implementation of an Electronic Patient Care Reporting System for the State of Maryland
                                                                                                                    Page 8 of 16
Technical Requirements                                                                                                                  To Be Completed by Offeror
                                                                                                                                                                                      Modification
                                                                                                                                                                                     (Estimate the
                                                                                                                                               Independent          Planned        Level of Effort by
                                                                                                          Delivered out of                        Module           Capability         hours in the      Not
Req.#      Function                                        Description                                        the Box        Configuration      or 3rd Party     and Timeframe        Comments)         Met   Comments
TR.8 2) Security      The system shall provide the following audit trail:
      Requirments     a) The following minimum set of events/actions must be logged and kept as
                      required by State and Federal laws/regulations:
                      i. Additions, changes or deletions to data produced by IT systems;
                      ii. Identification and authentication processes;
                      iii. Actions performed by system operators, system managers, system engineers,
                      technical support, data security officers, and system administrators;
                      iv. Emergency actions performed by support personnel and highly privileged
                      system and security resources.
                      b) The audit trails must include at least the following information:
                      i. Date and time of event;
                      ii. User id of person performing the action;
                      iii. Asset or resource name and type of access;
                      iv. Success or failure of event;
                      v. Source (terminal, port, location, IP address) where technically feasible.


TR.9   2) Security    The sysetm shall have an authorization process which specifically grants access
       Requirments    to information ensuring that access is strictly controlled, audited, and supports
                      the concepts of ―least possible privileges‖ and ―need-to-know‖.

TR.10 2) Security     The system shall have an authentication process to verify the identity of users
      Requirments     prior to initiating a session or transaction.
TR.11 2) Security     The system shall have an audit trail process to ensure accountability of system
      Requirments     and security-related events.
TR.12 2) Security     The system shall have a process for ensuring that all systems have the ability to
      Requirments     log and report specific security incidents and all attempted violations of system
                      security. This capability must be enabled at all times.
TR.13 2) Security     The system shall have the processes to establish, manage, and document user
      Requirments     id and password administration.
TR.14 2) Security     The system shall have a segregation of the functions of system administration
      Requirments     and security administration to provide separation of duties.
TR.15 2) Security     All users must be uniquely identified. Group or shared ids are prohibited unless
      Requirments     they are documented as ―Functional ids‖. Functional ids are user accounts
                      associated with a group or role that may be used by multiple individuals (e.g.,
                      Emergency Problem/Fix Ids) or that are associated with a particular production
                      job process. Passwords associated with functional ids are exempt from the
                      password restriction on sharing and change requirements specified below.

TR.16 3) System       The system shall support additional user definable data elements as seen
      Requirments     necessary by MIEMSS or EMSOPs (Patient Priority, Trauma Category,
                      Exceptional Call, etc.).
TR.17 3) System       The system shall have an integrated method to ensure data submitted by an
      Requirments     EMS agency is valid (i.e. is tested against the NHTSA/NEMSIS standard at the
                      user interface level).
TR.18 3) System       The system shall utilize probabilistic back-end data linkages to prevent the
      Requirments     duplication of pre-hospital EMS data by multiple EMSOPs (NOTE: A patient ID is
                      not a suitable key for this System).
TR.19 3) System       The system shall provide multiple logic checks and edits on data fields to ensure
      Requirments     data integrity.




                                                         Request for Proposals: Purchase and Implementation of an Electronic Patient Care Reporting System for the State of Maryland
                                                                                                               Page 9 of 16
Technical Requirements                                                                                                                    To Be Completed by Offeror
                                                                                                                                                                                       Modification
                                                                                                                                                                                      (Estimate the
                                                                                                                                                Independent          Planned        Level of Effort by
                                                                                                            Delivered out of                       Module           Capability         hours in the      Not
Req.#       Function                                      Description                                           the Box        Configuration     or 3rd Party     and Timeframe        Comments)         Met   Comments
TR.20 3) System        The system shall be accessed by any authorized user via the Internet. It should
      Requirments      be able to be accessed by average EMS users.
TR.21 3) System        The system shall operate efficiently with all levels and types of Internet
      Requirments      connections from dial up to broadband.
TR.22 3) System        The system shall be compatible with MS Windows 2000 and later versions of
      Requirments      Windows (XP / Vista / Win7) as well as server operating systems from MS
                       Windows Server 2003 through Windows Server 2008.
TR.23 3) System        The system should be scalable and have a standard that can be expanded to
      Requirments      encompass future data systems.
TR.24 3) System        The system shall be able to handle multiple users at one time with no record
      Requirments      locking. Offerors should document their ability to manage Maryland’s volume
                       across various internet access speeds as they would want to be noted in the
                       vendor proposal
TR.25 3) System        The system shall provide multiple levels of user access based on login.
      Requirments
TR.26 3) System        The system shall have the ability to import and export data from other data
      Requirments      collection systems if those applications utilize the most recent NEMSIS - NHTSA
                       EMS XML and XSD’s.
TR.27 3) System        The system shall be capable of receiving data that also meets the technical
      Requirments      format prescribed by the current NHTSA EMS database XML and XSDs.

TR.28 3) System        The System shall have the ability to receive and load data into the database with
      Requirments      the same level of quality checks that is used for data collection through System
                       user interfaces (e.g., invalid or incomplete data should be prevented from
                       entering the state database during data import processes.) Data rejected during
                       the import process should be reported with sufficient detail to determine the
                       causes of rejection.
TR.29 3) System        The system shall be optimized to allow fast screen re-draws. Offerors will
      Requirments      document their ability to manage Maryland’s volume across various internet
                       access speeds as they would want to be noted in the final contract.

TR.30 3) System        The system shall have the capability to quickly, easily, and securely send data to
      Requirments      a central EMS database for collection and reporting in a real time capacity.

TR.31 3) System        The system shall will provide a user friendly and easily navigated Graphical User
      Requirments      Interface.
TR.32 3) System        The Contractor will provide a web-based user interface/System, it must meet the
      Requirments      following requirements:
                       a) It must be ―Browser agnostic‖ and compatible with multiple web browsers,
                       including but not limited to, MS Internet Explorer, Netscape Navigator, AOL,
                       Opera, yahoo, Mozilla, Firefox, among other mainstream browsers.
                       b) It must be capable of providing128-bit SSL encryption
                       c) It must be built on current J2EE standards

TR.33 3) System        The System will not be based on proprietary technology, in order to ensure cost
      Requirments      efficiency of ownership and connectivity throughout the State of Maryland, and to
                       minimize the risk of potential failure due to the network’s configuration. Explain
                       how your product meets this requirement.




                                                          Request for Proposals: Purchase and Implementation of an Electronic Patient Care Reporting System for the State of Maryland
                                                                                                               Page 10 of 16
Technical Requirements                                                                                                                         To Be Completed by Offeror
                                                                                                                                                                                            Modification
                                                                                                                                                                                           (Estimate the
                                                                                                                                                     Independent          Planned        Level of Effort by
                                                                                                                 Delivered out of                       Module           Capability         hours in the      Not
Req.#       Function                                            Description                                          the Box        Configuration     or 3rd Party     and Timeframe        Comments)         Met   Comments
TR.34 3) System             The system must be an open, standards based and fully documented
      Requirments           architecture. These terms are defined as follows: open - an architecture that
                            allows for the addition, upgrade and/or swap of integrated system components
                            with custom in-house components or third party components without additional
                            cost; standards based - software that employs the use of commonly accepted
                            standards for both its internal components (i.e. j2ee, rbms) and its external
                            components (i.e. soap, rest, ftp, etc.); fully documented - software with an API
                            that is documented extensively and accurately so as to allow third party
                            developers to extend, add to the system, or import/export data easily.

TR.35 3) System             The Offeror should state what hardware requirements are necessary to achieve
      Requirments           multi-user and other System performance objectives.
TR.36 3) System             Maintenance, new versions, upgrades, security updates, and patches must be
      Requirments           easily deployable, preferably via an internet interface.
TR.37 3) System             Support should be offered via multi forms of communication to include toll free
      Requirments           telephone line, e-mail, live on-line support, and on-line knowledge base support.

TR.38 3) System             System Issues shall be classified as follows:
      Requirments           a) CRITICAL (Priority 1) — The problem results in extremely serious
                            interruptions to MIEMSS and/or EMSOPS operations. It has affected, or could
                            affect, the entire user community. Tasks that should be executed immediately
                            cannot be executed because of a complete crash of the system or interruptions
                            in main functions of the production system. Data integrity is compromised and
                            the service request requires immediate processing. Security related issues that
                            can compromise the access to or functions of the System or its data.
                            b) URGENT (Priority 2) — The problem results in serious interruptions to normal
                            operations or will negatively impact MIEMSS and/or EMSOP operations.
                            Important tasks cannot be performed, but the error does not impair essential
                            operations, processing can still continue in a restricted manner, and data
                            integrity may be at risk. The service request requires timely processing, because
                            the malfunction could cause serious interruptions to critical processes or
                            negatively impact operational decisions.
                            c) IMPORTANT (Priority 3) — The problem causes interruptions in normal
                            operations. It does not prevent operation of a system, or there could be minor
                            degradation in performance. The error is attributed to malfunctioning or incorrect
                            behavior of the software.
                            d) MINOR (Priority 4) — The problem results in minimal or no interruptions to
TR.39 3) System             normal operations (no operational impact). The issue consists of ―how to‖
                            For System maintenance the Contractor will provide on-call support twenty-four
      Requirments           hours a day, seven days a week for the System based on the priority levels set
                            forth above as follows:
                            a) Priority 3 and 4 classifications – one (1) business day.
                            b) Priority 1 and 2 classifications – one (1) hour.

TR.40 4) Operational &   The system shall allow for data to be exported to an outside analysis tool (.i.e.
      Reporting Features SPSS, SAS, Access, Excel) via an ODBC or a similar connection, or by one or
                         more data export tools provided by the Offeror. Describe methods of export and
                         tools to be provided.
TR.41 4) Operational &   The system shall have the ability to create and alter tables and views in the
      Reporting Features reporting database.




                                                               Request for Proposals: Purchase and Implementation of an Electronic Patient Care Reporting System for the State of Maryland
                                                                                                                    Page 11 of 16
Technical Requirements                                                                                                                      To Be Completed by Offeror
                                                                                                                                                                                          Modification
                                                                                                                                                                                         (Estimate the
                                                                                                                                                   Independent          Planned        Level of Effort by
                                                                                                             Delivered out of                         Module           Capability         hours in the      Not
Req.#      Function                                          Description                                         the Box        Configuration       or 3rd Party     and Timeframe        Comments)         Met   Comments
TR.42 4) Operational &   The system shall shall have the ability to operate on both production servers and
      Reporting Features reporting or BI (business intelligence) servers in order to minimize server slow
                         down during peak usage times.
TR.43 4) Operational &   The ePCR application must be able to be hosted on multiple mobile devices
      Reporting Features including but not limited to laptops and notebooks, PDA, and handheld devices.




                                                             Request for Proposals: Purchase and Implementation of an Electronic Patient Care Reporting System for the State of Maryland
                                                                                                                  Page 12 of 16
                              REPORTS                                                                              To Be Completed by Offeror
Report         Report Name                  Report Description               Delivered out of   Modification to an       Custom         Not                Comments
Number                                                                           the Box         existing report                        Met If Delivered, provide Report Name and
                                                                                                                                                            Number
Report 1   Jurisdictional Activity Jurisdictional Activity Overview report
           Overview                provides an overview of county,
                                 company, or unit level activity based
                                 on dispatch, certification, priority,
                                 outcome status, and first due unit
                                 information over time.

Report 2   Time Distributions by Time Distributions by Call Outcome
           Call Outcome          report shows average times (in
                                 minutes) for each time interval
                                 captured within the
                                 application/system. Calculations of
                                 average times are based on records
                                 with valid beginning and ending times
                                 for a specific time interval. For
                                 example, average minutes between
                                 an EMS unit’s arrival at the response
                                 location and first direct contact with a
                                 patient; or average minutes between
                                 an EMS unit’s arrival at a response
                                 location and departure from that
                                 location.
Report 3   Time Distributions by This reportshall provide the ability to
           Day of Week           review EMS resource usage by Hour
                                 of Day and Day of Week. The data
                                 view can be changed to evaluate
                                 activity for a particular
                                 county/jurisdiction/EMSOP, company
                                 or unit, or Care Levels over time. The
                                 distribution of calls by Hour of Day
                                 shall be based on the call times, i.e.
                                 Ambulance call time.




                        Request for Proposals: Purchase and Implementation of an Electronic Patient Care Reporting System for the State of Maryland
                                                                             Page 13 of 16
Report         Report Name                 Report Description              Delivered out of   Modification to an   Custom        Not                  Comments
Number                                                                         the Box         existing report                   Met   If Delivered, provide Report Name and
                                                                                                                                                       Number
Report 4   Injury Demographics   The Injury Demographics report shall
                                 allow a user to view injury related
                                 data from varying perspectives. This
                                 report shows the
                                 distribution of injury types by age
                                 groups, gender, ethnicity, injury
                                 causes, safety equipment used,
                                 county/jurisdiction/EMSOP, company,
                                 or unit, care levels provided, trauma
                                 mechanisms and trauma identifiers
                                 reported or entered within the system.

Report 5   Medical               The Medical Demographics report
           Demographics          provides the ability to review
                                 aggregated data for records of a
                                 medical (non-injury related) nature. It
                                 includes distribution of medical calls
                                 by age groups, gender, ethnicity, care
                                 levels provided,
                                 county/jurisdiction/EMSOP, company
                                 or unit, and signs/symptoms, or
                                 conditions.
Report 6   Skills Overview       This report provides an overview of
                                 procedure attempts and successes
                                 as well as other types of care
                                 rendered by
                                 county/jurisdiction/EMSOP, company,
                                 or unit, injury or medical call types,
                                 and care levels over time.

Report 7   Medications           The Medications report shows the
                                 distribution of medications
                                 administered by
                                 county/jurisdiction/EMSOP, company,
                                 or unit, injury or medical call types,
                                 and care levels over time.

                         Request for Proposals: Purchase and Implementation of an Electronic Patient Care Reporting System for the State of Maryland
                                                                              Page 14 of 16
Report          Report Name                  Report Description              Delivered out of   Modification to an   Custom      Not                  Comments
Number                                                                           the Box         existing report                 Met   If Delivered, provide Report Name and
                                                                                                                                                       Number
Report 8    Transport Reasons /    The Transport Reasons /
            Communications         Communications report shows the
                                   distribution of total calls by the
                                   reasons receiving facilities were
                                   chosen, as well as the quality of EMS
                                   radio communications based on the
                                   Reason Hospital Chosen.
Report 9    Special Responses      The Special Responses report shows
                                   the distribution of calls marked or
                                   reported as Exceptional Call, Haz Mat
                                   Call, Multiple Patients Seen, and/or
                                   Multiple Patients Transported.

Report 10   Assessment             The Assessment Overview report is
            Overview               the classifications of provider's
                                   assessment based on
                                   Signs/Symptoms and Conditions
                                   reported.
Report 11   Cardiac Overview       The Cardiac Overview report allows
                                   the users to review cardiac related
                                   data. This report shows cardiac or
                                   respiratory arrests, witnessed arrests,
                                   other arrhythmias reported, whom
                                   CPR was initiated by, as well as pre-
                                   hospital procedures and other care
                                   rendered.
Report 12   Hospital Interaction   The Hospital Interaction Review
            Review                 report is derived from the consulting,
                                   transferring and receiving facility
                                   codes. With this report, Hospital
                                   interaction data can be viewed over
                                   time, care levels, or by
                                   county/jurisdiction/EMSOP, company,
                                   or unit.




                         Request for Proposals: Purchase and Implementation of an Electronic Patient Care Reporting System for the State of Maryland
                                                                              Page 15 of 16
                                                                                                                                        To Be Completed by Offeror
 Req.#                               Module Description
                                                                                                                                                                    Modification
                                                                                                                            Independent                         (Estimate the Level
                                                                                     Delivered out of                      Module or Third   Planned Capability of Effort by hours    Not
                                                                                         the Box         Configuration         Party           and Timeframe     in the Comments)     Met   Comments
OM.1     FIRE RMS/NFIRS 5.0 Incident Reporting
OM.2     Module capable of monitoring inventory   based on data input into state
         database or ePCR application.
OM.3     Module capable of monitoring inventory based on data input into state
         database or ePCR application.
OM.4     Module to accept data from a Computer Aided Dispatch (CAD) system into a
         run report.
OM.5     Module capable of managing vehicle maintenance, apparatus, and equipment
         inventory.
OM.6     Module for EMSOPs that choose to utilize GPS and/or GIS capability.
OM.7     Module for mobile data collection




                                                    Request for Proposals: Purchase and Implementation of an Electronic Patient Care Reporting System for the State of Maryland
                                                                                                         Page 16 of 16

								
To top