Peninsula Health: Scanned Medical Records Tender

RFT Part B: The Specification

23 February 2010

RFT Part B – Specification

Peninsula Health

Specification for

Scanned Medical RecordsTender

RFT Part B - Specification

Contents Page

1 / Introduction / 3
2 / Scope of Tender / 5
3 / Service Conditions / 6
4 / Statement of Requirements / 7
4.1 / Key Functional Requirements / 7
4.2 / Functional Requirements / 11
4.3 / Technical Requirements / 29
4.4 / Capabilities/Capacity / 40
5 / Quality Standards & Accreditation / 41
6 / Privacy & Confidentiality / 41
7 / Payment Terms / 41
8 / Further Information / 41

1 Introduction

Peninsula Healthis the primary provider of health care to the residents of Frankston and the MorningtonPeninsula. Services are delivered across numerous sites, from Chelsea in the north to Rosebud in the south. Peninsula Health includes two acute hospitals, a psychiatric service, integrated health service and sub acute services. Sites include:

FrankstonHospital

Hastings Road

FRANKSTON 3199

RosebudHospital

1527 Pt Nepean Road

ROSEBUD 3939

Mount Eliza Centre

Jacksons Road

MOUNTELIZA3930

Frankston Aged Care and Rehabilitation Service

125 Golf Links Road

FRANKSTON 3199

Frankston Community Health Centre

Hastings Road

FRANKSTON 3199

Frankston Community Care Unit

4 Spray Street

FRANKSTON 3199

Michael Court Residential Aged Care

Michael Court

SEAFORD3198

Peninsula Community Mental Health Service

15-17 Davey Street

FRANKSTON 3199

Rosebud Community Rehabilitation Service

288 Eastbourne Road

ROSEBUD 3939

Rosebud Community Health Centre

1527 Pt. Nepean Road

Rosebud 3939

Rosebud Residential Aged Care Service

Point Nepean Road

ROSEBUD 3939

The Mornington Centre

Cnr Separation Street and Tyalla Grove

MORNINGTON 3931

Mornington Community Health Centre

62Tanti Ave

Mornington 3931

Hastings Community Health Centre

Cnr Cool Store Rd and Victoria St

Hastings 3915

2. Scope of Tender

2.1 Tenders

Tenders are invited for the provision of a Scanned Medical Record system across Peninsula Health

2.2 Mandatory Requirements

  • The successful tenderer will be a legal entity with which Peninsula Health is able to contract. The Tender response must describe and provide evidence of the legal status of the Tenderer, including their Australian Business Number (ABN).

2.3 General Requirements

  • The tenderer will demonstrate an understanding of the requirements of the Tender.
  • The tenderer will describe the experience of the Tenderer in relation to the provision of similar services.
  • The tenderer will provide references from or contact details of at least two clients within the health industry for whom the Tenderer previously carried out similar activities. Referees will not be members of the Tender Evaluation Group (TEG) and should preferably be from outside Peninsula Health.
  • The tenderer will provide sufficient supporting documentation to enable Peninsula Health to satisfy itself as to the financial, technical, planning and other resource capability of the Tenderer to successfully undertake the service.

2.4 Contract Period

The contract will be for a period of 5 years from the commencement date, with the option to extend the contract on an annual basis for a further 5 years.

2.4Service conditions

3.1Code of Behaviour

The successful tenderer shall vouch for the fidelity of their employees and shall hold Peninsula Health indemnified against any loss occasioned by the health service due to any illegal act by the successful tenderer’s employees and the health service shall have the right to withhold payment to the Contractor for the purpose of making good any loss sustained by the health service.

