Peninsula Health: Linen Tender

RFT Part C: Tenderer’s Response

RFT Part C – Tenderer’s Response

Peninsula Health

Scanned Medical Records Tender

RFT Part C – Tenderer’s Response

Contents / Page
Tender Document Details / 2
  1. Tenderer’s Information
/ 3
  1. Executive Summary
/ 3
  1. Compliance with the Specification
/ 4
  1. Alternative Tender
/ 64
  1. Confidentiality Statement
/ 64
  1. Service Delivery
/ 64
  1. Financial Viability
/ 66
  1. Conflict of Interest
/ 68
  1. Ethical Purchasing Policy
/ 69
  1. Any Other Matters
/ 69
  1. Disclosure of Contract Information
/ 69
Attachment A: Contract Disclosure / 70
Attachment B: Deed of Confidentiality / 71

Tender Document Details

(a)Tenderers must provide an electronic copy of the Tenderer’s Response in submitted in accordance with the Conditions of Tender.
(b)All responses must be provided within the specified red highlighted areasand must respond to the Specification (Part B) in accordance with the Conditions of Tendering (Part A).
(c)Do not include graphics or data in responses. Where necessary, any graphics or data should be placed at the end of the documents and referred to in the response.
(d)Include the name of the Tenderer in the footer of the Tender.
(e)All documents must be virus checked by the Tenderer before lodgement.

Page 1 of 73

Peninsula Health: Linen Tender

RFT Part C: Tenderer’s Response

1. Tenderer’s Information

Request for Tender for Medical Scanned Records
I accept the provisions contained in the Conditions of Tendering (Part A)
Name of Tenderer and address of registered office:
Place of registration:
Australian Company Number:
Australian Business Number:
Principal office in Victoria (if any):
Telephone:
Facsimile:
Email:
Name and title of Tenderer’s authorised agent:
Date:

Under Part C of this RFT a Tenderer must submit their responseshowingits level of compliance with the Specification contained in Part B of this RFT.

2. Executive summary

Provide a brief executive summary providing an overview of the Tender.

3. Compliance with the Specification

This section allows the Tenderer to show their level of compliance with RFT Part B Specification.

Please detail your response under each of the required criteria using the “Details” column. Elaborate on how your system meets/does not meet the specification requirements for this section. Explain the key benefits and selling points of your system. The nature & extent of any non-compliance must also be clearly stated.

Page 1 of 73

Peninsula Health: Linen Tender

RFT Part C: Tenderer’s Response

Key Functional Requirements / Details
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
Functional Requirements / Details
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
Provide version control to maintain and monitor superseded files that have been uploaded – provide detail on how this can be achieved
Accept bulk upload of images/files from outsourced scanning facility. Vendor must describe system configuration, metadata translation and quality controls in the context of an outsourced (off site) scanning operation.
Direct Data Entry (e-form)
Ability to direct enter data onto e-forms for storage within the system. Please provide detail including:
  • Description of functionality
  • If format and content is site defined
  • Any limitations
  • Ability to spell check content
  • Ability to edit/modify
  • Audit of edit/modification
  • Version control
  • Ability to support voice recognition software

4.2.4 / Quality Control (before scanned document(s) is written to record)
The system has a quality control process that is easy to use. That is, the presentation to the user enables easy navigation through a quality control process eg using icons.
The system must have a documented QA process for batch scanning
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
The system must support a process which allows a single user to undertake any required quality control process within a reasonable timeframe
View all digitised images as documents are scanned
System must automatically recognise where images are not correctly formatted ie. upside down, not straight, dog earred etc. These images must be highlighted or redirected for manual view and correct by operator.
Ability for operator to correct or improve image – rotate, enlarge, straighten, darken, lighten etc.
Each form identifying barcode must link to metadata containing the business rules for that particular form. The System must automatically apply these rules to the form. The System must recognise where the form does not conform to the rules and highlight or redirect for manual review and correct by operator.
Enable deletion of a single scanned document or uploaded file by authorised user
Enable deletion of multiple scanned documents or uploaded files by authorised users (i.e. selecting a number of images at once and deleting them simultaneously)
Provide a “trash bin” that contains documents that have recently been deleted. All files that are deleted are moved to this bin. Retention time (up to permanent) is site defined
Manually re-index a single scanned document or uploaded file (This may include moving images/files between different records)
Manually re-index multiple scanned documents or uploaded files
Provide a search functionality to assist in finding “lost” documents, i.e. documents that are missing an index element
Ability to merge patient records manually and upon receipt of HL7 ‘patient merge’ message from PAS
4.2.5 / Output
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

Ability to search and list by selected variables:
  • Unit/program
  • Ward
  • Attending doctor or Healthcare Provider (HCP)
  • Clinic
  • All current ED patients