You are on page 1of 37

Requirement

1 PM/EMR General
Requirements
1.1 Data & Information
Management
1.1.1 Highly desirable that data is
maintained in a structured format
ensuring a minimum of text-
based data.
1.1.2 Highly desirable that required
data be highlighted in some
manner.
1.1.3 Highly desirable that existing
clinically relevant data not be
overwritten when updating.
Corrections should be marked as
such.

1.1.4 Text-based data should be edited


for spelling, grammar and/or
against a table of standard
phrases.
1.1.5 Highly desirable that structured
data be:
edited for format,
reasonableness, and/or,
validated against master
files/tables at time of data entry.

1.1.6 Highly desirable that all data


maintained as coded values (e.g.
gender of “F” or “M”, “J20” ICD10
code for acute bronchitis) be
enterable by code, partial code
and selection from an English
pick list.

1.1.7 Coded data should be checked


for input error (e.g. ICD codes
specific to gender or diagnosis).

1.1.8 Highly desirable that coded data


be reportable by code and/or
description.
1.1.9 Highly desirable that the system
share a single data store of
patient demographic data or
provide seamless options for
transferring data between
modules without re-entry.

1.1.10 Highly desirable that all data,


once entered, be searchable on
an ad hoc basis including but not
limited to:
1.1.11 Searches for individual
patients, and groups, on any
combination and/or range of
criteria (e.g. July 1, 2004 AND
July 31, 2004; July 1 – July 31,
2004, all patients whose last 3
BPs meet a specified criteria)

1.1.12 Wildcard
searches/searches on partial
data (e.g. DoB = July, 2004)
1.1.13 Highly desirable that user be
able to save/re-use searches.
1.1.14 Highly desirable that a patient
identification search be available
including search options of
name, PHN, chart #, phone #
and/or postal code

1.1.15 Highly desirable that the system


be able to identify duplicate
records.
1.1.16 Highly desirable that the system
be able to merge/unmerge
patient records.

1.1.17 Highly desirable that all data be


reportable.
1.1.18 The system should have the
option to organize and display
data based on the role of the
user, e.g. physician, nurse,
dietician.
1.1.19 Highly desirable that the system
support data access restrictions
(entry, view and reporting) based
on the role of the user, e.g.
physician, nurse, dietician.

1.1.20 Highly desirable that the system


accommodate and synchronize
input temporarily stored on
portable devices.
1.2 Functional Integration
1.2.1 PHCOs require effective
integration between modules of
the proposed system to ensure
optimal workflow efficiencies for
multi-disciplinary medical
practices and PHCOs. Describe
how the system ensures
effective integration of modules
including:

seamless data flow


between appointment booking,
registration, arrival/check-in,
progress notes and billing
without requiring re-entry.

automatic translation of
diagnostic coding to billing as
required for compliance to MSP
claims submission, encounter
reporting.

integration with office


productivity tools (e.g. word
processing).
integration with dictation
programs.
1.3 Scanning
Describe how the systems
scanning functionality functions
including:
1.3.1 the acceptance of
documents by scanned image or
OCR input.
1.3.2 whether scanned images
are unalterable.
1.3.3 the allowance for import
and attachment of other file
formats (e.g. MS Office, email)

1.3.4 Explain how data integrity is


maintained when recording
discrete data from a document
source.
1.3.5 Explain how the system
differentiates between health
documents that must be
attached to a patient’s record
and reference or educational
materials given to the patient.

1.4 Security
1.4.1 Highly desirable that suppliers
declare whether or not system is
completely compliant with latest
FOIPPA standards.
1.4.2 All reasonable means should be
used to protect data from
unauthorized access, disclosure
or modification. Explain your
security
architecture/components.

1.4.3 Highly desirable that suppliers


advise their customers on
appropriate strategies including
but not limited to the use of
firewalls, two-factor
authentication, antivirus
software, documented policies
and procedures, user training
and internal processes to
improve security.

1.5 Remote Access


1.5.1 Describe the way remote access
to the system is handled,
including but not limited to
description of differences in the
user interface and functionality
and synchronization ability.

1.6 User Profiles/Permissions


1.6.1 Highly desirable that access to
the system be secure, authorized
and appropriate by function, user
role, and type of data.

1.6.2 Highly desirable that access be


authorized through the use of
unique individual user ids,
passwords and profiles, including
for system administrators and
other technical staff

The system should support:


1.6.3 named provider/patient
relationships.
1.6.4 inter-provider work
assignment/temporary access –
e.g. provider absence due to
illness or vacation.
1.6.5 access to patient
demographic and health data
and information managed at the
data element level.
1.7 Audit Trail
1.7.1 Highly desirable that the system
track all accesses (view, create,
update, report) to patient
demographic and health data
and information including date,
time, user id, patient id.

1.7.2 Highly desirable that the system


allow denied requests for data
‘correction’ to be recorded and
annotated in accordance with
privacy legislation. Such
annotation should form part of
the audit trail. Describe how
your system will deal with such
issues for reporting purposes.

1.7.3 Highly desirable that the system


report audit tracking by date,
user id and/or patient id, on
request.
1.7.4 Highly desirable that the audit
trail be unalterable.
1.7.5 Highly desirable that the system
track unauthorized access
attempts and issue administrator
notifications.
1.7.6 Highly desirable that the audit
trail data be maintained on-line
for one year.
1.7.7 Audit trail data may be archived
after one year if it can be
reported.
2
User Interface Requirements
Desirable user interface
requirements include:
2.1.1 Customizable
prompts/naming conventions,
and layout of data entry screens,
screen displays.
2.1.2 On-line context sensitive
help.
2.1.3 Customizable user views
of the application/data (tied to
user profile).
Desirable ease of use features
include but are not limited to:

2.1.4 Patient (full name, sex,


DOB and unique patient
identifier) and Provider identified
on every screen.
2.1.5 Standardized presentation
of /access to similar data (e.g.
patient name always on right at
top) and functions.

2.1.6 Tables and master files


“searchable” by drop down lists,
code and free text data entry.

2.1.7 Describe the available methods


of navigation and data entry
including but not limited to:
Point & click
Short cut/hot keys
Touch screen
Voice recognition
Hand writing
3 Registration & Scheduling
(ADT)
3.1 Scheduling (Resources)
Highly desirable that Scheduling
support the following:

3.1.1 user-defined resources


including providers, personnel,
rooms/locations, room/location
types, and equipment

3.1.2 multiple user configured


schedules and appointment
types for each resource including
time slot and booking blocks.

3.1.3 multiple user defined


booking priorities
3.1.4 user-customized views of
resources they are responsible
for
3.1.5 templates and/or copy
functions to assist in schedule
development and maintenance

3.1.6 display and print daily,


weekly, monthly schedules by
resource and by patient.
3.1.7 manage provider on-call
schedule
3.1.8 multiple users can
view/update schedules
simultaneously
3.2 Appointment Booking
(Patients)
Highly desirable that the
Appointment booking support the
following:
3.2.1 multiple users can
view/update appointments
simultaneously
3.2.2 search for next available
appointment by provider,
provider type, day of week, time
of day, appointment type
3.2.3 1 to 1, 1 to many, many to
1 and, many to many patient /
resource bookings
3.2.4 flexible booking (2 short =
1 long, recurring appointments,
block booking)
3.2.5 book by name, phone #
and/or PHN
3.2.6 optionally collect/update
demographics
3.2.7 record presenting
problem, referring physician and
reminder notes with booking

3.2.8 display available alerts


and notes
3.2.9 notify of duplicate/multiple
bookings and over bookings

3.2.10 transfer, cancel and/or


rebook by resource, individual
patient and/or group without loss
of data or repeated typing or
processes

3.2.11 display and print day sheet


by resource (provider, room,
etc.), by time, by patient
3.2.12 export day sheet to mobile
device
3.2.13 automatically track and
report no-shows and
cancellations, and produce
letters to these patients
3.2.14 automatically initiate
transfer of information to billing
for no-shows and cancellations
3.2.15 maintain a dynamic,
integrated “recall by phone” list
(next appointment, results ready,
etc.) and track patient call back
status (e.g. outstanding, in
progress, closed)

3.2.16 track and graphically


report time to provider’s “third-
next-available-appointment” on a
daily and/or period basis
3.3 Arrival/Check-in
Highly desirable that
Arrival/Check-in support the
following:
3.3.1 · recording patient arrival
(e.g. by PHN card swipe device)

3.3.2 · displays alerts and booking


information (presenting
complaint, referring physician,
notes)
3.3.3 · updates appointment state

3.3.4 · notifies provider


3.3.5 · optionally collect/update
demographics
3.4 Registration Requirements
Highly desirable that Registration
support the following:

3.4.1 Seamless access to