3.2 Workcover

  • The successful tenderer as Contractor shall be insured and be covered during the period of the contract to the full extent against liability to his employees employed in the performance of the contract, under the laws enforced in the State in which the contract is being performed relating to Workcover and shall waive all rights of subrogation and indemnity against the health service and its officers, servants and agents given by such law to the Contractor (and the Contractor shall ensure that its insurer likewise waives its rights) in respect of claims by employees of the Contractor for injury (including injury resulting in death) arising from work performed under the Contractor
  • The Contractor shall be solely responsible to meet all payments, costs and expenses arising out of any claims and proceedings for damage, loss, death or injury or of to the Contractor and the Contractor’s officers, employees, agents, sub-contractors, invitees and licensees which may be sustained in the performance or work pursuant to the contract and the Contractor shall indemnify Peninsula Health, its employees and agents against any claims and proceedings made in respect of damage, loss, death or injury.
  • The Contractor shall on demand produce to the Chief Executive Officer of Peninsula Health for inspection, the cover notes, policies and premium receipts in proof of the existence of such insurance.

3.2Invoices

The service provider will provide the agreed invoices to Peninsula Health promptly.

3.3 Management of the Contract

Peninsula Health’s Manager, Health Information Services is the principal point of contact and liaison for the contract.

3.4 Terms and Conditions

  • Venders must comply with the terms and conditions as specified on our website. Any additional costs such as delivery costs, administration fees, handling fees, minimum order costs, etc. Will not be excepted unless specific written permission has been granted.

14.Statement of Requirements

Tenders must address all of the following points as part of their tender response as described in the Part C documents and include the following.

4.1Key Functional Requirements

Key Functional Requirements / Comments
Currently operational within a health environment
Ability to support the system with an office/support staff based in Australia
4.1.1 / General
  • Access scanned record 24/7/365

4.1.2 / Interfacing
Interface with the Patient Administration System (iPM). The following fields are required for demographic information:
  • UR Number
  • Surname
  • Given Name
  • Date of Birth
  • Death flag
The following fields are required for inpatient event information:
  • Event identifier
  • Admission Date
  • Discharge Date
  • Treating Doctor and Unit
  • Ward
  • DRG (see 7.1)
The following fields are required for outpatient event information:
  • Event identifier
  • Clinician
  • Clinic Name
  • Appointment Date
  • Appointment Time
  • Attendance status
The following fields are required for ED event information:
  • Event identifier
  • Arrival Date
  • Arrival Time
  • Departure Date
  • Departure Time
  • Attending Doctor
The following fields are required for theatre event information:
  • Theatre date
  • Theatre time
  • Surgeon name
  • Anaesthetist name

4.1.3 / Scan Documents
Accurately recognise different inks, including:
  • Red pens
  • Permanent markers
  • Highlighters
  • Felt pens

4.1.4 / Quality Control (before scanned document(s) is written to record)
The system must have some built in quality control mechanisms and be able to the check orientation and filing of all pages is correct, identify any blank pages and flag any discrepancies
Ability to merge patient records upon receipt of HL7 ‘patient merge’ message from PAS
4.1.5 / Searching for a patient
Search by variable or combination of variables:
  • UR Number
  • Surname (including soundex and partial searches)
  • Given name
  • Gender
  • DOB (including partial searches, e.g. by year)
  • Form name

4.1.6 / Patient record
Display demographic bar on every screen that contains patient information:
  • UR Number
  • Surname
  • Given Name(s)
  • Gender
  • DOB
  • Death flag

Ability to record access restrictions to record and reason ie. Patient request
Allow a single record to be viewed by multiple users simultaneously
4.1.7 / Information Dissemination
Print selected (single or multiple) documents by an authorised user
The system enables an operator to bundle parts of a record or some forms together into a pdf file to send to an approved user who has requested the information
Burn to CD selected documents by authorised user
4.1.8 / Security
Individual logon required to access system
Ability to limit access and function by user and user group permissions
Ability to restrict access at certain levels such as:
  • Patient
  • Service type/folder
  • Event
  • Document
The file tree should be displayed but access blocked at document level.
Sessions can be automatically closed after a period of inactivity
Prohibit saving of the image by the user (read only)
4.1.9 / Interface Mapping
Map the fields between the scanning system and interfaced systems
4.1.10 / Audit Trails
Record date & times of user session in the system
Record the following details within the audit trail:
  • Time / date stamp
  • User ID
  • Document / File ID
  • Action

