B1.1. The period during which the Vendor provides
Software Support are set out in the Customer's Service Level Agreement Schedule A.
B1.2. A current
Software Support Licence is a mandatory requirement for continued used of the Software. The Vendor undertakes to maintain the
supplied Products during the term of this Contract and provide such corrections
as are necessary to ensure the requirements set out in the Customer’s
Functional Specifications are fully met.
B1.3. The Software Support Licence does not include the cost of Vendor
supplied hardware repairs or replacement parts after the two year hardware
warranty period expires. Please see section C7 for further details.
B1.4. The Vendor will
provide support staff that are familiar with the software and the Customer’s
business environment.
B2.1. Customer Support Requests can be made via contact
details listed here:
Name | Email/ Telephone | Escalation Point and Coverage |
K2MS | Call 1300
432 204 | First point of contact all faults, queries – standard hours |
Peter Hunt, | Call 0408
321 368 | Formal Complaint if unsatisfied with previous actions – standard
hours |
Registered
Office/ Warranty Returns | Correspondence |
K2
Medical Systems Ltd | K2
Medical Systems Ltd |
B3.1. All
Customer Support requests will be logged in the Vendor’s ticketing system and the
Customer given a unique reference (ticket) number. Faults will be classified and handled
according to the Fault Definition table summarised below in section C1.3 and
further detailed in section C2.
B3.2. A Vendor generated Product Incident Report
(PIR – see section C3) will not be created unless it is determined that either
a product issue has been identified or a request for software change required.
B3.3. Priority Ratings are assigned to ensure that
Product Incidents are addressed appropriately depending on incident severity,
fault or request; see section C1 below. Priority Ratings and Fault Classifications shall be assigned by the
Vendor’s Systems Manager in consultation with the Customer.
B3.4. If a product
fault is identified or suspected, the Vendor will log the details of the fault
in a PIR and the Customer will be notified by email of the PIR number, details
reported and the fault classification. This is the Initial Response Time; see section C2 for timescales.
B3.5. If a request for software change is made the Vendor
will work with the Customer to clearly specify the change requirements before
assessing the change is covered under the existing system functional
specification, or is additional functionality that attracts a software
development charge. If a charge is to be
applied this would require the formal sign-off by the Customer’s Budget Holder.
C1.1. Priority ratings and Fault classifications
will be assigned by the Vendor’s Systems Manager in consultation with the
Customer, as follows:
Priority | Definition |
RED | Clinical
Event: Faults or the system being inoperable in whole or part that have led
to patient injury/death, or could lead to patient injury/death. Refer to the current version of the TGA
Guidelines on Reporting Adverse Events for details. |
YELLOW | Faults
that render the Vendor’s Software inoperable, or render a major function
inoperable. |
GREEN | Limited
impact on the business of the Customer. Typically, intermittent or partial faults
where the System, service or strategic component is still usable or there is
a suitable alternative. Not
likely to increase clinical risk or clinical risks are mitigated. |
BLACK | Low
priority is given to an issue that is mainly cosmetic in nature. |
C1.2.1. Clinical
Events are events where there has been a patient injury or injury to the
Customer’s staff or where there was a likelihood of such injury through the
system being inoperable in whole or part or use or misuse of Vendor software.
C1.2.2. The
Customer must notify the Vendor within 24 hours of any Clinical Event where it
is responsibly felt that Vendor software has been a compounding factor.
C1.2.3. It
is acknowledged by the Customer that the Vendor has statutory responsibilities
to inform the TGA of serious Clinical Events.
C1.3. On
investigation, the Vendor may further classify Priority TYPE 1, 2 & 3 Faults
into the following categories:
TYPE 1 Faults are related to the Customer infrastructure upon which the Vendor’s software is reliant. This includes network infrastructure, server hardware, internal wiring and hardware supplied by the Customer. The Customer is responsible for the Response & Resolution timeframes for TYPE 1 Faults.TYPE 2 Faults are related to the configuration of the software, database, Vendor supplied dependencies (hardware or software) and all other faults not listed in Schedule B2 that DO NOT require a software development/formal validation cycle to correct.TYPE 3 Faults are within the Vendor supplied Software, requires a software development cycle to correct and require the deployment of a new software version. The Vendor will work with the Customer throughout the resolution time to agree possible interim solutions.In our experience, TYPE 1 and TYPE 2 Faults are by far the most common sources of fault leading to some loss of operability (>99%). TYPE 3 Faults leading to a major loss of operability (YELLOW) are very rare (<1%). The resolution of system faults are not chargeable.
C1.4. Support Response Time - will be measured from
the time the call was logged to the time the Vendor gains remote access to the Customer’s
System. For the quoted response timeframes to be honoured, the Customer must provide
the Vendor with independent remote access to the System that will be actively
managed (Please refer to Schedule B – Customer Responsibilities). Time measures are Business Time measures, the
Vendor’s published hours of business operation.
C1.5. Resolution Time - is the time it takes for the
identified fault to be corrected within the System. For the avoidance of doubt this is not the
length of time that the System will remain out of action, in part or in
total. The Vendor will use all
reasonable endeavours during the resolution period to restore any lost
functionality by way of, for example, software rollbacks, whilst a permanent
solution is engineered.
C1.6. If, after investigation, the fault is
reclassified, the timings for that priority will apply from the time of
reclassification.
C1.7. The Vendor commits to up-times of 99% business
hours over an annual period. PLEASE NOTE:
Calculation of up-time excludes periods of outage caused by Customer dependent
infrastructure.
Priority | Definition | Response
Time | Resolution
Timeframe |
RED | Faults or the system
being inoperable in whole or part that have led to patient injury/death, or
could lead to patient injury/death. Refer to the current version of the TGA Guidelines on Reporting
Adverse Events for details. | 10
mins | 12
hours |
C2.1. Clinical incident Response Actions
Stage | Timescale | Customer Action | Vendor Action |
1 | Immediate | Suspend system usage. Notify the Vendor by phone and optionally
follow with a fax or e-mail. Notify Managers and Users. Commence business continuity procedures. | Log fault call and provide the Customer with a
log number (PIR). Raise a fault and inform the Quality &
Regulatory Affairs Manager and Director. The Quality & Regulatory Affairs
Manager will raise an adverse event report and submit it to the TGA as per
Vigilance Reporting Guidelines. Commence investigation into the fault. |
2 | As soon as possible, but within 16 hours
unless by mutual agreement. | Hold a joint review
of the cause of the incident and decide if the System can be brought back
into clinical use. If User can
re-start: Reclassify the fault as Priority YELLOW (1); If User cannot re-start:
The review will decide on the next course of action. | |
Priority | Definition | Examples | Response
Time | Resolution
Timeframes |
YELLOW Priority 1 or HIGH | Faults that render the Vendor’s Software
inoperable as a whole, or render a major function inoperable | The System is unable
to be accessed. Main System
malfunction — important changes or transactions cannot be recorded. The PAS interface is
not working when the fault is defined, due to a fault with the Vendor’s
Deliverables. There is a
demonstrable failure to collect cardiotocograph (CTG) signals correctly. CTG Software system
administration essential to the continued correct running of the System as a
medico-legal record cannot be performed. | 10
mins | Type 1 Fault Customer responsibility Type 2 Faults 10 hours Type 3 Faults 40 hours (8 business days) |
GREEN Priority 2 or MEDIUM | Limited impact on the business of the
Customer. Typically, intermittent or
partial faults where the System, service or strategic component is still
usable or there is a suitable alternative. Not likely to increase clinical risk or
clinical risks are mitigated | Module, System or PAS interface intermittently
malfunctioning. Reports provided or accepted by the Vendor for
maintenance cannot be produced or contain incorrect information, and no
workaround acceptable to the Customer is available. | 4
hours | Type 1 Fault Customer responsibility Type 2 Faults 24 hours Type 3 Faults 280 hours (35 business days) |
BLACK Priority 3 or LOW | Low priority is given to an issue that is
mainly cosmetic in nature | Screen layouts
require amendment. Routines or
updates/processes need minor changes. Minor presentation
issues in standard reports need changes. | 2
business days | Type 1 Fault Customer responsibility Type 2 Faults not applicable Type 3 Faults not applicable |
C3.1. A PIR is
resolved when a fix has been verified and supplied to the Customer or when the
Customer accepts that the PIR has been sufficiently captured on a Scope of Work
to form part of a planned future update.
C3.2. The Customer is
informed about the management and progress of PIRs at intervals from the time
the problem is reported. These include
at each point of escalation.
C3.2.1. Investigation Plan
C3.2.2. Explanation Reports
C3.2.3. Resolution Plan
C3.3. Where the resolution of a PIR is not
progressing to the satisfaction of the Customer the escalation procedure may be
involved.
C3.4. PIR Definitions
– a PIR encompasses
C3.4.1. Products faults, actual or perceived
C3.4.2. Incidents or
notable occurrences
C3.5. PIRs in the
following areas are subject to the Vendor’s fault management procedures.
C3.5.1. Application software
C3.5.2. Users (contract deliverables, navigation, security etc.)
C3.5.3. Service levels
C3.6. Reporting and
recording problems – the Vendor will provide reports as and when requested by
the Customer.
C3.6.1. PIR analysis – summarising the number of
problems by priority rating.
C3.7. The PIR
resolution procedures do not apply to recovery from widespread and exceptional
problems that combine to constitute a ‘disaster’.
C4.1. The software is
comprised of a suite of applications (Athena modules, Guardian modules, Central
Station, etc.); interfaces (PAS demographics, PAS ADT etc.); an underlying
clinical model (metadata); and reports.
C4.2. Applications –
applications contain no site localisation information and are therefore generic
across all Customers.
C4.3. Application Updates – provide minor
enhancements to the functionality and rectify application errors (‘bugs’)
identified in previous versions. Notifications of application updates will be sent to the Customer as
released and will be deployed to the Customer as requested. There will be no charge for the deployment of
Application Updates where these can be deployed remotely by the Vendor. If a site visit is required then reasonable
onsite charges will be payable and must be agreed prior to installation.
C4.4. Application
Upgrades – relate to features not included in the Customer’s Defined Scope of
Work for the supplied Software and will be available at an additional cost.
C4.5. Change Requests
– bespoke change requests will be chargeable unless deemed sufficiently generic
that they would be of benefit to other Customers using the Vendor’s
applications. This will be exercised at
the Vendor’s sole discretion.
C5.1. The Clinical Model is abstracted from the
software and contains all localisation information of the Customer. The Clinical Model comprises the User
interface; the data items to be collected; the data collection wizards; the
display of data items (text, tables and graphs); templates for printouts of
data; and report templates.
C5.2. Clinical Model changes are bespoke to the
Customer and will be chargeable after the initial System GO LIVE. Such charges will cover the time required to
specify; implement; test; validate; release; and deploy changes. The charge will be estimated based on an
assessment of the time required to facilitate the change. The current Vendor daily rate will then be
applied. All changes and charges will be
agreed with the Customer prior to commencement of the work.
C5.3. The only exceptions to this charging
model are:
C5.3.1. ‘Bugs’
in the Clinical Model which are not chargeable. The definition of a ‘bug’ is a repeatable error, rendering a User unable
to enter data, or progress further through a work flow. This does not include cases where new fields
would be required, or the structure of the data being collected is being
altered.
C5.3.2. Statutory reporting requirements of
individual Health Authorities. The
Vendor agrees to discount such Clinical Model changes that may be required to
satisfy the Customer’ reporting specification at the Vendor’s current daily
rate ($1,250 per day but subject to review). Where there is a national reporting requirement and it can be deployed
to all affected Customers centrally there will either be no charge or a
proportionate charge across all affected sites.
C6.1. The Vendor provides a catalogue of report
templates as part of the purchased product as well as advanced reporting tools
allowing the self-authoring of reports based on the data collected and stored
in the System. In cases where the
Customer requires additional report template writing support the Vendor will
provide a reasonable level of support for this without charge. However, in cases where extensive report
writing or consultancy is required a daily rate will apply.
C6.2. The only exception to this will be is
Statutory Reporting requirements change as detailed in point C5.3.2 above.
C7.1. Each K2MS Portal has a two year return to
base warranty ending two years after the original supply of this hardware. Warranty of these units commences at GO LIVE.
C7.2. The
return and insurance of the Portal to the Vendor (as detailed in section B2.1) is
the responsibility of the Customer.
C7.3. The
Customer should contact the Vendor before any unit is returned. An RMA (Return Material Authorisation) number
will be issued, which should be quoted in any future correspondence.
C7.4. All
K2MS Portals should be decontaminated as per the Customer’s best practices
before they are returned.
C7.5. Warranty
is limited to the K2MS Portal only. Cables are excluded.
C7.6. Extended
Warranty (one to three years) can be purchased. Details are available upon request.
C7.7. Repair
and return of hardware under warranty is within fifteen business days of
receipt of the unit by the Vendor.
C7.8. For
K2MS Portal repairs out of warranty, the unit should be returned to the Vendor;
a quotation will be provided for the repair; the unit will be returned within ten
business days of receipt of a valid purchase order.
C7.9. If
the Vendor has supplied the cart or mounting arm, this is covered by the
Manufacturer’s standard 12 month warranty. The Vendor will coordinate repairs or replacements with the Supplier
during the warranty period.
C7.10. The
Customer is responsible for the fixing of mounting arms to walls and is
responsible for the fixing of K2MS Portals to the arm.
C7.11. The
Customer is responsible for routine maintenance of the arms and carts and to
ensure that they remain operationally safe at all times.
C7.12. Cart and mounting arm repairs outside of the
warranty period will be chargeable at the Supplier’s rate and shall be
coordinated by the Customer.
C8.1. If the Vendor has supplied Central
Station hardware this is covered by the Manufacturer’s standard warranty.
C8.2. If the hardware has been supplied, the
Vendor will coordinate PC repairs or replacements with the Supplier during this
warranty period.
C8.3. Outside of the warranty period PC repairs
or replacement costs will be chargeable at the Supplier’s rate and shall be
coordinated by the Customer.
The Customer is responsible for keeping a record
of operation of the System, which shall include the following details:
D1.1. A written
record of all faults or queries reported to the Customer Support Staff by
System Users, including the date and time the report is received.
D1.2. A written
record of all fault calls or queries reported by the Customer to the Vendor’s
Help Desk, including the date and time the report is made and the agreed
priority rating.
D1.3. The maintenance
of a file containing the Customer’s copy of any Fault Reports raised.
D2.1. The Customer
must allow unfettered, unlimited and 24 hour access to the database and servers
upon which the Vendor’s software is installed for support purposes.
D2.2. Access will be
via remote access using agreed means such as VPN
D2.3. Access will be
authorised by the Customer following the agreed Customer based governance and
IT Security Process.
D3.1. The Customer
shall perform any action in connection with the correction of any failure of
the Support Services to meet a Service Level or Levels, which are agreed by the
Customer and the Vendor at the material time to be the responsibility of the
Customer.
Unless defined within Schedule A of this SLA as
being the responsibility of the Vendor, the Customer will be responsible for:
D4.1. Maintenance of
all Operating System software (e.g. Microsoft Windows), including software
upgrades required for the User workstations (PCs), in accordance with the
standards and recommendations provided by the Vendor (available on request),
including but not limited to:
D4.1.1. Microsoft
Server software
D4.1.2. Back-up
software/ schedules/ procedures (Vendor recommendations can be viewed here)
D4.1.3. Anti-virus
software (the Customer will be expected to take all reasonable precautions to
ensure that any Customer software is free of viruses).
The Customer will be responsible for the
maintenance of the following hardware items:
D5.1. K2MS Portal
mounting hardware and carts if provided.
D5.2. The central
server hardware and System software.
D5.3. All PC and
terminals to be used with the System.
D5.4. All printers to
be used with the System.
D5.5. Any other
peripheral equipment for use with the System including interconnecting cables
(excluding K2MS supplied Bedside Portal interconnecting cables).
D5.6. All Local Area
Network hardware.
D5.7. Wireless networks
if used.
D5.8. All
communications equipment to be used with the System.
D5.9. The database
server.
The Customer will be responsible for the
following site maintenance:
D6.1. Maintenance of
suitable accommodation in which the central ‘host’ hardware is located.
D6.2. Maintenance of
electrical power supply, power points and environmental control system, in
accordance with the environmental standards defined by the relevant hardware
suppliers.
D6.3. Maintenance of
communications networks, end user network access points and fly leads.
The
Customer’s System Administrator will be responsible for:
D7.1. Customisation
D7.1.1. Ensure
passwords and access rights are set up and maintained in accordance with agreed
standards.
D7.1.2. Test all system
changes carried out by the Vendor.
D7.1.3. Definition of
new reports.
D7.1.4. Liaise with the
Vendor on any future System changes required.
D7.2. Organisational
procedures
D7.2.1. Ensure any
actions for organisation change are carried out.
D7.2.2. Set up manual back
up procedures.
D7.2.3. Set up internal
support procedures.
D7.3. Training
D7.3.1. Ensure training
facilities are set up for training courses and that Customer staff attend.
D7.3.2. Train any
Customer staff who need to know how to use the System who have not already been
trained by way of any formal training provided by the Vendor.
D7.4. Communication
D7.4.1. Act as point of
contact with the Vendor’s Help Desk.
D7.5. Expertise
D7.5.1. Be the Customer
expert user in all aspects of the System and the internal point of contact for
any Customer staff with queries on the use of the System.
D7.5.2. Keep up-to-date
with new developments in the System and, where necessary, attend training
courses to refresh and increase areas of expertise.
D7.6. Documentation
D7.6.1. Keep the System
Reference Manual up-to-date.
D7.6.2. Assist in the
production and maintenance of local user training documentation.
D7.7. System
Integrity
D7.7.1. Check on and
maintain patient record integrity.
D7.7.2. Maintain an
error log of Type 1 Faults.
D7.7.3. Produce a
monthly report showing all issues logged to relevant internal stakeholders and
the Vendor.
D7.7.4. Ensure back-ups
are performed in accordance with the procedures and/or recommendations provided
by the Vendor (available on request).
The Customer will be responsible for:
D8.1. Provision of Vendor
access to the System for remote diagnosis and repair.
D8.2. Provision and
maintenance of any additional security measures (e.g. “dial-back modems”,
firewall systems, etc.) to ensure conformance to the Customer’s security
standards, where appropriate.
D8.3. Providing reasonable
access to appropriate Customer staff for discussion and resolution of technical
or other issues which may arise from time to time during the provision of the
Support Service.
The Customer will also be responsible for:
D9.1. Returning the K2MS
Platform / Portal for repair.
D9.2. To return
products, the Customer must contact the Vendor (see Schedule D) and receive a
Return to Manufacturer Authorisation (RMA) number within the return policy
period applicable to the product to be returned.
D9.3. The Customer
must return the products to the Vendor in their original or equivalent
packaging, prepay shipping charges, and insure the shipment or accept the risk
if the product is lost or damaged in shipment. (The Vendor recommends that the Customer retain 3 to 5
original shipping cartons for this purpose. The Customer can purchase
additional shipping cartons for $100 each).
D9.4. Any hardware
returned to the Vendor must be decontaminated in line with the Customer’s
current decontamination procedures.
D9.5. Before you ship the product(s) to the Vendor, ensure data on the hard
drive(s) is backed up along with any other storage device(s) in the
product(s). Remove any confidential,
proprietary, or personal information and removable media such as USB storage
devices. The Vendor is not responsible for any confidential, proprietary, or
personal information; lost or corrupted data; or damaged or lost removable
media.
D10.1. Undertaking first line support of the products and any supporting Systems/ hardware should be carried out by the midwifery support staff, IT support, or other agreed party for the Customer. Recommended Customer Issue Escalation Process
D10.3. Using Guardian Bedside Diagnostic 'Spanner’ tools to investigate problems with:
D10.3.1. Database.
D10.3.2. Central Station.
D10.3.3. Fetal Monitors.
D10.3.4. Checking connectivity of K2MS Portal
units with fetal monitors.
D10.3.5. Annual inspection of K2MS Portal cables
for wear and tear.
D10.3.6. Annual inspection of K2MS Portals for
safety, cleanliness and functionality.
D10.3.7. Carrying out annual inspection of
mounting solution and carts where applicable.
D10.3.8. Checking that power is available and
connected to K2MS Portals, Central Stations and accessories.
D10.3.9. Removal of suspect or defective units for
return to the Vendor.
D11.1. Undertake second line support of K2MS Systems,
supporting operating system, hardware and IT infrastructure (carried out by a
member of the Customer’s IT Department or a System Champion).
D11.2. Investigate and remedy K2MS Portal network
connectivity Issues as instructed.
D11.3. Carry out manual installs of the K2MS Product as
instructed.
D11.4. Check operating system parameters and amend if
needed.
D12.1. The Service Charges will be paid annually, with
the first payment becoming due on the GO LIVE-Live date after Final Acceptance
of the System.
D12.2. The due date for all payments shall be thirty
(30) days from the Customer’s receipt of a valid invoice.
D12.3. Subsequent annual charges will be due on the
anniversary of the GO LIVE date.
D12.4. It is the Customer’s responsibility to ensure
that a Purchase Order (PO) is in place to facilitate the issuance of the
Vendor’s invoice.
D12.5. Penalties and overdue interest charges will
apply if the Customer delays raising a PO past the anniversary date.
D12.6. The Vendor will send advanced notifications of
the approaching renewal of the Annual Service Charge.