registration from appointment
booking
3.4.2 Hot key to registration for
walk-ins
3.4.3 Ensure user searches
prior to creating a new patient to
prevent duplicate records
3.4.4 Automatic notification of
potential duplicate record prior to
creating a new patient
3.4.5 Maintain active and
historical data including but not
limited to:
- Multiple patient
names/name types
- Multiple addresses/address
types
- Multiple contacts/contact
types
- Identification of family
members, relationships, groups

- Identification of household
groups
- Patient status (e.g.
deceased)
3.4.6 Quick/copy (“clone”)
demographic information where
appropriate (e.g. for family
members)
3.5 Scheduling, Appointment
Booking, Arrival and Check-in
Recap (OPTIONAL)
3.5.1 Use the space below to describe
the features of the application
that you feel are noteworthy in
meeting the criteria.

3.5.2 Use the space below to describe


the features that provide
workflow efficiencies for the user.

4 Billing Requirements
4.1 Teleplan
4.1.1 Highly desirable that Billing
software be MSP Teleplan
compliant
State your compliance status
and the actual (or planned) date
of compliance for each of:

4.1.2 Teleplan Specification


V3.0 Fee For Service Claims
4.1.3 Teleplan Specification
V3.0 Primary Health Care
Project & Special Record
Formats
4.1.4 Teleplan Specification
V4.0 Web-based
Telecommunications
4.1.5

Pre-loaded PHCO
population-based funding patient
list ("patient register"). Patient list
will be supplied by the clinic, or
by MoHP/S, Primary Health Care
branch on behalf of the clinic.
4.1.6
Availability of complete
ICD9 and ICD10 code lists
through the billing software (not
just 3 and 4 character codes)
4.1.7 Preloaded MSP Fee Schedule at
the time of implementation.
4.1.8
Updates to the MSP Fee
Schedule and related MoH P/S
billing related reference tables be
made electronically through
Teleplan.
4.1.9
Diagnostic codes recorded in the
EMR automatically
transferred/translated to MSP
ICD9 billing codes for submission
and processing through Teleplan.
4.1.10

Clinicians may choose to


maintain diagnostic data in
coding system other than ICD9.
Indicate if and how your
software supports multiple
diagnostic coding systems.
4.1.11
Systems must retain records in
accordance with the MSP
Payment Schedule requirements
[2] at a minimum.
4.1.12 Systems should check for
patient MSP eligibility on-line
4.2 Additional Functions &
Features
Beyond compliance with
Teleplan, the billing module
should provide all of the
functions usually found in an
Accounts Receivable system
including but not limited to:

4.2.1 track and report on daily


services (& sales) by item and
provider,
4.2.2
bill patients and 3rd parties,
4.2.3 prepare & issue invoices,
statements and payment
receipts,
4.2.4 support a user-defined
billing cycle including discounts
for prompt payment,
4.2.5 perform payment
reconciliation,
4.2.6 prepare aged accounts,
4.2.7 manage write-offs and
transfers to collections,
4.2.8 correct errors by audited
adjustments,
4.2.9 report on account payment
history,
4.2.10 add user defined fee
items,
4.2.11 add comments to specific
accounts,
4.2.12
add messages to invoices,
statements and receipts,
4.2.13 record account contact
information such as name,
phone number on specific
accounts,
4.2.14
support financial and
statistical reporting and inquiry
suitable for a multi-disciplinary
medical practice and/or PHCO
4.3 Billing Recap (OPTIONAL)
4.3.1 Use the space below to describe
the features of the application
that you feel are noteworthy in
meeting the criteria.

4.3.2 Use the space below to describe


the features that provide
workflow efficiencies for the user.

5 EMR Requirements
5.1 General Requirements
Highly desirable that the EMR:
5.1.1
Support the capture,
display and reporting of clinically
significant data in a multi-
disciplinary setting including but
not limited to physicians, nurses
and nurse practitioners, and
dieticians.
5.1.2

Track the history of patient