4.1.11 / Legislative compliance
The Victorian Evidence Act 1958 currently decrees an original document as best evidence. A copy that can be proven to be a true copy without opportunity for tampering may be admissible, in the absence of the original. The Vendor must describe System ability to provide evidence of 100% document to image integrity.
The Public Record Act 1973 obligates the creation and retention of medical records in accordance with the PROS 99/04 Retention & Disposal Authority (RDA). At this time destruction of scanned paper records is not permitted in Victoria but Vendors should detail system ability to comply with the RDA including:
  • Tenderers must ensure that the system complies with the minimum retention periods detailed within Part 3 of the PROS 99/04 General Disposal Schedule for Public Health Services Patient Information Records.
  • The system can automatically schedule different minimum periods of retention for scanned records depending on the nature of the information being stored ie emergency records stored for 7 years, inpatient attendance 15 years from date of last attendance.
  • The due for destruction date is displayed within the system.
  • Scanned records can only be deleted in accordance with the rules outlined in the above schedule.
  • A register of all records destroyed or deleted by the system must be maintained.
  • A report of records due for destruction can be produced from the system.
  • The system can destroy/delete records as a bulk transaction.
  • The destruction date, time and reason for destruction is displayed within the system for all records destroyed/deleted.
  • Automatic reassignment of retention period as events are superseded
  • Ability to transfer expired records to another storage medium or level

The Health Records Act 2001 legislates for the integrity, security and protection of medical records. The System must comply with the HRA by means of robust document to image integrity, access and change security mechanisms and audit logs. Vendors should provide detail on system security, quality control and non repudiation processes to illustrate 100% document to image integrity.
The Victorian Public Records Office Victorian Electronic Records Strategy (VERS)has been developed to preserve the electronic records for the long term. Tenderers must state their system compliance with version 2 of the VERS Standard. If currently not compliant, tenderers must indicate an intention to achieve compliance in the future.
The following criteria is essential ; tenderers must ensure that their system complies with all aspects of the Electronic Transactions (Victoria) Act 2000.
  • Where an entry in the system is required to be logged against a user, the requirements for electronic signatures as detailed within Section 9 of the Act must be met:
- “ …a method is used to identify the person…”
- “… the method was as reliable as was appropriate for the purposes for which the information was communicated…”
  • If required to produce a document under law the requirements for production as detailed within Section 10 of the Act must be met:
-“…the method of generating the electronic form of the document provided a reliable means of assuring the maintenance of the integrity of the information contained within the document…”
-“ .. the integrity of the information contained in a document is maintained only if the information has remained complete and unaltered, apart from – the addition of any endorsement; or any immaterial change ….”
  • As described within Section 11 (c) all transactions within the system must contain sufficient detail to enable identification of the following;
-“the origin of the electronic communication”
the time and date of the transaction

4.2Functional Requirements

Functional Requirements / Comments
4.2.1 / General
Access scanned record;
  • 24/7/365

Access scanned record from any terminal on the network
Access scanned record remotely
Access scanned patient record (to individual document level) by multiple users simultaneously
Process from scanning to saving in the system must be automated and integrated ie. minimal or no intervention by operator unless fails quality control processes
The system must be simple to navigate, user friendly, intuitive and require minimal training
Presentation of data to user must be such that user workflow is not impeded ie. minimum number of mouse clicks and immediate response time.
The system must be able to present a complete patient record to the clinician in one view i.e. eliminate the need to log on to different systems to obtain different pieces of information
The user interface can be customised for each site within the Health Service
The user must be able to easily navigate the system using minimum keystrokes and mouse clicks.
Provide a core menu that is accessible from any screen
Provide online help functionality
Change the colour of hyperlinks once they have been selected (for the duration of a logged in session)
Provide alert functionality with site defined categories and discrete icons to denote categories. Describe if this functionality is provided within the System or interfaced from PAS.
Index non-clinical documents (e.g. HR, finance) using site defined indexing framework.
Ability to support on site and off site scanning models (partnered with commercial scanning facility). Provide information on system configuration, costs and partnership arrangements
4.2.2 / Interfacing
Interface,via HL7 V2.4, with the Patient Administration System (iPM). The following fields are required for demographic information:
  • UR Number
  • Surname
  • Given Name
  • Date of Birth
  • Death flag
