HomeMy WebLinkAboutExhibit5All the functional requirements listed below are considered to be
the MINIMUM expected performance/requirements for each item.
Check each item in the appropriate box to indicate if your
product can provide this requirement as either: Out of the box,
as a customized option at additional cost, or not available at all.
Use the comments area to specify if your product exceeds this
requirement or can provide a similar result. Also, use this area
to provide estimates for custom options costs.
NO.
MINIMUM
REQUIREMENTS
AVAILABLE
OUT OF
THE BOX
AVAILABLE AS
CUSTOMIZED
OPTION AT AN
ADDITIONAL
COST
NOT
AVAILABLE
COMMENTS
ACCESSIBILITY
1.
Backend ePCR Software
includes a web -based
administrative tool that
allows the Agency to
add, modify, define sort
orders, or deactivate
lookups.
2.
Agency is able to
configure the Backend
ePCR Software via a
web -based interface to
limit the access to open
and close reports
according to user 'roles'.
This authority restriction
can be designated down
to the individual level.
3.
Program allows Agency
to assign application
security levels by person
and/or system defined
groups. (Firefighters
and/or Lieutenants
and/or Captains, and/or
Chiefs and/or working
groups, etc.)
.
4.
The ePCR System
MUST offer the ability to
create custom access
'roles' to the Backend
ePCR Software. These
roles can be defined
whereby the user will
only have "no view,
read-only, partial, or full"
edit access to certain
reports based on
parameters including
units or shifts. Any
ePCR accessed MUST
be tracked with
date/time and username
of person viewing or
printing an ePCR. This
role creation and
modification feature
MUST be through a
web -based interface.
5.
Staff access rights for
ePCR viewing and
ePCR modification can
be defined by the
agency through a web -
based interface. An
authorized administrator
can define factors
effecting who can view
or amend an ePCR
including by crew, shift,
and unit.
6.
The ePCR system must
allow the agency the
ability to configure all
'closed' reports as
'locked -out' and
unavailable for data
editing. However, the
agency can provide an
authorized user to
'unlock' a report for an
authorized edit entry.
7.
Through a web -based
tool, Agency has the
ability to manage system
access information for
users/personnel, e.g,
username and password
without requiring vendor
intervention.
8.
Through a web -based
tool, the Agency's QA
Officer and Medical
Director must have the
ability to audit a PCR.
9.
Transparency security is
supported, restricting
documents and/or
reports from users
without proper security
such that the documents
for which the user does
not have authority are
transparent to the user
and also any hypertext
links to these documents
are automatically
disabled.
10.
When logging on to the
backend system, a
screen is available to the
user notifying them of all
incomplete or open
reports for his/her unit
and shift. This list also
will include reports that
have not been received
by the backend, yet
dispatch by CAD. The
system will allow the
relevant user to search
cases (by date or unit
parameters) that they
have been assigned to,
without exposure to
other cases they have
not been assigned.
11.
The ePCR Mobile
Software MUST allow for
Agency -definable
content to be loaded
onto the mobile device,
such as PDF and HTML
file content. This
content should also be
easily accessible from
within the software by no
more than 2 clicks.
12.
All interfaces and
communications
between portable
devices and other
internal and external
sources are available 7
days a week, 24 hours a
day. List any
exceptions.
13.
The system must have a
rapidly accessible ePCR
listing screen. This
screen will expose all
ePCRs managed by the
system, including open
and closed reports as
well as a simple
mechanism to deliver
any of the reports.
14.
Product can support
multiple Agencies and
be able to differentiate
which alarm belongs to
which Agency; Example:
Miami services the
Village of Key Biscayne
Fire Department and
hosts their data. Each
agency's access to the
ePCR System can be
configured to be agency -
specific. When querying
the data, the product can
produce reports for each
Agency separately and
independently. Vendor
should provide separate
pricing for this capability.
15.
ePCR status changes
are maintainable by the
ePCR System by
authorized users
throughout the ePCR life
cycle (open, closed,
approved, rejected, QM
review)
16.
Each ePCR is linked
directly to the unit and
author and not the
patient or incident. This
allows each Report
Writer who needs to
contribute data for this
incident to open,
complete and close their
individual reports
regardless of the status
of any other unit's
Incident report.
17.
Mobile ePCR Software
allows a Report Writer to
complete, close, and
send a report even while
that incident is still
active.
18.
Remote access is
available for both mobile
and backend software
program.
19.
Mobile ePCR Software
has agency -definable
URL favorites to
establish links to web -
based sites such as
hospital status, etc.
20.
Application security is
provided through a
username/password
login process that is
synchronized with the
Active Directory account
and prompts the user to
change his/her
USERNAME/PASSWOR
D every 90 days.
21.
Vendor's access to
agency server is only
through a WebEx with
the supervision of
agency personnel.
22.
Product provides the
ability to "quick lock" the
application on demand
and/or during inactivity.
A button or menu -item in
the application that
would effectively 'lock"
the application and the
work station, similar to
ctrl-alt-delete.
ARCHITECTURE
23.
Significant portion of
ePCR architecture is
based on Dot NET
technology. List any
other development
foundation(s) e.g. MS
SQL, etc.
24.
Software Program is
built using an
expandable/modular
architecture.
25.
ePCR system utilizes a
minimum of 128 bit
encryption.
26.
Mobile ePCR software is
compatible with
Windows XP or most
recent Windows version
available. List any other
operating system that is
compatible with Mobile
ePCR software.
27.
The mobile and backend
architecture is available
as web based and
client/server based.
CAD INTERFACE
28.
Mobile ePCR Software
interfaces with Agency's
CAD "REAL-TIME" to
receive the following
data (28.1-28.29)
pushed to the tablets.
SHOW — indicates
display and storage of
the element in the ePCR
STORE — indicates
capture in the database
only
28.1
Incident Type as
Dispatched
(character length-8, field
type -character)
SHOW
28.2
Incident Type as Found
(character length-8, field
type -character)
STORE
28.3
RMS primary situation
found
(character length-8, field
type -integer)
SHOW
- if not provided, the
program will try to
translate it with the CAD
Incident Type as
Dispatched in the RMS
Interface
28.4
Incident address
(character length-40,
field type -character)
SHOW
28.5
Incident Scene Name
(character length-40,
field type -character)
SHOW
(Note: if scene location,
business or landmark
has a proper or
commonly recognized
name)
28.6
Incident city
(character length-13,
field type -character)
SHOW
28.7
District
(character length-6, field
type -integer)
SHOW
28.8
Incident Date/Time
(character length — 8/6,
Field type — date/time)
STORE
28.9
Incident receive by
Dispatch date / time
(character length-8/6,
field type-date/time)
STORE
28.10
Dispatch Date/Time
(character length-8/6,
field type-date/time)
STORE
28.11
Arrival Date/Time
(character length-8/6,
field type-date/time)
STORE
28.12
End Date/Time
(character length-8/6,
field type-date/time)
STORE
28.13
Control Date/Time
(character length-8/6,
field type-date/time)
STORE
28.14
First Arriving Unit
(character length-6, field
type -character)
SHOW
28.15
Station (character
length-6, field type -
character)
SHOW
28.16
Agency
(character length-3, field
type -character)
SHOW
28.17
UNIT
(character length-6, field
type -character)
SHOW
28.18
Unit dispatch date / time
(character length 8/6,
field type-date/time)
SHOW
28.19
Unit en route date and
time
(character length 8/6,
field type-date/time)
SHOW
28.20
Unit at scene date / time
(character length 8/6,
field type-date/time)
SHOW
28.21
Unit at patient date /
time
(character length 8/6,
field type-date/time)
SHOW
28.22
Unit departed date / time
(character length 8/6,
field type-date/time)
SHOW
28.23
Unit at destination date /
time
(character length 8/6,
field type-date/time)
SHOW
28.24
Unit clear/in service date
/ time
(character length 8/6,
field type-date/time)
SHOW
28.25
Unit at station date / time
(character length 8/6,
field type-date/time)
SHOW
28.26
Incident number
(character length 8)
STORE
28.27
Incident number of
Mutual Aid Agency
(character length 7)
STORE
28.28
Unit hospital contact
date / time
(character length 8/6,
field type-date/time)
SHOW
28.29
Hospital Name
(character length 20,
field type — character)
SHOW
29.
ePCR System MUST not
rely on static IP's to
send CAD data to
Mobile ePCR Software.
30.
Non-MFR units that are
entered into CAD but are
not pre -loaded onto
RMS (E.g. American
Medical Response,
Florida Power & Light,
Miami Police Dept. etc)
will transfer over to the
ePCR system as "aid
units" and be viewable
within the Patient
Report.
31.
When CAD dispatches a
Unit to an alarm, CAD
Interface to the Mobile
ePCR Software will
automatically transfer
the Unit's crew
information (badge or
employee IDs) per the
current roster of that Unit
as maintained by City's
FRMS (24Seven).
32.
With the exception of
wireless access issues
or `old' dispatches, the
CAD interface
automatically transfers
EACH relevant unit's
dispatch information to
the mobile unit's ePCR
Software, without user
request.
33.
If an updated CAD
message changes the
incident type to 611
(cancelled en route),
Mobile ePCR Software
can extract relevant data
from CAD to auto -
generate an ePCR
pertaining to a 611
directly on the backend
based on CAD data and
default values. This
feature allows the
Agency to pre -populate
designated fields in the
ePCR which include;
from CAD (Incident #,
Incident Type as
Dispatched, address,
Unit #, dispatched
date/time, en route
date/time, cancel
date/times); from RMS
(Crew members); and
predefined default
values for (Property Use,
Mutual Aid, and
"Cancelled en route" as
the Actions Taken and
final disposition). This
feature will eliminate the
need of the Report
Writer from manually
generating an ePCR for
cancelled en route
alarms.
34.
Mobile ePCR software
will accept or reconcile
all CAD updates into the
report for a period of
time designated by
Agency (approx 30
days), while still
maintaining a copy of
the originally printed and
closed report.
35.
The Mobile ePCR
Software will provide an
audible alert on the
device if a new CAD
incident is dispatched to
the particular unit.
36.
Agency can opt to lock
CAD data so that Report
Writer cannot delete
and/or edit the
transferred CAD data.
These elements include;
incident number and
type, scene address,
units dispatched and unit
times — excluding at
patient time.
37.
ePCR system integrates
with third party CAD
systems. Give examples
of which CAD systems
your software integrates
with currently.
38.
ePCR System MUST
integrate with Miami's
CAD.
39.
Vendor MUST currently
have proven experience
with custom CAD
interface development
by providing references
to at least 3 Fire -based
EMS services, each
utilizing a different
vendor's CAD product.
40.
ePCR Systems' CAD
interface is a pull and/or
push technology.
Specify what user
actions are required?
41.
Incident Type as
Dispatched must be
populated in the CAD
interface. This list can
also be 'filtered' (such as
EMS, FIRE) and the sort
order can be specified
by the Agency.
CLINICAL
CONFIGURATION
42.
Agency can Zink
additional agency -
definable questions to
clinically -relevant data
(complaint, cause,
symptom, allergy,
preexisting conditions,
findings, impression, and
treatment) to assist the
user. e.g., if user selects
Chest Pain as a patient
symptom, the program
automatically exposed
additional questions
such as "have you taken
Viagra in last 24 hrs or
how long ago did it
start?" etc.
43.
Agency can set default
values and list contents
for all treatments,
including drug dosages
and routes specific to a
treatment, with the ability
to edit these via a web -
based interface.
44.
In order to provide the
Agency with significant
flexibility, ePCR System
must allow clinical entry
lists (complaint,
symptom, cause, allergy,
meds, preexisting
condition, findings,
impression, and
treatment) to be agency
definable, along with the
agency able to define
'sub' fields or questions
for each of the individual
list items above. For
example, the Agency
can include one or more
additional questions for
a treatment, with each of
these questions
containing an agency -
defined list of answers.
This MUST be available
for all of the clinical entry
lists noted above.
•
DATABASE
45.
ePCR system database
is in an operational
environment utilizing MS
SQL 2005 or newer.
45.1
Future plans to make the
ePCR system database
operational utilizing MS
SQL 2008 when it
becomes available.
46.
The total number of
databases and tables
utilized by the ePCR
System, including
interfaces are made
available by vendor. List
all that apply.
47.
A data dictionary and as
built diagram displaying
table relationships, i.e.
primary and secondary
keys will be provided to
the client in electronic
and paper copies.
ePCR REPORT
48.
All ePCRs will printout
with the agency name
and logo, incident # and
type, patient last name
[except where HIPAA
applies] and disposition
on every page of the
report.
49.
A scanned Field Copy
Report or any PDF
document can be
attached as a JPEG or
PDF, respectively, to a
specific ePCR via the
Backend ePCR Software
using a web -based
interface. This data will
be retrievable as an
attachment capable of
being printed along with
the ePCR.
50.
MPDS dispatched is a
read only field auto
populated from CAD.
This is followed by an
MPDS FOUND field
which is also auto
populated with same
data. To make a
correction, Use the stylet
or tab to it, and it
automatically opens a
drop down window
listing all the MPDS
codes and written
translation for easy
selection.
51.
A "Mutual Aid" field
includes a drop down list
containing all FDID #
and agency name for
easy selection. This
field would default to
`none' through the RMS
interface if not
containing data.
52.
"Actions taken" field
contains a list whose
sort order can be
specified by the Agency.
Any Actions Taken will
be considered for the
entire crew.
53.
Mass Casualty field, if
selected, the user can
choose from an Agency
definable list.
54.
Selecting from the
Mobile ePCR Software's
unit list will send an
ongoing message to the
backend informing it of
its current activity status.
A new incident involving
the unit will result in
automatically delivered
dispatch details to the
relevant unit. These
incident details (incident
number, type, address,
and times) will populate
the Mobile ePCR
Software.
55.
Corrections to key
dispatch details
(address) will be
automatically sent to the
Mobile and update the
record.
56.
Upon selecting the unit
from within the Mobile
ePCR software a
wireless request will be
made to the RMS
system to obtain a list of
crew member badge or
employee numbers
assigned to that unit
(Daily Roster). This list
will populate the Mobile
ePCR Software's active
crew list for that unit.
Manual modifications to
the list of crew members
can be made during any
stage of the shift by
picking from a list of all
personnel of the Agency.
This list of crew is
broken down by last and
first name, badge or
employee number, and
skill level. The Report
Writer must be able to
separately define the
`role' of each respective
crew member for that
unit.
57.
Delays (to and from the
scene) are easily
recorded by selecting
from an Agency defined
list of delays. Delay lists
are placed in logical
sections (delay to scene
in a scene or incident
screen, delay from
scene in a transport or
outcome screen).
58.
Searching for a crew
member can be
performed by entering
the first few letters of the
name which will update
a list of all Agency staff
starting with the entered
letters. The crew
member can then be
selected and be added
to the active crew list.
59.
The patient address field
can be populated with
the scene address using
the copy key and can be
easily edited if needed.
60.
Gender Field is multiple
choices: Male, Female,
Unknown.
61.
Ethnicity or Race Fields
are agency definable.
62.
When Social Security #
is entered, program
automatically places
dash in correct place,
allowing user to enter
just the numbers.
63.
Date of Birth field is
entered using the
MM/DD/YYYY template,
the program enters the /
in the correct places.
64.
Upon entering the DOB,
the program
automatically converts
this information to the
patient's actual age and
allows for day or month
entry for infants.
65.
Insurance Company,
Policy #, Group #,
Medicare #, Medicaid #
fields are large enough
to hold 25 characters.
Major carriers and their
data should be pre -
populated in the
database.
66.
Employer information
includes fields such as
Name, Address, phone,
etc.
67.
Onset date can include
today's date or an
agency defined list of
date periods.
68.
"At patient side" time
field can be manually
entered, modified via a
list with one minute 1
increments, tapping a
'now' button or
populated via the CAD
interface.
69.
Chief Complaint lists can
all be displayed in
alphabetic order, filtered
further by a body area,
or entering the first few
letters will also narrow
the list of matches.
70.
User can select a Chief
Complaint and specify
further details, via a list
of additional Agency
defined questions and
associated answers
unique to each
complaint.
71.
More than one Chief
Complaint can be
documented.
72.
As with Chief Complaint,
past history (allergies,
meds, pre-existing
conditions) lists can be
displayed in its entirety
or filtered further by
entering the first few
letters to narrow the list
of matches.
73.
User can select an
allergy or preexisting
condition and specify
further, via a list of
additional Agency
defined questions and
associated answers
unique to each allergy or
preexisting condition.
74.
Past History elements
not found in the Agency
defined list can be
manually entered as
needed.
75.
All lists include an
"OTHER" selection to
manually enter data that
are not found in the list.
76.
Current Medication field
lists all medications in
alphabetical order. This
list as with the others
can narrow down the
selection by entering the
first few letters in the
medication entry field.
For example, entering
the letter T, will navigate
to all medication that
starts with the letter T
(not medications that
have the letter T in their
name). Additionally, the
program has word
memory that will narrow
down the selection as
more letters are entered.
For example, entering
NITRO will highlight all
data in the list beginning
with those letters, (e.g.,
NITROGLYCERINE).
77.
A medication list is
provided as part of the
Mobile ePCR Software
and includes information
similar to a PDR such as
definitions, indications
/contraindications, etc
and is updated regularly.
User can select the
medication by categories
or by Trade /Generic
filter to conduct search.
78.
Medical Dictionary is an
integral part of the ePCR
System
79.
For every symptom
selected, the user can
identify it as a pertinent
negative by selecting a
"denies" tab (or similar
method) after selecting
the symptom.
80.
A Cardiac Rhythm list
can be displayed in the
assessment section as
well as relevant
treatments (defibrillation,
pacing, cardioversion) to
minimize excessive
navigation efforts.
81.
The Mobile ePCR
Software must allow for
agency definable
additional questions
(and associated
answers) for "current
pregnancy" as well as
"labor/delivery"
82.
Suspected Alcohol/Drug
Use Field. (YES/NO)
can be placed in
relevant clinical sections
(such as cause,
impression)
83.
Any treatment prior to
911 arrival is
documented in fields
that have drop down
lists. These fields can be
configured to display
treatments normally
associated with prior
care, such as (AED,
CPR etc.). These
should include Outcome
of Care - (Improved,
Unchanged etc.) and
Who gave Care -(EMS,
Law enforcement etc.).
The ePCR System must
also allow for the
Agency to define
additional treatment -
specific questions and
associated answer.
84.
A vitals entry screen
must be available
throughout the program
without more than 2
clicks and can be
accessed to quickly
enter vitals data at any
point during the report.
Selecting this tab or
button opens a window
with fields including BP,
Pulse rate and
regularity, Respiratory
Rate, SpO2 and
comments. Upon
completing this
information, the Report
Writer is directed back to
the previously visited
screen.
85.
A treatment entry screen
must be available
throughout the program
without more than 2
clicks and can be
accessed to quickly
enter treatment data at
any point during the
report. Selecting this tab
or button opens a
window for treatment
entry and review. Upon
completing this
information, the Report
Writer is directed back to
the previously visited
screen.
86.
Time stamped clinical
elements (vitals,
treatments, and certain
assessment details)
must be placed in a
clinical event section of
the report, thereby
ordering time sensitive
clinical events into a
single section of the
ePCR.
•
87.
A pick -list on top of page
shows list of patients
(Patient 1, Patient 2,
Patient 3, etc.) for the
incident. There must
also be a quick and
simple method to add
more patients to the
same incident. All
information patient -
specific data entered will
be associated with the
actively highlighted
patient. A pull -down list
or similar must be
available to switch
`globally' between
multiple patients.
88.
When a new patient is
added, the program
updates its `to-do' list
immediately and
highlights all applicable
mandatory fields.
89.
At a minimum, the
following must be
assessment groups
which can be time
stamped;
- Pt position
- LOC (AVPU)
- Protocol followed
- Airway (status)
- Breathing (effort, lung
sounds)
- Circulation (strength,
regularity, site)
- Eyes (size and
reactivity)
- Skin (temp, moisture,
color)
- GCS (computed score,
eye, verb, motor)
-APGAR
- RTS
- Blood Sugar (value and
'hi' and `low' entry)
- Capnometry,
Capnography values
90.
ALL treatments must be
definable by the Agency,
along with ANY
additional questions
associated with each
specific treatment. For
example, `Morphine' will
expose questions such
as dose and route (that
must have values
specific to morphine),
but agency defined
questions such as pre -
pain and post -pain level,
amount of drug
discarded, etc, must be
definable by the Agency.
The treatment entry
automatically defaults to
the current date/time.
91.
The relevant medication
dose is automatically
calculated by using the
patient weight already
entered and the
standard applicable
dose for each particular
medication. This will
automatically populate
the dose field but can be
easily edited by
highlighting the field to
display complete
multiple choice list to
choose from.
92.
Cincinnati Stroke Scale
is collected by the
system
93.
The Mobile ePCR
Software also has an
optional signature field
that can be used to have
the ED DR or Nurse who
verified the tube
placement sign as a
witness.
94.
Personal Protective
Equipment used (mask,
goggles, gloves, etc.) is
documented by the
system.
95.
Temperature data can
be entered in either the
Fahrenheit or Celsius,
the program will then
convert the data and
display both.
96.
Signs and symptoms
associated with body
areas should utilize a
body area and body
system diagram
whereby tapping on the
body area or system list
will expose agency
defined signs or
symptoms associated
with that respective area
or system.
97.
When conducting a
physical each of the
following areas can be
broken down into
additional agency
definable lists of detailed
signs:
- HEENT (Head,
etc)
- Neck
- Chest
- Abdomen
- Pelvis
- Back
- Upper Extremities
- Lower Extremities
Each of the areas must
be broken down further
(abdomen must allow for
the selection of RUQ,
RLQ, LUQ, LLQ), or
Upper Extremities into
(shoulder, arm, elbow,
hand, wrist, finger, etc).
Each of the areas can
also include further
documentation of these
areas including;
- upper/lower
- right/left
98.
The treatment entry
screen must allow for
agency definable
categories which allow
for quick filtering of
treatments. For
example, selecting the
cardiac arrest filter
would display a list of
cardiac arrest related
treatments.
99.
If Report Writer selects a
compliant of CHEST
PAIN, the agency can
specify additional
questions to expose
associated with this
complaint. (99.1 — 99.6)
99.1
Pain started while (at
rest, walking, strenuous
exercise etc.)
99.2
Pain Quality (Dull,
Sharp, Stabbing etc.)
99.3
Pain Radiates to (neck,
right arm, left arm, etc.)
99.4
Pain Scale (1-10)
99.5
Pain Duration (1-5 min.,
5-15 min., over 15 min.
etc.)
99.6
A remarks field is
included to add any
pertinent notes,
example: relieved after
patient nitro or no relief
after two patient nitros
etc.)
100.
If the Report Writer
selects an impression of
CARDIAC ARREST the
agency can specify
additional questions to
expose associated with
this impression (100.1 —
100.11)
100.1
Cardiac Arrest - prior to
EMS / after EMS arrival
100.2
Bystander CPR/AED?
100.3
Cardiac Arrest Etiology
(presumed cardiac,
drowning, electrocution,
trauma, respiratory, not
known, etc.)
100.4
Resuscitation attempted
(Attempted Defibrillation,
initiated chest
compressions,
Attempted ventilation,
etc.)
100.5
Arrest witnessed by
(layperson, healthcare
provider, not witnessed
etc.)
100.6
First monitored Rhythm -
Utstien template
(asystole, Vfib, Vtach
etc.)
100.7
Any return of
spontaneous circulation
(yes prior to ED arrival,
yes prior to ED arrival
and at the ED, no etc.)
100.8
Estimated time of arrest
prior to EMS arrival (0-2
min., 2-4 min., 4-6 min.,
6-8 min., etc.)
100.9
Date/Time Resuscitation
initiated/discontinued
(time CPR was stopped
or Time of death)
100.1
Reason CPR
0
discontinued (Medical
control order,
protocol/policy
requirements complete,
DNRO, etc.)
100.1
Rhythm on Arrival at
1
Destination (NSR, PEA,
Vfib etc.)
101.
If the Report Writer
selects an impression of
TRAUMATIC INJURYT
the agency can specify
additional questions to
expose associated with
this impression (101.1 —
101.8)
101.1
Cause of injury ( MVA,
burn, fall, industrial
accident, etc.)
The Agency can define
unlimited causes AND
unlimited questions and
associated answers
associated with EACH
distinct cause.
101.2
Mechanism of injury
(blunt, penetrating,
superficial, etc.)
101.3
Intent of Injury (assault,
self-inflicted etc.)
101.4
Triage criteria (Adult
Category 1 - 2 or more
long bone fractures,
B/P< 90, etc.)
101.5
Fall height (standing, < 8
Ft., > 10 Ft., etc.)
101.6
Surface (asphalt,
concrete, grass, etc.)
101.7
Work related injury?
(yes/no) If so, what type
of industry?
(Construction,
manufacturing,
agricultural, etc.)
101.8
Area of injury is selected
using a diagram of the
anatomical body.
102.
If the Report Writer
selects a cause of MVA,
the agency can specify
additional questions to
expose associated with
this impression (102.1 —
102.11)
,
102.1
Additional MVA
questions must include:
seat belt use, impact
type, patient
compartment intrusion.
102.2
Type of vehicle (auto,
bus, truck, motorcycle,
etc.)
102.3
Area of impact (front
center, rear center, right
side, left side, etc.)
102.4
Vehicle involved with
(auto, bus, truck,
motorcycle, etc.)
102.5
Patient ejected (no,
partial, yes fully, etc.)
102.6
Safety equipment used
(lap belt, shoulder strap,
helmet, etc.)
102.7
Extrication tools (Jaws of
Life, Pneumatic Cutter,
hand tools, etc.)
102.8
Trauma indicator on
vehicle (dash deformed,
roll-over, DOA same
vehicle, etc.)
102.9
Seat row location of
patient (1, 2, 3 etc.)
102.1
0
Position of patient in
seat (driver, pass,
middle, left, right, etc.)
102.1
1
Airbag deployed (no,
dash, side, etc.)
103.
A disposition -driven and
agency -configurable `to-
do' list is available in the
Mobile ePCR Software
allowing the Report
Writer to select the item
which subsequently
navigates to the field or
provide a mechanism to
directly enter the data
element. The agency
definable disposition list
also will drive the to-do
list through a `matrix' of
data elements usable in
the to-do list.
104.
Final disposition must be
configurable by the
Agency and must allow
for dispositions including
but not limited to: treated
and transported by EMS,
treated but refused
transport, transported
but refused treatment,
refused treatment and
transport, will find own
transportation to ER,
DOA, DNRO, etc.
105.
Mobile ePCR software
must provide a
configurable field (with
pick list items) to allow
for the documentation of
"Condition at
destination" or "Patient
status at ED" (improved,
unchanged, worse, etc.)
106.
The ePCR System must
provide a ePCR faxing
feature from the field as
well as a web -based
mechanism to define a
fax number for each
receiving facility,
eliminating the need of
the Report Writer to
manually enter a
hospital's fax number.
107.
Once the hospital is
chosen, the Report
Writer can opt to
wirelessly deliver or
activate exposure to a
summarized ePCR to
the receiving facility,
accessible over a secure
web -based application.
This summary will
provide key data about
the patient including
gender, age, chief
complaint, past medical
history, present
condition/vitals,
treatments rendered and
any documented results
of the treatment.
108.
The ePCR System will
include a field "Reason
for Hosp Chosen" -
closest facility, patient
choice, family choice,
protocol, etc.
109.
The ePCR System must
allow the Report Writer
to capture patient
transport destination.
The system must
provide documentation
of the destination via a
list of hospitals as well
as alternate transport
providers (AMR, MPD,
etc). These lists must
be configurable by the
Agency
110.
ePCR System must
document "Level of
Care" (ALS / BLS) via a
pick list
•
111.
ePCR System must
document status to and
from scene (e.g., lights &
siren, upgraded from
routine to lights and
sirens, downgraded from
lights and sirens to
routine, etc.)
112.
ePCR System must
document Patient
Movement to Rescue
(stretcher, walked,
carried, etc.)
113.
ePCR System must
document Patient
Placement in Rescue
(stretcher, bench seat,
child seat, etc.)
114.
ePCR System must
document Patient
Movement to Hosp
(stretcher, walked,
carried, etc.)
115.
The Mobile ePCR
Software must manage
patient refusals by
allowing the Report
Writer to `check' canned
refusal
acknowledgements and
statements. These
statements will appear in
the ePCR on the same
screen requiring the
patient's signature.
116.
Report date is
automatically populated
by default to actual date
Report Writer is logged
on.
117.
Mobile ePCR software
provides a narrative
section that will include
English and Medical
spell -checking as well as
allow for the capture of a
minimum of 3,000
characters.
118.
The Report Writer for the
active ePCR can be
selected through an
agency definable list of
crew `roles', including
`Officer in Charge'.
119.
A 'report summary
screen is available in the
Mobile ePCR Software
providing a summarized
ePCR, normally used
when contacting a
hospital or medical
control. The contents of
this summary screen
include the patient age
and gender, receiving
facility, as well as a
summary of present
history, past history,
findings, impression,
treatments, and vitals.
Time stamped items
(such as treatments and
vitals) will be displayed
and sorted by the time of
the event.
120.
The ePCR can be easily
reviewed in the Mobile
ePCR Software by the
report Writer prior to
closing or printing a
ePCR. The Mobile
ePCR Software review
feature is a print preview
of the actual printout and
allows for scrolling the
report in its entirety. It is
strongly preferred that
the report is in an
industry standard, such
as PDF.
121.
The ePCR System
provides a web -based
interface for report writer
or an authorized user to
create one or more
addendums with
additional data without
modifying the originally
'closed' reports.
122.
Each ePCR can be
displayed and printed in
a 'show' or hide'
addendum mode.
123.
Each addendum within a
report is time/date
stamped and includes
other pertinent details
such as type of
addendum, action, and
who created the
addendum.
124.
Trauma Center criteria is
automatically generated
from data entered in
previous pages in
reference to the
Respiratory rate, Blood
Pressure, Pulse rate,
Intubation, Long bone
fracture, etc.
125.
Product uses data
entered in the vitals
section for Respiratory
Rate (10-29, >29, 6-9, 1-
5, none), Systolic B/P
(>89, 76-89, 50-75, 1-49,
none), and GCS (13-15,
9-12, 6-8, 4-5, 3) to
automatically generate a
revised trauma score.
126.
Employee badge #
needs to be 5
characters.
127.
Vehicle ID # needs to be
4 characters.
128.
Agency can choose
which non mandatory
data elements and fields
to include/exclude in the
application as a
requirement to complete
a report.
129.
Agency can opt to turn
on or off the auto
narratives which will
determine if a Report
Writer can or cannot use
the auto narrative
feature.
130.
A narrative is required
and as such is a
mandatory field for every
completed Report. When
printed, the narrative
includes the company ID
# and the Report Writer
badge # on a banner on
the screen/page.
131.
Product includes a
Broslow tape that can be
customized by the
Agency for specific
protocols and zoomed in
for easy reading.
132.
Product differentiates
between types of alarms
(ALS, BLS, pediatric,
trauma, etc.) and
includes a relevant
checklist to document
the specific data needed
to properly complete that
particular type patient
report.
133.
Addendum reports will
be entered under same
incident # and viewable
under the same Incident
#.
134.
Mobile ePCR software
includes a screen that
lists the average
pediatric weights and
vital signs according to
age.
135.
Addendum reports will
be separated per unit
and the program will
allow unlimited
addendums to be added
per incident.
FRMS INTERFACE
136.
Miami uses 24/SEVEN
as its Fire Report
Management System
(FRMS) to document
Fire Incident reports.
The ePCR software
must be capable to
interface and transfer
data to and from the
24/SEVEN product in
order to
generate/complete
required reports.
Following are four
examples (136.1 —
136.4) of the data
exchange required
between the ePCR
Software and
24/SEVEN. These
business rules must be
provided as part of the
final release of the
ePCR system.
136.1
Example 1;
Units dispatched to a fire
incident that turns out to
also have a patient will
require the ePCR
software to allow the
applicable unit to
manually initiate a report
on the ePCR software.
Via a FRMS interface,
the ePCR System will
then deliver the following
manually entered data
elements to the 24/7
system through a web
service to complete a
'Company Report':
- Agency ID
- Incident Number
- Unit ID
- Crew badge # or
employee #s
(including which
employee is
Officer in Charge)
The ePCR System will
provide a means by
which to verify manually
entered information with
CAD before delivering
this data to 24/SEVEN.
Data for this unit and
incident already residing
in the 24/7 software will
not be overwritten, with
the exception of crew if
differences exist.
136.2
Example 2;
Units dispatched to a fire
incident that turns out to
be strictly an EMS
incident will require the
ePCR software to
receive the Actual
Incident Type of EMS
from CAD which will
trigger a report due from
each unit that arrives on
the scene. Units that do
not arrive on the scene
will not have a report
created. Arriving units
will complete a
"Company Report" and
the ePCR software will
send the report Agency
ID, Unit ID, incident #,
author, and personnel
via a web service to
24/SEVEN to close that
unit's corresponding
"Company Report" on
both the ePCR software
and 24/SEVEN. The
main unit (transporting
unit or unit taking
responsibility for the
patient) will complete a
full ePCR report. The
ePCR System will
interface with 24/SEVEN
to transfer the following
NFIRS data needed via
a web service:
- Actions Taken
- Actual Incident
Type
- Mutual Aid
- Property Use
- Incident Number
- Personnel
(including Officer
in Charge)
- Agency ID
- Unit ID
These elements sent to
24/SEVEN will close the
24/SEVEN NFIRS
report.
The ePCR System will
provide a means by
which to verify manually
entered information with
CAD before delivering
this data to 24/SEVEN.
Data for this unit and
incident already residing
in the 24/7 software will
not be overwritten, with
the exception of crew if
differences exist.
136.3
Example 3;
Units that are dispatched
to an EMS incident that
turns out to be strictly a
Fire Incident will require
the ePCR software to
receive the Incident
Type as Dispatched
from CAD which will
trigger a report due from
each unit that arrives on
the scene. Units that do
not arrive will not have a
report created.
Arriving units will
complete a minimal EMS
report (driven by a
disposition of `fire -only
event' or similar) and the
ePCR software will send
the report Agency ID,
Unit ID, Incident #,
Author, and personnel
via a web service to
24/SEVEN to close that
unit's corresponding
"Company Report" on
both the ePCR software
and 24/SEVEN. The
main unit (unit taking
responsibility for the
incident) will additionally
complete the incident
report on 24/SEVEN (not
directly relevant to ePCR
System).
136.4
Example 4;
Units dispatched to EMS
incidents that remain
strictly an EMS incident
will require the ePCR
software to receive the
Incident Type as
Dispatched from CAD
which will trigger a report
due from each unit that
arrives on the scene.
Units that do not arrive
will not have a report
created. Arriving units
will complete a
"Company Report"
(driven by disposition)
and the ePCR software
will send the report
Agency ID, Unit ID,
incident #, author, and
personnel via a web
service to 24/SEVEN to
close that unit's
corresponding
"Company Report" on
both the ePCR software
and 24/SEVEN.
The main unit
(transporting unit or unit
taking responsibility for
the patient) will complete
a full ePCR report. The
ePCR System will
interface with 24/SEVEN
to transfer the following
NFIRS data needed via
a web service:
- Actions Taken
- Actual Incident
Type
- Mutual Aid
- Property Use
.
- Incident Number
- Personnel
(including Officer
in Charge)
- Agency ID
- Unit ID
These elements sent to
24/SEVEN will close the
24/SEVEN NFIRS
report.
The ePCR System will
provide a means by
which to verify manually
entered information with
CAD before delivering
this data to 24/SEVEN.
Data for this unit and
incident already residing
in the 24/7 software will
not be overwritten, with
the exception of crew if
differences exist.
137.
The ePCR system will
utilize a web service
provided by Tiburon to
obtain (and submit) the
active crew members
assigned to a particular
unit. This web service
will require
authentication and pass
the following arguments:
- Agency ID
- Unit ID
- Date/Time of the
request (if
requesting a
unit's active
staffing)
- Incident Number
(if requesting a
unit's crew for a
specific incident).
The elements below will
not be passed if staff
information is requested,
only if staff information is
submitted:
- Employee ID
and/or badge
number
- Last Name
- First Name
- Role designator —
including Office in
Charge).
138.
The ePCR system will
utilize a web service
provided by Tiburon to
obtain certain data
elements from the 24/7
FRMS system as well as
submit/enter certain data
elements collected by
the ePCR System into
the 24/7 system. This
web service will require
authentication and pass
the following arguments
to request (or populate)
data elements in the
24/7 system that are
specific to both a unit
'and incident:
- Agency ID
(required)
- Unit ID (required)
- Incident Number
(required)
- Actions Taken
- Actual Incident
Type
- Mutual Aid
- Property Use.
It is envisioned that the
first request will be read-
only in nature (provide
null values for the latter
elements). The second
request would
subsequently populate
any applicable elements
collected in the ePCR
System and not found in
the original FRMS
record.
139.
Able to upload an
individual PCR to the
central server without
the need for a 'batch"
upload.
MOBILE DATA
ENTRY
140.
Mobile ePCR Software
data entry requires a
digitized pen platform for
better accuracy,
increased hardware
durability and optimal
handwriting recognition.
141.
Mobile ePCR Software
is user friendly to allow
the entry or retrieval of
any data with minimal
pen taps or keystrokes.
Most if not all data can
be managed throughout
every screen of the
program with a
maximum of two
tap/selections.
142.
The need to use a
keyboard (physical or
electronic) to enter data
into the Mobile ePCR
Software report is kept
to a minimum to
increase the speed and
efficiency of use.
143.
All data is automatically
saved to the data base
server and via solid state
media at timed intervals
(selected by Agency)
and also to the tablet's
local hard drive upon
last entry to minimize
any data loss if server or
tablet hardware fails to
function.
144.
Mobile ePCR software
utilizes a tightly
integrated handwriting
recognition tool. For
speed it MUST allow for
quick access, entry and
correction of handwritten
information of fields that
would otherwise require
the use of the keyboard.
It should "recognize"
field data types and
automatically adjust for
these types to heighten
recognition accuracy,
E.g. time fields MUST
only accept HH:MM data
and must not accept a
time of 25:00.
145.
Mobile ePCR software
has the ability to store
an audio file, recorded
via a microphone on the
mobile device, and
attach it to a particular
report. On scene audio
data can be easily
recorded by the user
with an easy access tab
available on all screens.
This can be used to
record a verbal refusal
from the patient or to
document an unusually
violent or threatening
scene.
146.
Mobile ePCR software
screen data is large
enough and spaced to
ensure easy legibility
and rapid entry.
147.
Mobile ePCR software
can capture electronic
signatures for patient
reports.
148.
Mobile ePCR software
screen data input fields
are logically sized and
grouped so that
horizontal scrolling is
eliminated and vertical
scrolling is minimized.
149.
Mobile ePCR software is
created using templates
with drop -down menus
and auto fill capabilities
to reduce the need for
free -text comments field,
but free -text fields are
available as an option.
150.
Medical and English
dictionaries are included
in the Mobile ePCR
software to automatically
spell check any free-
form narrative data that
is manually entered.
151.
Mobile ePCR software is
categorized into several
commonly used screens
including, incident,
patient, history (present
and past), findings
(physical, impression),
treatments, fire basic,
and result.
152.
Mobile ePCR software
MUST possess NFIRS
basic module entry
screens to collect such
NFIRS basic module
elements as `action
taken' and `property
use'. These screens
cannot be part of a
separate program.
153.
All drop down windows
used throughout the
Mobile ePCR Software
are wide and large
enough to display
multiple lines of data that
is easily viewed with
minimal scrolling.
154.
Mobile ePCR Software
must allow the Report
Writer to `move' between
screens without
requiring completion of
entry at that immediate
point in time. This is
critical when utilizing the
system real-time.
155.
Mobile ePCR software
has 'one touch' time
entry, filling a data field
(operational times, vitals,
treatments) with the
current system time
without additional user
action.
156.
Mobile ePCR software
has a scratch pad 'notes'
feature allowing for rapid
entry of 'post -it' style
notes to access later
when completing
finishing the report.
157.
The Mobile ePCR
Software utilizes a
Handwriting recognition
tool that is activated by
no more than a single
click, is enlarged, and
displays near or next to
the relevant field, not in
a uniform location, in
order to speed data
entry instead of
restricting its use to a
small box.
158.
The Mobile ePCR
software is programmed
for single point of data
entry (example: If you
enter the age for a
patient in one screen,
you should not have to
enter it again on another
screen.).
159.
All mandatory fields are
highlighted in some
fashion to alert the end -
user (color coding, bold,
etc) until respective data
is entered.
160.
Crew login details (shift,
unit, agency and crew)
will be retained in the
Mobile ePCR Software
for each subsequent
incident.
161.
Mobile ePCR Software
provides the ability to
display ALS-level or
BLS -level treatments
based on the
documented service
level of unit entering the
report, thus exposing
only the pertinent data
elements needed for that
particular unit.
162.
The authorized
user/crew member name
or badge number must
be collected and
displayed as part of the
resulting ePCR crew
signature
163.
If a patient refuses
assessment, treatment
or transport, the report
writer can specify this
refusal in the software,
which can be configured
by the Agency to require
the patient's signature to
complete the ePCR. The
refusal screen defaults
to the patient's name as
the signer but can be
edited by the user if a
family member is signing
for the patient.. If the
patient refuses to sign or
is unable to, an unable
to sign field or button
can be selected. This
would result in an
"unable to sign" reason
to be captured (DOA,
Cardiac Arrest, Trauma
to hand, etc.). Selecting
this field will by-pass the
required signature.
.
164.
Agency can customize a
treatment tree to be
automatically opened for
specific common Chief
Complaint entries. It
includes additional list of
possible questions to
ask and areas to
consider for adequate
evaluation of Patient's
complaints to assist with
narrowing the provider
impression selection.
Example: a Chief
Complaint of Chest Pain
would automatically
open up a Cardiac Page
which includes all
required information to
ask, observe, and treat
in order to satisfy the
chest pain protocol
along with NEMSIS data
requirements. This will
direct the Report Writer
to follow the correct
procedure and capture
the pertinent data. Each
Chief Complaint is linked
to their respective
treatment tree as pre -
selected by the Agency.
165.
ePCR System allows for
patient transport with no
charge (for city
employees or
dignitaries) by using a
customizable billing pick
list specifying this
exception.
166.
Lists supporting both
keyboard entry and
handwritten entry can
narrow down or highlight
list contents based on
data already manually
entered (e.g., in the
Medications field, hitting
C will bring up all
medications starting with
C)
167.
Most of the ePCR is
easily completed by
using only the tablet
computer's pen to select
all data without the need
to use a keyboard during
mobile use at patient
side.
168.
All treatment
administered offer a 'set
to defaults' feature
whereby all sub -
questions associated
with each treatment can
be entered with an
Agency -defined default.
169.
Mandatory data fields
are displayed on
screens under main
icons and not hidden
under sub -icons that can
be accidentally
overlooked causing
pertinent data to be
inadvertently omitted or
difficult to find. ALL
DATA ENTRY USES
NO MORE THAN 2
LAYERS OF SCREENS.
170.
In the patient's address
screen, the Country field
must default to USA. An
Agency -definable list of
countries must also be
available.
171.
The Mobile ePCR
Software MUST offer a
user -transparent and
instant saving feature.
This eliminates a `save'
button and also allows a
Report Writer to return to
continuation of entry of
the ePCR in the event a
hardware error occurs
on the mobile device.
172.
The Report Writer can
switch to another
incident report without
clicking a `save' button
(e.g., saving is
transparent to the user).
173.
The Report Writer can
switch between two or
more patients managed
for the same incident
with minimal effort (no
more than 2 clicks).
174.
Mobile ePCR Software
allows for a minimum of
six (6) crew members to
be entered for each
Fire/EMS unit report.
These crew members
will be retained in the
ePCR system for any
subsequent incidents.
175.
Mobile ePCR Software
has an optional
signature field to capture
the name and signature
of who accepted the
report or the patient at
the ED.
176.
ePCR software allows
for the capture of up to 4
types of signatures,
including the patient,
primary and/or
secondary care provider,
witness, receiver, or
`other'. Each signature
must also allow for the
capture of the signer's
name and type of signer.
177.
Any field requiring a
number entry should
offer a numeric -only
handwriting recognition
tool or large number
keypad pop up for entry.
178.
Have a field to allow for
adding non -crew ride-a-
longs/Paramedic
students as well as
display that entry as part
of treatment providers.
179.
ePCR System provides
some mechanism to
document "high alert"
data, such as DNRO,
HIV, HEP C, SARS,
Organ Donor,
Tuberculosis etc.
180.
Product has an
anatomical figure to
easily document
traumatic injuries.
181.
Choice of inputting
patient weight in either
metric (kilogram) or
Imperial (pounds) which
is then automatically
converted to the other
format.
182.
Mobile ePCR Software
provides the ability to
select and add pertinent
negatives where
necessary.
183.
Mobile ePCR Software
provides an easy
method to edit and
record mid -shift crew
member and/or vehicle
changes.
184.
Mobile ePCR Software
allows the Report Writer
to navigate directly to a
particular page within
the software using a
combination of buttons,
lists, or tabs. The
software MUST not
require a specific order
of data entry but instead
be optimized for real-
time entry.
185.
More than one patient
can be documented for
the same incident by the
same unit by the
selection of an "add
patient" button or tab,
which will automatically
copy incident -specific
information into the new
patient's ePCR without
redundant entry.
186.
Most information is
plainly displayed with a
minimal need to open
and search through
many categories, sub-
categories. The use of
drop down lists under
main headings is
preferred. The focus is
to make the data
available with minimal
effort and maximum
efficiency.
187.
On specific fields, the
ePCR Mobile Software
allows for positive and
negative documentation
of a clinical element.
For example, a symptom
can be documented or
the patient can deny the
symptom exists
(pertinent negative).
188.
On the "Patient
Medication", screen,
selecting a medication
and clicking a reference
button will expose an
online PDR with
expanded information for
that medication.
189.
A copy feature must
exist in the Mobile ePCR
Software allowing
applicable data already
entered to be reused
without reentry. For
example, a scene
address entered in one
screen can be copied to
the patient's address on
a different screen by
applying this copy
feature.
190.
Data entered in most
fields is automatically
accepted and saved
upon the entry of data
without the need to
press an additional enter
or save key for time
efficiency.
191.
If a data search field is
used in the Mobile ePCR
Software to find
information and then the
information needs
transferring to another
field, then the search
field is simultaneously
cleared with the
transferring of the data.
This will leave the
search field ready to
query the next data with
just one pen tap instead
of having to clear the
previously queried data
before entering new
request.
192.
The Mobile ePCR
Software must allow the
Report Writer to
manually initiate an
ePCR as well as merge
subsequently delivered
dispatch information into
the originally initiated
ePCR
193.
All the date/times
(Dispatched, En Route,
Unit Arrival, Patient Side
Arrival, Transport, Arrival
at ED, Unit back in
Service, Unit back in
Quarters, etc.) pertaining
to an incident are
automatically transferred
over from CAD. If not
sent via CAD these
times can be manually
entered through
handwriting, a keyboard,
or can be manually
entered by using a "now"
button.
194.
A Mandatory field can
be linked / tied to a
second mandatory sub
field. E.g. if the
procedure of EKG is
chosen, program then
mandates that an entry
be made in the rhythm
field or if the procedure
of Pacer is chosen, then
program mandates an
entry in the rate field.
195.
Data entered into the
"Provider Impression"
field, prompts the Report
Writer to enter further
data in specific
correlating fields that are
pre -selected by the
Agency. This can be
accomplished by several
means: a) highlighting
the fields throughout the
program b) listing the
fields in a separate list
c) Linking the specific
fields required as sub
mandatory fields. These
will be in addition to all
those fields already
highlighted as
mandatory ones to
comply with
NEMSIS/EMSTARS
elements. This will
eliminate the possibility
of omitting pertinent
patient evaluation and
treatment for a specific
patient illness or injury.
For Example, if Chest
Pain is entered as the
Provider Impression, the
program automatically
highlights all pre -
selected fields in the
Treatment Page to
include 02, 12 lead,
Nitro, Aspirin.
196.
Using the Chief
Complaint as the basis
for the required
treatment, the program
compares the treatment
entered against the
required treatments in
that particular protocol
and alerts the Report
Writer if there are any
inconsistencies or
omissions. If Report
Writer does not correct
the data entered, the
program automatically
sends an alert to QA for
review of this report.
197.
All treatment
administered
automatically defaults to
"PROTOCOL" as the
authority or reason for
the treatment. This
saves repetitive entry for
treatments, especially in
a cardiac arrest where
the treatment list can be
very long. On those rare
occasions when the
Radio MD gives an order
that supersedes the
protocol, the program
allows for the user to
edit the authority from a
drop down list to select
from (Medical Director,
Radio MD, Patient's MD,
On Scene MD, etc.).
198.
Report Writer can
manually save an
incomplete report at any
point during the data
entry.
199.
Anytime the software
enters the sleep mode
whether its due to
programmed time limits
or manually selected by
the user, it will re -boot to
the screen/field that was
actively being used last.
200.
Program is configured to
be efficient and eliminate
any duplication of effort
to complete reports. E.g.
when a Report Writer
closes out a report, the
program automatically
uses the badge # of the
Report Writer who is
logged on to the PC,
instead of having to
enter his badge # after
each report. This is also
more secure than being
able to enter a separate
badge # or password at
the end of each report.
201.
Has a field to document
any valuables or
personal items taken to
and left at the hospital.
202.
Mass Casualty field, if
selected, the user can
choose between
Suspected Terrorist Act
and Non Terrorist Act.
The selection of either
one of these prompts the
user to contact proper
supervisors/support
selected by Agency and
automatically highlights
fields throughout the
application requiring
additional data entry.
203.
All Confirmation,
Response, Complication
must be multiple choice
fields per NEMSIS.
204.
HIPAA
brochure/information
given to the patient must
be documented in
appropriate field.
205.
Report Author/Officer in
Charge automatically
defaults to the Report
Writer logged on but can
be easily edited by using
the stylet to highlight
field and type either the
badge number or name
of the Report Author.
Program will search for
information from
database to complete
missing badge # and/or
name.
MOBILE
INTERFACE
206.
Mobile ePCR software
has the potential
capability to interface
with optional card swipe
hardware to read
magnetic strip and
automatically transfer
the data into the
appropriate fields in the
report.
207.
Mobile ePCR software
has the ability to view
and attach one or more
digital images to the
ePCR from an attached
camera without requiring
the user to utilize a third
party software.
208.
Mobile ePCR software
must have a seamless
interface to Agency's
current LifePak 12
product (also specify
interfaces to other
medical devices).
209.
ePCR system integrates
and interfaces with other
remote devices and
technical products
wirelessly. E.g..bar code
reader, driver license
scanner, camera, GPS,
voice recognition, etc.
210.
The ePCR System
(Mobile and Backend)
MUST provide a direct
interface with
Medtronic's LifePak 12
monitors. This MUST be
an interface live in the
field today. With the
exception of necessary
Medtronic software, the
Backend ePCR
Software's review of
ECG data MUST be
web -based to minimize
workstation
configuration.
211.
Completed report can be
sent by fax to a
designated list of
facilities provided by the
Agency. This is
accomplished by simply
selecting the fax button
which will then default to
the facility chosen for
transporting the patient.
User can also select
"other" which will open a
drop down window
displaying all the
facilities to choose from.
This feature is used to
fax a report to a
receiving hospital as a
redundant system when
the printer is not
available to provide a
hard copy of the report.
212.
Mobile ePCR Software
provides a means to
wirelessly (Bluetooth or
other functional wireless
mechanism) transfer
reports between portable
devices in the field. E.g.
to transfer a report that
has been started by an
Engine Company to a
Rescue, the Engine
Officer would select the
Rescue number from a
pre -designated list and
then select the send
button. This will transfer
all the patient -specific
and applicable report
information gathered by
the Engine to the
Rescue, thereby
eliminating redundant
entry. The Engine still
MUST complete its unit
report independent of
the Rescue's ePCR.
213.
The Mobile ePCR
System has an Agency -
configurable language
translator tightly
integrated exposing a list
of questions or
statements defined by
the Agency in Agency -
definable languages
(Spanish, Creole, etc.).
MOBILE
MANAGEMENT
214.
ePCR System is able to
identify each Mobile
Device by a unique
identification number
assigned to it which is
used to send data to a
specific unit.
215.
Due to the need for
reliable wireless
connectivity, the Mobile
ePCR software MUST
manage and/or display
wireless connectivity to
the backend system to
ensure the field user is
aware of connectivity
status.
216.
Any device that is
interfaced or connected
with the tablet/PC will
have its date/time
synchronized with this
software in order to
avoid conflicting times in
the completed
document.
217.
Agency must have
significant flexibility with
the ability to change the
title of fields and tabs on
Mobile ePCR Software
screens to be consistent
with the Agency's
terminology.
218.
The Agency is capable
of temporarily adding or
activating a new field or
icon/flagging tool to the
software program to
identify specific
incidents, example:
Hurricane event, acts of
God, mass casualty, etc.
as determined by the
Agency. The Agency will
have the ability to
configure the start and
stop dates and times to
have this particular field
or icon in use. This
temporary field or icon
will be used by the
Report Writer when an
incident is related to this
specific event. Agency
can then query and tie
all alarms that were
related to this event by
the Report Writers'
selection of this field or
icon. This will assist in
the collection of data for
future study of these
specific incidents.
219.
The Mobile ePCR
Software will
automatically scan the
report for required
elements and display a
'to-do' list exposing
omitted mandatory fields
needing attention.
These elements will be
highlighted in the
software and each can
be navigated to by
clicking on the
applicable to-do fist item.
220.
The amount of patients
per incident and the
amount of incidents that
can be managed by a
single mobile device is
unlimited. (Specify any
limitations that do apply).
221.
ePCR System provides
redundancies to store
data on the mobile
device. Provide the
methods used by the
ePCR system to meet
this requirement
WITHOUT a reliance on
wireless connectivity (if
device's HD is
damaged).
222.
Mobile ePCR Software
has a warning alert
before exiting the
application to avoid
accidental closing during
use.
223.
Once a PCR has been
synchronized to the
server, the PCR will be
available to the medic
from any device running
the application. E.g.
platform independent.
PERFORMANCE
224.
System's 'up time' is at
least 99.5%, 24 hours a
day, 7 days a week.
225.
Mobile ePCR Software
takes minimal time
(typically < 2 seconds) to
perform actions
including login, open
report, move from
screen to screen, enter
data and save data.
226.
Mobile ePCR Software
is NEMSIS Silver
Compliant.
227.
Mobile ePCR Software
requires less than 5
seconds to setup for
either printing or ePCR
wireless transfer.
228.
Data must be available
real/near real time to
various stakeholders,
e.g. quality assurance,
billing, research
processes, other
units/stations.
229.
Vendor can Provide the
time required to retrieve
an individual ePCR
based on five (5) years
worth of data
(approximately 450,000
records) contained in the
database.
230.
Vendor can disclose
minimum bandwidth
required to transmit data
and the average size of
an ePCR, e.g. at 56kb/s
an average PCR will
require "x" time to
transmit to the server.
231.
Vendor can provide the
wireless capabilities of
the ePCR System to
include the size of files
currently transferred and
type of data currently
transferred.
232.
MUST be able to
wirelessly transfer
completed ePCRs from
Mobile to Backend
ePCR Software without
security issues.
233.
Software connects to
multiple sites throughout
the day without having to
reboot.
REPORTING &
ANALYSIS
234.
Program has optional
report printing versions
to choose from for
specific purposes;
1. Original ePCR
2. Amended ePCR
3. HIPAA-sensitive
ePCR (excluded
data fields
normally
containing
confidential
information).
235.
Agency can schedule
reports/queries to be
generated and routed to
be distributed at a pre-
determined time frame
automatically.
236.
Product is able to query
all reports tied to a
particular member by
more than one means,
(badge number or
employee number, name
etc.) to facilitate these in
case of a name change
due to marriage or other.
237.
Canned reports are
included with software
package, (provide list).
238.
.
Reports can be
integrated with mail
server for distribution as
a PDF, EXCEL, WORD
(or similar) format.
239.
The ePCR System must
have the ability to view
an ePCR where multiple
care providers and/or
units provided treatment
and/or transport to a
single patient during a
single incident as one
contiguous record (of the
final unit managing the
patient) if an electronic
transfer of that patient
occurs between these
respective units.
240.
Over 99.5% of data
elements capable of
being collected by the
ePCR System are
capable of being
analyzed though the
Custom Reporting and
Analysis Tool on all
ePCR records.
241.
Following is a list of
common reports used to
analyze data collected
through the ePCR
System. Specify if the
ePCR System can
generate each of the
required reports by
either a predefined
(canned) report or
through a reporting tool
customized specifically
for the ePCR System.
The reports MUST be
generated through a
web -based tool.
242.
Action taken by
Unit, Shift, Date/Time
Period.
243.
# Incidents by
Unit, Shift, Employee.
'
244.
Cardiac/Respiratory
arrests by
Unit, Shift, Date/Time
Period.
245.
Chief Complaints by
Unit, Shift, Date/Time
Period.
246.
Final disposition by
Unit, Shift, Date/Time
Period.
247.
Injury (Cause) by
Unit, Shift, Date/Time
Period.
248.
Medications given by
Employee.
249.
Procedures performed
by
Employee.
250.
Provider Impression by
Unit, Shift, Employee.
251.
Exception report, such
as no vitals, no
transport, chest pain
with no treatment, etc.
by
daily/month ly/yearly
(specify what exceptions
the system can report
against).
252.
Non -reconciled incidents
by
Unit, Shift, Employee
253.
ePCR
H I PAA-sensitive
information INCLUDED
(this will show
addendums)
254.
ePCR
HIPAA-sensitive
information EXCLUDED
(this will show
addendums)
255.
ePCR
H I PAA-sensitive
information INCLUDED
(this will show
addendums), this report
will also show fields that
were left blank.)
256.
Incidents by
situation found,
company type, false
alarms, Date/Time
Period
'
257.
Average response time
(monthly)
This includes fractal
breakdown as specified
in the following example:
The system must include
a reporting tool allowing
the Agency to specify
the average difference
between ANY TWO
operational or clinical
times. For example,
average time between
dispatch and
defibrillation, dispatch
and first vitals, at patient
and first treatment.
Agency must be able to
pick any two times and
compare them (NOT
through canned reports.
258.
Cancellations
by unit (monthly/yearly)
259.
Response time >
"agency -defined time" by
Unit, Shift, and
Date/Time Period
260.
Transports by
Hospital,
(monthly/yearly)
261.
Inter hospital transfers
by
(monthly/yearly)
262.
Intubations by
Unit, Shift, Employee,
(monthly)
This is one example.
Agency MUST have the
flexibility to query ANY
treatment and ANY
associated questions to
a treatment. For
example, reports for
intubations can include a
compliance breakdown
for each of the agency -
definable questions
associated with
intubation (or any other
treatment) as well as a
breakdown for any of the
answers selected for any
one of these definable
questions (i.e.,
breakdown of lung
sounds, tube check,
cords visualized, etc).
263.
Transported ALS/BLS by
unit, status from scene,
(monthly/yearly)
264.
Web Based Query Tool
allows agency -
configurable access to
database with minimal
information. Tool
supports "drill down"
capabilities to allow the
user to click or select a
field and retrieve
additional information.
265.
Able to query if ePCR
reports have not been
completed but units
have been dispatched
and a ePCR is expected
by unit and shift, station
and shift, district and
shift, etc.
266.
ePCR Custom Reporting
System must display the
result set in various
formats (charts, tables,
graphs, etc) from within
a web browser
267.
Authorized user can
create a personal folder
to save custom reports
he/she created for future
use.
268.
A web -based Custom
Reporting System
provided with the ePCR
System MUST be able
to query data based on
multiple fields (data
fields collected by the
system) as well as
display results by
multiple fields selected
in the system. For
example, a user can
create a report that finds
all cases involving
cardiac arrests that did
not receive aspirin,
oxygen, or any other
agency -specified
treatment, and break
down the results by
employee, disposition, or
other agency -defined
parameters. At least
98% of all data elements
collected by the ePCR
system MUST be
capable of being
queried.
269.
When incidents are
sorted according to type
(Hazmat, EMS, Chest
Pain, etc.) it can be
configured to print in the
sorted order.
270.
The web -based
reporting tool MUST not
expect or require
knowledge of SQL to
build and execute
reports since many of
the Agency users will not
have a background in
SQL. The Agency
REQUIRES a reporting
tool that is `fine-tuned' to
the ePCR system
instead of a third party
reporting tool, such as
Crystal Reports. Ad hoc
reports, for example,
should not require any
SQL knowledge or third
party reporting.
•
271.
ePCR System MUST
provide a web -based
tool allowing an
authorized user the
ability to create and
execute queries by
individual paramedics.
For example, a
breakdown of types of
calls, intubations and
success rates, other
treatments, etc.
272.
Any of the reports built
by the Agency using the
Custom Reporting
System, can be
scheduled for automatic
email delivery to
Agency -definable staff
(daily, weekly, monthly).
273.
All fields that accept
numeric entry are left
blank instead of having a
"0" as a default. This
eliminates the possibility
of misleading
information if this field is
overlooked and report is
erroneously printed with
zeros.
274.
The ePCR System
allows for the capture of
all Florida State
EMSTARS required
elements per the Silver
standard and is NEMSIS
Silver -compliant.
Specify how this is
accomplished.
275.
The ePCR System
allows for the capture of
all elements required for
the State Aggregate
report and can send the
data via an XML file
extracted from the
database.
276.
The ePCR System's
State Interface can
create an extract file
containing required data
elements in compliance
with the Florida State
EMSTARS utilizing the
NEMSIS Silver standard
and will offer updates as
part of maintenance to
comply with the required
elements in this
standard. Specify how
this is accomplished.
277.
The ePCR System must
meet Florida's
EMSTARS minimum
criteria as listed below:
1.) The software must be
certified as NEMSIS
compliant at either the
Silver or Gold level.
2.) The software must be
configured with data
elements, field values,
and validation rules
specified in the Florida
EMS Data Dictionary.
3.) The software must
utilize the EMSTARS
XML Schema to export
EMS event records.
4.) The software vendor
must successfully submit
test records to the
EMSTARS database for
validation.
278.
The Agency is not
limited to NEMSIS or
EMSTAR codes. For
example, while NEMSIS
may have one
impression code for
chest pain the Agency
may define additional
impression codes similar
to cardiac (chest pain,
cardiac related, potential
STEMI, etc). However,
the Florida EMSTAR
Interface must provide
the ability to consolidate
similar coded elements
into a single element for
Florida EMSTAR extract
submission.
279.
If data is entered into a
field using the copy
function, when printing
the report, the program
prints out the actual data
and not the word copy.
280.
Upon printing reports,
program only prints the
populated fields. Having
a heading print out that
is left blank is a liability
concern and also wastes
paper. Any printed report
includes Alarm #, Report
Writer or Badge # ID and
date report was printed
clearly stamped on
bottom of each page.
SYSTEM
281.
The ePCR System
supports the capability to
easily integrate with
Reporting Services and
the potential capability to
easily integrate with
other web -enabled
products.
282.
Every ePCR report
created MUST be
accessible to edit on
both a mobile device on
the field apparatus as
well as each station's
workstation.
283.
ePCR software includes
extensive data dictionary
with consistent
terminology. A
comprehensive data
dictionary documenting
all data structures,
triggers, and database
details MUST be
delivered with the ePCR
Software prior to or at
system acceptance.
284.
Backend ePCR Software
allows authorized staff to
add or modify lists or
lookups via a web -based
interface. The same
users MUST be able to
disable a list item but
cannot delete a list item
already captured in the
past (to maintain
referential integrity).
285.
Backend ePCR Software
should have the
capability of exposing
QM notes for a specific
alarm or staff member
as well as providing
general messages
enterprise -wide.
286.
The ePCR System
MUST allow any coded
list element to be
enabled or disabled to
allow the Agency to
archive data and hide
any particular element
from being viewed in the
current Mobile ePCR
Software pick list due to
discontinued equipment
or retired personnel.
This data remains in the
database and is
accessible for future
queries, legal matters,
etc.
287.
The ePCR System
MUST readily distinguish
between two ePCRs
entered by the same unit
for the same alarm on
different shifts. E.g. If
Q4A is on an alarm at
shift change and is
relieved by Q4B, each
officer must generate a
separate report to
document their
assignment for the same
unit on this same alarm.
288.
ePCR system must have
the ability to quickly
search and retrieve one
or more matching
ePCRs based on the
utilization of one or more
search parameters
(including wildcards) or
filters including:
- date or date range
- incident number
- incident address
- patient name
- patient SSN
- destination
- shift
- unit
- crew last name
- crew employee ID
- Officer in Charge
This feature MUST be
web -based and offer the
same role -based access
rules noted elsewhere in
this document.
289.
Report status categories
include: open, closed,
updated/appended,
cleared or rejected by
supervisor, etc. It is
understood that each of
these status categories
may have significant
business intelligence but
the ePCR system should
have the potential
capability to expand
upon these status types
in the future.
290.
The ePCR System must
provide a mechanism to
store ePCRs in a
production or operational
database for retrieval
and analysis as well as a
separate archival
database for the same
purpose. The same
review and analysis
tools MUST be web -
based and MUST allow
a user to access either
database through a
simple means.
291.
The ePCR system
MUST be able to
DEMONSTRATE its
ability to effectively
manage a quantity of at
least 100,000 annual
ePCR records in the
operational system and
a minimum of 400,000
ePCRs (5 years of report
data) in the archival
system. The capability
of the ePCR System to
handle this volume
MUST be demonstrable
(e.g., live customer).
292.
An automatic log off
feature or capability
MUST exist on both the
Mobile and Backend
systems based on an
agency -defined period of
inactivity to comply with
HIPAA regulations.
293.
Program has a built in
report audit feature that
tracks and displays
applicable activity in
reference to the report.
When reviewing/printing
any ePCR, program
automatically captures
an audit record of the
ePCR, went it was
reviewed, printed, or
when an addendum was
added. An ePCR can be
printed either in its
original 'closed' format,
or printed in with its
addendums. The
addendums must also
display information
about each addendum
including date/time,
author, reason and the
addendum content. The
functionality above
MUST be through a
web -based interface.
294.
Except under very
limited circumstances,
all Mobile ePCR system
updates will
automatically Toad up on
the Mobile ePCR system
devices upon a
connection without the
need of user
intervention. This is
accomplished without a
long delay, while the
system is operational.
295.
The Backend ePCR
Software utilizes a web -
based query building
tool used to create
custom reports without
the need of specialized
computer skills (such as
SQL) or specialized
query software (such as
Crystal Report, Cognos,
etc).
296.
Agency can select
certain criteria based on
impression, complaint,
cause or treatment to
automatically trigger
routing a report to QA for
review.
297.
Vast majority of Mobile
ePCR Software updates
are done from an
administrative location
which will automatically
upload to all devices so
as to not have to
manually upload each
unit individually.
298.
Interfaces to 24Seven
and State required EMS
report allow for the
specification of exported
data elements to have
default values
automatically entered in
the back end which may
not be collected by the
Report Writer.
299.
Product allows for new
guidelines or protocols
to be pushed out to all
the field devices from a
central location via a
web -based interface
from an administrative
station.
300.
The ePCR System
allows the Agency to
specify unlimited
dispositions. Each
disposition can be
defined with a specific
check or to-do list of
data elements that need
to be collected prior to
closing an ePCR.
301.
Integrity of original,
legally closed medical
record is maintained.
ePCR can be made
read-only after ePCR
closure rules have been
satisfied. Information
can be amended via a
web -based application
by authorized users, e.g.
demographics,
insurance details. All
changes must be
tracked by version
controlling method(s) to
maintain HIPAA
compliance (name, date,
what was edited on the
ePCR)
302.
Through a web -based
tool, the Agency is able
to update user
information from the
server to field collection
device without requiring
vendor intervention.
303.
Through a web -based
tool, the Agency's QA
Officer and Medical
Director must have the
ability to attach
comments to the PCR.
304.
ePCR system integrates
with third party billing
software. The billing
interface must be at
least in an XML format
(vendor defined is
acceptable) and is fully
automated (scheduled)
and can send the extract
file automatically via
secure FTP or via a web
service. Give examples
of billing companies
software integrates with.
305.
ePCR System MUST
provide a "repeat
customer" referencing
feature. The Mobile
ePCR Software MUST
be able to wirelessly
query the Backend
database by using
HIPAA-compliant
standards (e.g. a
minimum dataset of
name and SSN must be
entered to validate the
patient match). Upon a
successful match, the
repeat customer's
archived information will
populate applicable
fields in the Mobile
ePCR Software.
Minimum fields include
patient demographics
and billing information as
well as past history
(meds, allergies, and
preexisting conditions).
306.
All terminology used
throughout the program
is consistent in order to
reduce confusion. For
example if CVA,
Laceration, or MI are
used in any field or list,
then Stroke, Cut or
Heart Attack should not
be used to reference
similar data throughout
the program.
307.
At least 100 patients can
be managed on a single
handheld for a single
incident. Selecting a
specific patient for an
incident will expose and
print only that particular
patient's details.
308.
The ePCR System must
allow the Agency to
configure one or more
dispositions specific to
the collection of an
'Incident Report'. The
data elements
necessary to complete
this report must be
selected through a data
element 'matrix' (or
similar). This feature will
eliminate unnecessary
entry of data that is not
applicable to an 'Incident
Report', but still utilize
the same Mobile ePCR
Software.
309.
Three reporting modes
are used by the Agency
(ePCR, Incident, Unit).
The ePCR System must
allow for the
specification of one or
more dispositions
associated with these
reporting modes.
310.
The product
automatically calculates
relevant scores upon
entry of data elements
comprising the score
(GCS, APGAR, etc).
311.
The ePCR System
provides the collection of
the following NFIRS
basic module data
elements and will offer
updates as part of
maintenance to comply
to the required elements
in this standard
- property use
- action taken
- event type
- mutual aid
312.
Mobile ePCR software
has the capability to
connect to a primary and
secondary server
without requiring a
reboot.
313.
The Mobile ePCR
Software must be able to
upload an individual
ePCR to the central
server without the need
for a 'batch" upload.
314.
The ePCR system or
backend system alerts
the Agency administrator
of system events, E.g. a
server shuts down.
315.
ePCR System provides
a web -based tool that
continuously analyzes
certain clinical and
operational data and
offers authorized user
the ability to create
alerting rules based on
an event occurring once,
or an agency definable
quantity and time period.
A triggered alert will
result in an email or sms
being sent to one or
more agency definable
personnel.
316.
The system must have
`global' access to
agency definable HTML
or PDF content, such as
a Protocol reference.
TERMS &
CONDITION
317.
Vendor agrees to an
escrow contract for
source code. Release
triggers include provision
of source code for
internal use only if
vendor no longer
supports product or
cease business
operations.
318.
Vendor can provide
upgrade policy for
current software version
(costs for upgrades,
what is or is not
covered)
TRAINING &
SUPPORT
319.
City of Miami Fire -
Rescue is provided with
all future upgrades to
product.
320.
Product training is
provided with software
purchase for field, staff
and IT personnel.
Include the number of
hours per session,
number of sessions and
limits per session.
321.
Product implementation
is broken down into
milestones with specific
timelines provided in
advance to accomplish
each.
322.
Vendor provides a
project manager,
technical and support
resources, training staff,
etc. during
implementation and "Go
Live" stage. Give details
for onsite support
associated with go live
and post go live
activities (support times,
contact mechanisms,
etc).
323.
Vendor offers a reduced
pricing model for utilizing
the Mobile ePCR
software for training
purposes only.
MISCELLANEOUS
324.
While not required to be
installed or used initially
as part of the delivered
ePCR System, the
ePCR System MUST
have a capability which
can be demonstrated to
allow hospitals to
securely view an ePCR
of any patient delivered
to its facility by the
Agency, via a browser.
325.
There are no minimum
or maximum limitations
to restrict any aspect of
the purchase contract.
326.
Product can be
purchased with an
enterprise license to
allow the Agency to host
their own data at no
additional cost.
327.
A majority percentage of
all of your organization's
ePCR FULLY LIVE
implementations are fire -
based services. (provide
reference list).
328.
Provide the number of
annual incidents
responded to by your
largest and smallest
FULLY LIVE fire -based
service agencies.
329.
Provide key challenges
your customers have
faced when
implementing your
ePCR System.
330.
Provide details for the
training process,
timelines and support
offered by your company
and if conducted by
instructors with expertise
in specific fields. (For
example do experienced
paramedics conduct the
end user training, IT
personnel conduct the
technical training,
support personnel
conduct the
administrative training
etc.)
331.
Provide the development
cycle of your product,
when the current version
was developed and
when the next version is
scheduled for release.
332.
Provide the version # of
your current ePCR
System and any future
plans you wish to
disclose.
333.
Provide all hardware
required for both the
front and back end
products, give details of
the companies and
products you have
utilized in the past with
successful results.
334.
Provide a cost estimate
for custom work such as
CAD/billing integration.
335.
Provide at least three (3)
references utilizing your
ePCR product, with at
least 2 being fire -based
of similar size (or larger)
to Miami Fire.
336.
Provide the server
specifications for the
Backend ePCR
Software, including all
interfaces.
337.
List any shortcuts, tools,
features that are
integrated into the
Mobile ePCR Software
to assist in "mobile data
collection".
338.
A miscellaneous icon is
available for specific
incidents that will require
forwarding a report to
another agency (e.g.
elder links, animal
control, HRS, etc) with
additional data. Program
uses data entered into
the report to pre -
populate the form and
only the additional fields
need entry. Upon
completing the PCR, the
user can query this
specific "form report"
and fax it to the proper
agency using the direct
contact link to the
agency.
OPTIONS &
CUSTOMIZATION
339.
A Rescue inventory
check-out sheet can be
added to the tablet hard
drive and accessed by a
separate icon. The
apparatus inventory lists
all items by
compartment with an
entry field next to each
item. User simply
highlights an item and
selects from a quantity
box (1-2-3-4-5-6) for
each item. Upon
selecting a quantity, data
is transferred to the item
field and program
automatically highlights
next item needing entry.
With this format, the
user only needs to make
a quantity selection for
each item as the
program runs through
entire list with each
entry. This information is
transferred and stored
electronically to
eliminate hard copy
storage. This Rescue
unit's tablet (must keep
individual tablet married
with a specific Rescue
unit) hard drive would
then keep an ongoing
total of all inventoried
equipment/supplies as it
is used during this shift.
At pre -determined
quantity level or time
intervals chosen by
Agency, the product will
prompt the user by
audible alarm any items
needing re -stocking by
listing them in a pop-up
inventory window.
Oncoming shift can
select the inventory icon
and take a look at the
Inventory page at shift
change and quickly
stock low items first in
case of early alarm.
340.
Mobile ePCR Software
has the capability to
track supplies and
inventory to maintain an
accurate on hand
balance.
341.
The Mobile ePCR
Software has the
potential capability to
interface with barcode
and card swipe
technology to populate
applicable demographic
and event data of the
ePCR. .