care and documentation for a
complete longitudinal record of
all access, providers, and
activities involved in a patient’s
care.
5.1.3
Provide means to record
family history (i.e. chronic
diseases, dates of diagnosis,
disease status, functional status,
and date/cause of death).
5.1.4
Meet or exceed the
CPSBC requirements for records
retention
http://www.cpsbc.bc.ca/policyma
nual/rules/05.htm
5.1.5
Allow swift and complete
documentation at point of care
5.1.6 Support an electronic
physician signature to sign-off
charts. Describe the
mechanism.
5.1.7
Provide integrated access
to (customizable) knowledge
bases and reference material.
User should be able to insert
links, hot key to web e.g. to BMJ,
PubMed.
5.1.8 Use structured, validated,
edited, coded data with a
minimum of non-structured
information.
5.1.9 Support diagnostic coding
suitable in a multi-disciplinary
setting.
5.1.10 Be able to manage
multiple diagnostic codes for an
encounter (as per MSP Teleplan
ACG billing).
5.1.11 Provide word processing
capabilities for non-structured
information.
5.2 Templates
Provide a list of standard
templates including but not
limited to:
5.2.1
general and condition
specific default templates
including BC standards (e.g. for
CDM, BCRCP, clinical guidelines
and protocols)
5.2.2
templates within templates
for complex problems
5.2.3
templates preloaded with
“canned text”/routine answers
5.2.4 automated diagnostic
coding wherever possible
5.2.5 template based charts
including but not limited to
growth charts, maternity and
paediatric specific templates
5.2.6

Describe any provisions for


templates that are user (non-
programmer) customizable as
needed by provider
role/discipline. Indicate costs if
programming support is required
to update/create new templates.
5.2.7 Explain the systems ability to
export/import templates to and
from other installations.
5.3 Summary View
The EMR should provide a
summary view:
5.3.1 configurable by provider
and tied to their use permission
profile.
5.3.2 places all pertinent
information including problem list
in a single view
5.3.3 supports searching,
scrolling and drill down
5.4 Progress Notes
The EMR should provide
progress notes:
5.4.1
including user defined
templates, goal statements,
education materials provided,
follow-up plans, medications
prescribed, etc.
5.4.2
using a structured SOAP
format (Subjective-what the
patient says, Objective-what is
found by
observation/examination,
Assessment-may be per
condition specific template,
including “Not Yet Diagnosed”,
and Plan)
5.4.3 that automate multi-
disciplinary diagnostic and
intervention coding
5.4.4 that provide for electronic
signatures
5.4.5
that support the capability
to collect data elements defined
by the associated clinical
practice guidelines
5.5 Problem List
The EMR should provide a
problem list:
5.5.1 that provides a problem
status summary
5.5.2 separates active/inactive
problems
5.5.3 updates active problem list
from progress notes
5.5.4 that provides the capability
to create, review, or amend
information regarding a change
on a problem status
5.5.5 that provides the ability to
archive problems complete with
status history
5.5.6 that provides the ability to
link problems with results
5.6 Care Plan
The EMR should provide a care
plan:
5.6.1 that provides the ability to
create user defined
multidisciplinary care plan based
on expected outcomes

that provides the ability to:


5.6.2.1 - patient goals
5.6.2.2 - patient understanding of the
care plan including treatment
plans
5.6.2.3 - patient safety plan and
actions
5.7 Medication Management
Highly desirable that the EMR
medication management:
5.7.1
provide formulary
management for prescriptions
including preloaded tables and
electronic updates (provided by
BC PharmaCare )
http://www.hlth.gov.bc.ca/pharme
/outgoing/index.html
5.7.2
create/refill prescriptions
at point of care with optional print
and/or e-fax transmission
5.7.3
enable efficient physician
entry of prescriptions that
minimizes the opportunity for
prescribing errors. Describe
error prevention mechanisms.
5.7.4 provide integrated drug-
drug, drug-disease interaction
checking and allergy alerts
5.7.5
update patient medication
list for each new
prescription/refill including dose,
and course, OTC and non-
formulary drugs
5.7.6
EMR should retain patient
preferred pharmacy information
to assist with prescriptions.
5.8 Referral Management
Highly desirable that the EMR
referral functionality:
5.8.1
Support capture of referral
information (e.g. referral type,
date, reason and provider).
5.8.2 Support customizable
referral letter formats
5.8.3
Ensure the referring and
referred to provider’s MSP billing
number are on the referral
5.8.4
Generate referral letters,
optionally with appropriate
portions of the patient’s record
as necessary, for distribution by
electronic transmission, e-fax,
secured email and/or letter.
5.8.5 Track and report on all
outstanding referrals within a
specified # of days
5.8.6 Use automatic referral
receipt messaging for electronic
referrals
5.9 Consultation Management
The EMR consultation
management functionality:
5.9.1 should use a distinct
storage area for consultant
reports
5.9.2 should update referral
status as required
5.9.3
highly desirable that it
accept & hold reports received
via electronic transmission,
scanned input, e-fax, diskette,
CD and/or secured email for
provider review/approval prior to
association with the EMR.
5.9.4 highly desirable that it
issue “consult received”
messages for electronically
received consult reports
5.1 Work Queue Management
Highly desirable that the EMR
work queue management:
5.10.1 Offer both provider and
rules based triggering of alerts
with notifications to other
providers as necessary
5.10.2 Track & report overdue
preventive care, drug and
disease management items, and
immunizations
5.10.3
· Automatically initiate
recall notifications (for telephone,
mail or e-mail follow-up) allowing
provider review/approval before
MOA action or distribution to
patient.
5.10.4 Highlight abnormal lab test
results for follow-up
5.10.5 Enable providers to assign
tasks to other providers and/or
support staff
5.10.6 Provide on demand view
of task list status by practice, by
provider, by support staff and/or
by patient.
5.11
Patient Information Materials
Highly desirable that the EMR
support:
5.11.1
Patient information
education and handout materials
for all CDM areas at a minimum.
5.11.2 The ability to import
patient information handouts
5.11.3 All patient information
should be customizable.
5.11.4 Handouts should print, fax
or email on request.
5.12 Lab and Diagnostic Results
Lab and Diagnostic Result
Reporting:
5.12.1 Electronic receipt of lab
and diagnostic results is highly
desirable.
5.12.2
Automated downloads of
result reports and/or images to a
holding area (for provider
authorisation to import to
individual patient records) is
acceptable. List available
options including the security
and data integrity measures
employed.
5.12.3
Lab results should be
recorded as discrete data where
appropriate. Describe
edits/validations available for
results entered manually.
5.12.4