The following fields are required for inpatient event information:
  • Event identifier
  • Admission Date
  • Discharge Date
  • Treating Doctor and Unit
  • Ward
  • DRG (see 7.1)
The following fields are required for outpatient event information:
  • Event identifier
  • Clinician
  • Clinic Name
  • Appointment Date
  • Appointment Time
  • Attendance status
The following fields are required for ED event information:
  • Event identifier
  • Arrival Date
  • Arrival Time
  • Departure Date
  • Departure Time
  • Attending Doctor
The following fields are required for theatre event information:
  • Theatre date
  • Theatre time
  • Surgeon name
  • Anaethetist name

Retrieve Alerts information from PAS (iPM) and clinical system
Retrieve Medical Record Setup from PAS (iPM) for cross referencing of existing paper records
Interface via HL7 V2.4with other PH feeder systems:
  • Kestral/PACS (Radiology)
  • Ultra (Pathology – Dorovitch)
  • Oracle (Finance)
  • BOS (Birthing Outcome System)
  • Emdat (Dictation)
  • iPharmacy
  • Clinical Information System (Orion/Cerner)
  • PJB
  • SWITCH
  • Cboard
  • Winchart (theatre)
  • EDIS

Seamless interface with Clinical Information System (currently Orion)
Scanned records should be able to be merged, either by an operator, or on receipt of an HL7 “patient merge” message being received from PAS
The system must be able to add value to the current systems of viewing results by automatically filing electronic results in the relevant patient folder.
4.2.3 / Input
Scan documents
Read form identifying barcodes. Link to indexing metadata specific to form type.
Scans will be captured at a suitable resolution and colour depth to enable full colour images to be displayed onscreen, with no apparent loss of detail.
The system will keep a register of page/document types, sorted by barcode number
The system should detect page orientation (eg based on the orientation of the patient UR label barcode)
The system must only allow a user who has the required security privileges and is logged on to the system to add scanned pages to a record.
The system must be capable of scanning an entire patient medical record as a single batch,
The system must be capable of automatically identifying and coding/indexing each document that constitutes the medical record, based on a “document type” barcode located in a standard position on each page.
The system will automatically index all documents types, patient numbers, date/time stamps and store this information against each page.
Where a form is not barcoded, the system can recognise the form via another method as defined by the tenderer e.g. key word, tick box
For each document scanned, capture metadata regarding the creation and/or modification of the image ie. Date, time, UR, form type, file format, operator etc.
Automatically and accurately index documents using barcoded data (form identifier, UR, episode) and metadata specific to form type
Index scanned documents that are not pre-barcoded (e.g. barcoded through the use of a header sheet or barcode book)
Manually index document
Scan A4 sized documents
Scan non-A4 sized documents (A3 & A5 etc.) at significant speeds
Scan multi-page documents eg. Medication charts, ED charts, ICU charts
Scan double sided documents (duplex)
Scan colour documents including photographs
Accurately recognise different inks, including:
  • Red pens
  • Permanent markers
  • Highlighters
  • Felt pens

Ability to scan multiple documents from different events and patients in one batch.
Ability to support input from multiple scanners or uploads simultaneously
Documents must be scanned at an appropriate resolution to achieve clarity of image. Provide detail on image resolution and impact on file storage.
Ability to bulk scan old (non barcoded) records with minimal or manual indexing
Display a preview of the scanned image(s) before being saved
It must be possible for an operator to add incrementally to any record at any time
Upload files
Accept a variety of file types eg.
  • Image
  • Movie
  • Audio
  • MS Word documents

For each document uploaded, capture metadata regarding the creation and/or modification of the image ie. Date, time, file format, etc.
Manually index files
Automatically and accurately index uploaded files - provide detail on how this can be achieved