Highly desirable that


tabular and graphical views
indicate where results originated
(which lab- accommodating
possible variations in test
process/normal values/ranges)
5.12.5
Paper/fax based result
reports require manual review
before entry. Describe the
mechanisms used to highlight
abnormal results.
5.13 Clinical Decision Support
(CDS)
The EMR should provide
Clinical Decision Support:
5.13.1 that provides access to
medical research and literature
databases
5.13.2

that provides rules based


alerts, drug/drug and
drug/disease interaction
checking and contra indications
are sometimes considered to be
decision support. Describe any
additional decision support
capabilities provided and/or
planned for in your EMR.
5.14 EMR Recap (OPTIONAL)
5.14.1 Use the space below to describe
the features of the application
that you feel are noteworthy in
meeting the criteria.

5.14.2 Use the space below to describe


the features that provide
workflow efficiencies for the user.
6 Patient Access/Update
6.1.1 Describe how your system
supports patient review of
personal demographic and
selected health data.
6.1.2 Describe how your system
supports patient access to
record/update demographics,
health history, personal risk
assessment,
immunizations/vaccinations
and/or care plan progress.

If available, describe how the


system handles patient-entered
data with regards to:
6.1.3.1 identification of the data
source,
6.1.3.2 entry in a structured
format,
6.1.3.3 review/approval of data by
provider prior to inclusion in the
EMR.
6.1.3.4 patient update restrictions
for data previously entered data
by individuals other than
themselves.
6.1.3.5 security to protect the
privacy of patient data.
6.1.4 Providers are interested in
(offering) web-sites that give
patients access to education
materials, approved health links,
practice-specific templates for
collecting patient data, etc.
Describe any such capabilities /
services that you provide.

7 Reporting
7.1.1 Describe in general terms how
reports are produced and stored
by the system (i.e. exported to
Word, proprietary report viewer)
Provide a list of standard report
templates that are provided with
the system including but not
limited to:
7.1.2.1 Activity reports,
7.1.2.2 PHCO population-based
detail and summary reports,
7.1.2.3 PHCO access reports,
7.1.2.4 Chronic disease
management reports by
diagnosis, and
7.1.2.5 PHCO access reports.
7.1.2.6 Also include whether the
reports are tabular, periodic (e.g.
monthly, YTD, etc.), ad-hoc,
OLAP, KPIs, etc.
7.1.3 Describe tools available for
developing customized user-
defined reports. This might
include a proprietary report
writer, or a third-party tool such
as Crystal Reports.

7.1.4 Describe the reporting security


features.
8 System Management
8.1 Backup & Recovery
8.1.1 Highly desirable that the system
provide effective, automated
backup and recovery
mechanisms.
8.1.2 Describe the procedures
and tools necessary for daily
incremental and weekly
complete backups.
8.1.3 Describe the procedures
and tools necessary for
timely and complete
data/system recovery.
8.1.4 Describe how recovery
processes are validated prior
to resuming routine
processing.
8.1.5 State the frequency of on-site
testing of backup, recovery and
validation processes.
8.2 Data Archiving
8.2.1 Highly desirable that the
PM/EMR support data archiving
to retain patient data in a
recoverable manner while
ensuring the most effective user
interface response time.

8.2.2 Describe the circumstances and


procedures for archiving the
records of moved or deceased
patients.
8.2.3 Highly desirable that archived
patients not be reported on recall
reports.
8.2.4 Highly desirable that Archived
patients be reported in practice
summary reports.
8.2.5 Archived patients are included in
ad hoc and CDM reports that are
time dependent where
appropriate.
8.3 System Administration
As discussed in the body of the
RFP, the target implementation
of this project will include the
centralized administration of
multiple site installations.
Describe any tools available in
the system for the remote
administration and management
of these installations including
but not limited to:

8.3.1 Tools to enforce standard


data entry between practices in
the network,
8.3.2 Tools for the centralized
deployment of upgrades,
updates, patches, etc.,
8.3.3 Tools for remotely
supporting the practice
installations.
8.4 Data Warehousing
In addition to centralized
management of practice
installations, there will be a
future requirement to collect
information from these practices
into a central repository for the
purposes of data warehousing.
Describe any tools available in
the system for the purpose of
data warehousing including but
not limited to:

8.4.1 Ability to poll an individual


practice's PM/EMR application to
extract data remotely,

8.4.2 Tools to help cleanse data


from practices in the network,

8.4.3 Tools to help consolidate


data from the separate practices
in the network,

8.4.4 Tools to report the data


back to the practices
9 External Interfaces
9.1 Health Registry
Integrated access to Health
Registry is strongly
recommended.
Physicians and other health
providers need to accurately
identify patients to provide
appropriate care, accurately
diagnose symptoms, prescribe
safe and effective medication
and coordinate diagnostic and
treatment programs. The Health
Registry provides functions to
confirm or obtain a PHN and
participate in the process of
maintaining accurate patient
demographic data that is used
throughout the province
The Health Registry Compliance
Specification is available at

http://healthnet.hnet.bc.ca/hds/approved_standards/sd99-01_hnt_health_registry_std.

9.1.1 Use the space below to


describe the current and/or
planned integration of the
PM/EMR and Health Registry.

9.2 Provider Registry


The Provider Registry is
intended to maintain information
on all licensed and unlicensed
providers in BC including unique
identifiers, credentials and
contact information. Use of
Provider Registry will support
authentication and transmission
of health data between
providers.

It is strongly recommended that


Suppliers plan for the future
implementation of Provider
Registry.
Information on the Provider
Registry is available at:
http://healthnet.hnet.bc.ca/catalogu/provider_registry/index.html

9.2.1 Use the space below to


describe any planned
integration of the PM/EMR and
Provider Registry

9.3 Client Registry


The Client Registry is intended to
maintain information on all
clients in BC including unique
identifiers, and contact
information.
It is strongly recommended that
Suppliers plan for the future
implementation of Client
Registry.
9.3.1 Use the space below to
describe any planned
integration of the PM/EMR and
Client Registry
9.4 Chronic Disease Management
(CDM)
9.4.1 Highly desirable that the CDM
electronic data interchanges be
done in accordance with the BC
MOHS CDM policy and
procedures. Information on
CDM in BC is available at:

http://www.healthservices.gov.bc.ca/cdm/index.html

9.4.2 Highly desirable that the EMR be


able to pickup CDM registers by
physician and/or practice.

9.4.3 Highly desirable that the EMR be


able to report any differences
between the Ministry register and
the /physician register to assist
the physician in providing
planned, pro-active care to
patients with chronic diseases

9.4.4 Highly desirable that the EMR be


able to compile, format and
submit CDM data effective
January 2004.
9.5 Pharmanet
9.5.1 Integrated Medical Practice
Access to Pharmanet (MPAP) is
highly desirable. Willingness to
integrate this service by a
mutually agreeable date is highly
desirable.
MPAP will ensure that the
provider has on demand access
to a patient’s entire medication
history, provides drug to drug
interaction checking on the
actual medications that have
been dispensed to the patient,
reduces pharmacy/physician
phone calls and improves patient
care and convenience. The
MPAP Compliance Specification
is available at
http://healthnet.hnet.bc.ca/catalo
gu/products/medpract.html

9.5.2 Use the space below to


describe the current and/or
planned integration of the
software and Pharmanet.
9.6 Lab Test & Diagnostic Result
Reporting
9.6.1 Lab test & diagnostic result
reporting from public and/or
private facilities by electronic
interface is highly desirable. For
example, accept electronic lab
reports from PathNET, or a
hospital that serves a customer
locale. Willingness to supply
such services in a mutually
agreeable timeframe is a
requirement.

9.6.2 Use the space below to


describe the current and/or
planned electronic lab test and
diagnostic result reporting
capabilities.

9.7 BC Cancer Agency


9.7.1 An electronic interface to accept
patient recall notices from the BC
Cancer Agency and integrate
them with the Work Queue
(section 5.1) for follow up is
highly desirable.

9.8 Connectivity
9.8.1 Highly desirable that the
proposed solution support
comma delimited, file import and
export formats.
9.8.2 Highly desirable that the
proposed solution support
integrated connectivity among
health providers.
9.8.3 Describe connectivity standards
available with the solution such
as ODBC, SQL, SSL, 128-bit
encryption, etc.
9.8.4 Describe any messaging
standards available with the
solution, such as XML, HL7,
SMTP, etc.
Describe the current and/or
planned EMR connectivity to
(include if they are to be met by
configuration or programmatic
changes):

9.8.5.1 Other PM/EMR vendors


9.8.5.2 Meditech HCIS
9.8.5.3 BC MediNet
9.8.5.4 iPHIS – the public health system
– http://www.ciphs.ca/pdfs/i-
PHIS_Overview.pdf

Desirable iPHIS connectivity


includes:
a link to iPHIS for
Immunization data; including an
inquiry to determine status and
updating of the Immunization
Registry component of iPHIS if
an immunization is given.
provisions for reviewing
and reporting on Vaccine
Associated Adverse Events
(VAAE) and any other
contraindication

10 Future Capacity
10.1.1 Highly desirable that suppliers
develop familiarity with emerging
provincial and national standards
to ensure the timely
implementation of approved
standards in the EMR, for
example,

Electronic Medical
Summary (BC),
Electronic Signatures
(federal),
Electronic Prescription O/E
(federal),
Canada Health Infoway
architecture blueprint.
10.1.2 Use the space below to describe
your approach to maintaining
currency with approved and/or
mandatory standards indicating
when additional fees may be
incurred.

11 Scalability, Performance &


Availability
11.1.1 Highly desirable that the system
be capable of 24x7 availability.
Scheduled outages for backup
and updates are acceptable.

11.1.2 Highly desirable that the system


employ accurate data
synchronization when data is
recorded remotely for
subsequent entry to the EMR
database.

11.1.3 Highly desirable tha the EMR be


capable of a response time of 3
seconds or better from request to
display.
11.1.4 State the maximum number of
(active) users and patients
currently supported in a real-life
implementation.
11.1.5 Describe how capacity planning
is done to ensure expected
practice growth (# users, #
patients, growth in data storage
requirements) can be
accommodated.

12 Services
12.1 Section Not Applicable
12.2 ASP or Local Installations
12.2.1 State your software operating
environment (local and/or ASP)
and describe your available
environments.
12.3
Software Installation Services
12.3.1 Describe the installation services
provided indicating whether
installation is performed locally
or remotely and any related
costs.

12.4 Implementation Services


12.4.1 Highly desirable that the supplier
provide comprehensive
implementation support for
projects that are likely to require
phased software implementation
and work process re-design.

12.4.2 Use the space below to describe


the services provided indicating
who will provide the services and
any related costs.

12.4.3 Provide an example


implementation plan in an
Appendix to your response.
12.4.4 Highly desirable that the supplier
provide a single point of contact
for client sites during the
implementation period. Use the
space below to describe the
organization and skill set of your
implementation team.

12.4.5 Use the space below to


describe your issue tracking,
resolution and escalation
process.
12.5 Training Services
12.5.1 Highly desirable that the supplier
provide comprehensive and
effective user training for projects
that are likely to require phased
software implementation and
work process re-design. Ensure
your example implementation
plan includes usual training
points.

12.5.2 Use the space below to


describe the training tools,
materials and services provided
indicating trainer experience and
any additional costs for training
during initial implementation and
subsequent software upgrades.

12.5.3 Highly desirable that the supplier


provide on-site training unless
otherwise agreed at contract
negotiation.
12.5.4 Highly desirable that the supplier
provide a training environment
with non-production data and full
functionality including:

12.5.4.1 identifiable at a glance


(e.g. different background
colours);
12.5.4.2 require a non-production
user id.;
12.5.4.3 operate without the risk of
corrupting live data or
transmission to other production
systems.
12.5.5 Highly desirable that the supplier
provide cross-training for end
users and local system
administrator(s).
12.5.6 Use the space below to
describe the training
programme.
12.5.7 Provide examples of training
plans/materials in an Appendix to
your response.
Section 8.2c Provide sample software
documentation with respect to
the PM/EMR solution to illustrate
the standard of technical
documentation that will be
provided to FHA

12.6 Data Conversion Services


12.6.1 Highly desirable that the supplier
be able to perform a data
conversion from any existing PM
systems into new system.

Use the space below to


describe initial implementation
data conversion services and
limitations including:

12.6.2.1 Tools that assist/speed the


entry of pre-existing charts
Conversion of pre-existing
databases. Specifically state

12.6.2.2.1 - how long data transfer will


take and,
12.6.2.2.2 - mechanisms to manage
data in the time gap between
data conversion from existing
systems and actual
implementation
12.6.2.3 for Primary Health Care
patient registers
12.6.2.4 Medical Software Vendors’
Association (MSVA) patient
demographic data import.

12.6.3 Use the space below to


describe support for future
PM/EMR conversion activities
such as:
Adding new providers with
historical patient EMR.
Removing providers while
managing patient data in
accordance with record keeping
requirements.
Exporting practice/patient
data to support migration to a
new supplier (e.g. a provider
leaves the practice)

13 Support
13.1 Software Support
13.1.1 Highly desirable that the
suppliers provide a written
statement of their policies and
procedures regarding software
support for operational clients as
an appendix to the RFP
response. Support policies
should clearly:

define call priority


classification and response,
resolution and escalation times;

define processes for bug


fixes versus upgrades and
enhancement schedules;
describe how 24x7
support will be carried out and if
it is not provided, describe the
support availability that is
provided;
identify any
hardware/software requirements
that must be supplied by the
client for software support
services

Section 8.4 Proponent must provide


commitment to meet or exceed
the following service levels

Severity Level 1= Entire system


failure affecting at least one
PHCO: Response = Immediate;
Target Resolution = 30min

Severity Level 2=Module failure:


Response = immediate; Target
Resolution = 1hour

Severity Level 3= Function Loss


no workaround: Response =
1hour; Target Resolution = 1day

Severity Level 4= Function Loss


with workaround: Response =
immediate to specify
workaround; Target Resolution =
3days

Severity Level 5=
Enhancement/Upgrade request:
Response = 1 day to log request;
Target Resolution = Next
quarterly release

13.2
Master File and Tables Support
13.2.1 List all available master
files/tables and describe update
processes and schedules for
master files and code tables, and
the processes for converting
from one diagnostic code to
another, including but not limited
to:
Multi-disciplinary
Diagnostic Codes (e.g. ICD9,
ICD10-CA, ICPC, CSA body
codes for WCB reporting, etc.)

Pharmacare Formulary
MSP Fee Schedule, WCB
fee items, etc.
13.2.2 State the users ability to
customize and/or create user
preferred subsets.
13.2.3 Provide examples of on-line
context sensitive help, and an
example chapter of user guides
and operating manuals as an
appendix to your RFP response.

13.3 User Group


13.3.1 Describe your user group
including mandate, # members,
meeting schedule and ability to
establish development priorities.

13.4 Software Enhancements and


Upgrades
13.4.1 Describe your release schedule
for critical bug fixes, software
enhancements and upgrades
including:
Those covered by annual
licensing fees;
Custom enhancements
and upgrades specifying
development fees (hourly rates,
flat rate for extract, etc);
Process for incorporating
custom enhancements/upgrades
into a master version of the
software, available to all users.

14 Software Version Control


14.1.1 Describe your process of
software version control
including the use of
development, test, production
and training environments at the
supplier and customer sites.

14.1.2 Highly desirable that customer


written approval be obtained
prior to installation of bug fixes.

14.1.3 Highly desirable that customers


receive advance notification of
software upgrades including
comprehensive documentation
on new and changed
functionality and features.

14.1.4 Highly desirable that customer


written approval be obtained
prior to installation of software
upgrades.
14.1.5 Highly desirable that software
installation provide backups and
rollback to earlier operational
software version should it be
required.
Description

Excellent

Good

Acceptable

Marginally Acceptable

Weak Response

Unacceptable

You might also like