RFT Part D – Tenderer’s Response · Web viewPeninsula Health. Scanned Medical Records Tender....

Peninsula Health: Scanned Medical Records TenderRFT Part C: Tenderer’s ResponseFeb 2010

RFT Part C – Tenderer’s Response

Peninsula Health

Scanned Medical Records Tender

RFT Part C – Tenderer’s Response

Contents PageTender Document Details 2

1. Tenderer’s Information 3

of 73

Peninsula Health: Linen TenderRFT Part C: Tenderer’s Response

2. Executive Summary 3

3. Compliance with the Specification 4

4. Alternative Tender 64

5. Confidentiality Statement 64

6. Service Delivery 64

7. Financial Viability 66

8. Conflict of Interest 68

9. Ethical Purchasing Policy 69

10. Any Other Matters 69

11. 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 areas and 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.

of 73


1. Tenderer’s Information

Request for Tender for Medical Scanned RecordsI 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:

2. Executive summary

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

of 73


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.

of 73


Key Functional Requirements DetailsCurrently 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 InterfacingInterface with the Patient Administration System (iPM). The following fields are required for demographic information:

UR Number Surname Given Name Date of Birth Death flagThe 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

of 73


Key Functional Requirements Details Appointment Time Attendance statusThe 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

of 73


Key Functional Requirements Detailsmerge’ 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

of 73


Key Functional Requirements Details4.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

of 73


Key Functional Requirements DetailsRecord 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

of 73


Key Functional Requirements Detailsfrom 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%

of 73


Key Functional Requirements Detailsdocument 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 ….”

of 73


Key Functional Requirements Details

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

of 73


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.

of 73



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 flagThe following fields are required for inpatient event information:

Event identifier Admission Date

of 73



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 statusThe 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

of 73



Retrieve Medical Record Setup from PAS (iPM) for cross referencing of existing paper records

Interface via HL7 V2.4 with 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

of 73



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

of 73



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

of 73



Felt pensAbility 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

of 73



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

of 73



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)

of 73



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

of 73



Ability to search and list by selected variables:

Unit/program

Ward

Attending doctor or Healthcare Provider (HCP)

Clinic

All current ED patients

Hyperlink the search results to the patient record

Patient record

Display demographic bar on every screen that contains patient information:

UR Number Surname Given Name(s) Gender DOB Death flag

Display on demographic bar or in prominent position, patient alert icon(s) or information.

Display identifiers to indicate paper records that currently exist for the patient (see 2.4)

Ability to record access restrictions to record and reason ie. Patient request

of 73



Display a list of events – inpatient, outpatient, emergency, theatre, clinics etc.

Ability to sort the list of events by:

Event ID Arrival Date Separation Date (default, with the most recent at the top) Ward Unit Clinic Type Treating Doctor or HCP Event type (inpatient, outpatient, ED attendance)

Ability to sort by document type ie. list/display all anaesthetic charts (default reverse chronological order)

Display a list of documents / files within each event

Enable the list of documents / files to be expanded

Enable the list of documents / files to be collapsed

Ability to have the dividers in the paper record (This should be site defined). For example:

Emergency Outpatients Correspondence Community Dialysis Chemotherapy Inpatient episodes

of 73



Allow for documents to be stored under a temporary divider (e.g. Current Pregnancy). Divider shall have an editable end date upon which a report can be run to identify expired temporary dividers. System should then allow reassignment of single or multiple documents to other dividers and episodes.

Display individual documents / files with site definable file name. Ability to access form metadata from file name ie. right click

Multipage documents eg. progress notes, should be stored as a single file with ability to arrow/scroll through or page through. This should be the default but with option for operator to scan and index as individual documents.

Ability to view multiple documents from a single record simultaneously

Allow multiple patient records to be viewed on a single terminal simultaneously

Allow a single record to be viewed by multiple users simultaneously

Scanned images – view & navigation

Automatically resize the scanned image to fit the frame

Enable the user to zoom in / out the scanned image using the mouse scroll button

Ability to automatically resize image to fit frame post zoom

Enable the user to scroll up / down the scanned image (when zoomed in)

Enable the user to scroll left / right the scanned image (when

of 73



zoomed in)

Enable the user to rotate the scanned image

Enable the user to move forwards / backwards through documents that have multiple pages:

Move directly to the first page Move directly to the last page Scroll/arrow through pages Move directly to a specific page

Enable the user to place bookmarks on selected documents. Upon exit from the record book marks are not retained (user defined only)

Display the scanned image and the document tree in separate frames.

Uploaded files – view & navigation

Open uploaded files within the record

Enable playback of movie and sound files within the record

Play Stop Pause Move directly to beginning of movie Move directly to end of movie Fast forward Rewind

User profiles should allow a default sort order to be specified for each user or groups of users

of 73



A default view for users should allow ward-, clinic- or unit -based users to be shown patients currently under their care, or on their clinic list, or currently are inpatients.

Enable navigation of uploaded documents as per scanned documents above (see 5.3)

It is desirable that the system can add value to the existing methods of viewing records. For example it is highly desirable for the system to be able to generate views on atomic data such as cumulative view of selected tests

Direct Data Entry – view

Open forms that have been populated with data that has been directly entered into the system

Display of populated e-form shall be site defined

4.2.6 Information Dissemination

Print selected (single or multiple) documents by an authorised user

Auto Fax selected documents by an authorised user using GP database and HL7 messaging

Convert selected images to PDF. State how/where PDF files are stored within the system once created. Records should be exportable to a common format (preferably Adobe Acrobat PDF), with the user able to specify the range and/or nature of pages exported.

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

of 73



Burn to CD entire patient record by authorised user

4.2.7 Clinical Coding Worklists

Provide a coding worklist for users within the relevant user group based on absence of a DRG (see 7.1) within inpatient event data. Display:

UR Surname Given Name(s) DOB Discharge Unit Discharge Ward Attending Doctor Admission Date Discharge Date LOS (sameday = 0)

Sort patients based on user defined criteria:

UR Surname Unit Ward Attending Doctor Discharge Date Length of stay (LOS)

Filter patients based on:

Unit Discharge Date Attending Doctor Ward Length of stay (LOS)

of 73



Hyperlink the worklist entry to the patient record

Provide a link back to the worklist from the patient record

Refresh the coding worklist to reflect coded separations

4.2.8 Clinical Worklists

Display all inpatients that have been admitted under the user currently logged into the system (user profiles to include unit, ward, clinic types, ED etc.) ie. ability to customise “my lists”

Display current non admitted events (ED, Outpatients) under the user currently logged into the system

Ability to search by selected variables:

Unit

Ward

Attending doctor or HCP

Clinic

All current ED patients

of 73



Provide a clinical worklist for users within the relevant user group(s):

UR Surname Given Name(s) DOB Unit Ward Admission Date Discharge DateHyperlink the worklist entry to the patient record

Provide a link back to the worklist from the patient record

4.2.9 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.

The system can provide a high level of security for high risk or high profile patients (or staff) including restrictions to display specified information.

Locked sessions can be automatically closed after a period of

of 73



inactivity

The system can record the date and time a user was established in the system

The system can allow date or time limitations to user access; suspension of user access for defined periods; or editing of user access.

User defined time out of system

Prohibit saving of the image by the user (read only)

4.2.10 System Administration

Interface Mapping

Map the fields between the scanning system and interfaced systems

Audit Trails

Record date & times of user session in the system

Log every action that is performed on every document / file within the system such as:

Scanned Viewed Re-indexed QA Print Direct data entry/edit

of 73



Record the following details within the audit trail:

Time / date stamp User ID Document / File ID Action

Search audit trail by user ID

Search audit trail by event ID

Search audit trail by document ID

Search audit trail by a combination of the above options

Filter audit trail results by a specified timeframe

Display audit trail results with the following details:

Time / date stamp User ID Event ID Document / File ID Action

User Maintenance

of 73



Create a user:

User ID Password Surname Given Name(s) Role User Group Start Date End date Clinical profile

Modify user details

Permanently retain audit trail of user modifications

Permanently retain inactive user details

User Group Maintenance

Create user groups

Set user group permissions:

Reports System Administration Information Dissemination Scanning Quality Assurance Re-indexing Direct Data Entry Adding Alerts Printing Viewing (Viewing Authority) Viewing levels

of 73



Enter/edit on e-formsAbility to define default view/sort order by user and user group

Modify user group permissions

Delete user groups that do not have any users assigned to them

Index Maintenance

Create divider categories

Create form categories

Maintain divider categories

Maintain form categories

Define index hierarchy (including where each form belongs in the hierarchy)

Barcode / Form Maintenance

Create form identifier

MR number Form name Location in document hierarchy

Enter and maintain metadata (business & indexing rules) pertaining to the form identifier

Maintain form identifiers

Enter non-MR form (i.e. correspondence) identifiers into the system

Form name Location in document hierarchy

of 73



Map barcodes to form identifiers

Print header sheets for non pre-barcoded forms where required

Print labels for non pre-barcoded forms where required

Print barcodes

4.2.11 Reporting

Ability to produce standard and ad hoc reports from the system without need for Vendor programming

The system administrators will be able to produce routine reports and ad hoc management reports as required.

A menu of the routine system generated reports is available, and includes a de-identified example of each report on the menu.

The system allows defined users to download relevant patient information and reports into another common exportable format eg. Adobe Acrobat pdf.

4.2.12 Audit trails

Ability to report on access variables:

Date/time range

User

User group

Document type

of 73



Action (view, print etc.)

Report output to include variables as above plus accessed record details including:

UR

Name

Event type

Documents/levels accessed

Ability to set up standard reports using parameters specified above

4.2.13 Quality control process

Ability to report activity log of scanning and QA processes by variables:

Date/time range

User

UR (complete history of creation of record)

Action ie. scan, upload, manual re-indexing

Report output to include variables as above plus record details including:

UR

Name

of 73



Document file name

Detail of action

Ability to report in printed form and export to other file type ie. Excel

4.2.14 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.

of 73



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.

of 73



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 ….”

of 73



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.2.15 Non clinical documents

Ability to scan, index and store non clinical documents ie. Executive Suite, Human Resources, Finance documents, Contracts. Please provide:

Description of functionality

How documents will be indexed

How documents will be viewed and navigated

How non clinical documents will be separated from clinical documents

If this functionality is currently available within product or intended and if the latter, proposed time of availability

4.2.16 Non mandatory/desirable functionality

View & endorse results

Ability to upload investigation results from pathology and radiology providers

Ability to sort/access results by a combination of variables:

date/date range

of 73



type of result

attending doctor

unit

Ability to display cumulative results

Ability to graph results

Accept ‘abnormal result’ flag from provider and display same

Notification of incoming (new) results to requesting doctor. Provide detail on how results are routed to relevant doctors involved in the patient’s care

Ability for authorised user/recipient of result to endorse/sign off result

Please provide details of view and endorse result functionality additional to above (if any).

Reporting – results view & endorse

of 73



Ability to report user access of results by variables:

Date/time range

User

UR


UR

Name

Document file name

Ability to report non endorsement of results by variables:

Date/time

Result type

Abnormal/normal


UR

Name

Result

of 73



Access audit trail

Ability to report in printed form and export to other file type ie. Excel

of 73


Technical requirement Details4.3.1 Network Infrastructure

It is intended that the system will operate across all Peninsula Health sites using the following infrastructure:

Wired

The system must be able to operate over a range of network capabilities, including 100 and 1000 Mbps. At a minimum the reasonable speed expected is no more than 1 second to display an image when a document or patient is selected.

Use of the system simultaneously by 10% of the registered users must be possible at a given point in time, without creating an impost on available network traffic such that other applications are impaired in operation.

Tenderers should provide any documentation on minimum network specifications as an attachment to the tender, and guarantee full function and speed of the system.

Wireless

Peninsula Health is currently using wireless networks within four of its campuses. PH’s expectation is that the network will operate at up to 55 Mbps but in some situations the speed could fall to as low as 2Mbps.

The system must perform at a reasonable speed at 2Mbps over wireless networks.

Wide Area Network

of 73


Technical requirement DetailsThe Peninsula Health campuses are connected via Telstra TCS GWIP network running at speeds ranging from 10Mbps to 50Mbps. The system must operate at high speed at all campuses, with a maximum response time of 1 second from selection to display of an image.

4.3.2 Desk top Infrastructure Standard Operating Environment & Client Operating Systems

The standard SOE for desktop PCs at Peninsula Health is Windows XP SP3.

Please indicate if these specifications are sufficient for your system. If not sufficient please supply your minimum specification.

The Peninsula Health SOE is a highly locked-down environment. Users do not have administrative access to their workstation.

Please confirm that this environment is supported.

The tenderer must undertake any developments necessary to enable full functionality of the system by a user running the Peninsula Health SOE at no additional cost.

Any software which is required to be installed on more than 30 workstations must be able to be silently deployed.

The web-based client must have minimal or no dependence on Active X or Java (offerer must provide details of any ActiveX or Java components)

of 73


Technical requirement DetailsFor web functionality, if an Active X control (or similar) must be installed, this must be digitally signed to enable easy installation by clients.

If an Active X or Java control must be installed this must be specified in the tenderer’s offer.

Patching of Client Operating Systems

The client workstations are updated with Microsoft operating system patches within one month of release for severe issues/vulnerability. The tenderer must certify full functionality of the System with all Microsoft patches no more than one month following the patch release.Microsoft service packs are installed within six months of release. The tenderer must certify full functionality of the System with all Microsoft patches no more than six months following the service pack release.New versions of Windows are generally installed within 12 months of release. The tenderer must certify full functionality of the System within 12 months of release.Web Client for PCs

The system must use a web client for all general viewing of the medical record throughout Peninsula Health.Web clients must operate using standard HTTP protocol, over port 80 or port 443 if secure sockets layer is used.The only support client for web functionality on desktop PCs is Internet Explorer, version 6.0 as a minimum. Web functionality of the system must perform with full functionality using this version. Web functionality must perform with full functionality using any higher version of Internet Explorer greater than 6.0 that is available at the time of tendering.

of 73


Technical requirement DetailsIndicate what other browser versions you support.Web functionality must perform with full functionality using any new version of Internet Explorer released subsequent to the implementation of the system, within two months of that version being released by Microsoft.State browser versions supported by the system.

Tablet PCs & Portable Devices

It is desirable that all aspects of system functionality be possible using the handwriting input functionality of a Tablet PC.It is desirable some aspects of system functionality i.e. viewing pathology results be possible using PDAs.Thin Client Support

Thin Clients running Windows XP embedded or Windows CE 3.0, 4.2 or 5 are being considered for use by Peninsula Health. Any web-based functionality must be possible using the built-in web browser on these clients.If Java or ActiveX controls are required for full functionality the tenderer must, on request, recompile or rewrite those controls to enable functionality under Windows CE or XP embedded.The tenderer must state any special requirements for scanning workstation PCs including monitor size and hardware requirements.Remote Access Environment

Peninsula Health has a remote access environment where clients from remote PCs access a Windows Terminal Server Session.

of 73


Technical requirement DetailsAny web-based functionality must be possible using the built-in web browser in this environment.Scanners

State the recommended scanner types and models.

Tenderers must provide details of scanning hardware that is compatible with their product that is readily able to be acquired by Peninsula Health.

Interfaces

Peninsula Health has currently using the SeeBeyond eGate product. In general communications between applications will be via HL7 messages using eGate.

All interfaces to systems described in this section must be included within the functionality and pricing of the system offered by the tenderer.

4.3.3 Patient Administration System

Peninsula Health uses iPM a single health service wide Patient and Client Management System (P&CMS).

The tenderer must commit to the development and implementation of a HL7 interface to P&CMS. Any development and testing work will be provided at a reasonable cost and the tenderer must state the expected cost in the tender submission.

State the recommended server operating systems.

It is mandatory that at “go-live” a HL7 interface is provided to enable all patient demographics, inpatient activity, outpatient attendance details and alert information to be imported from the PAS system into the

of 73


Technical requirement Detailsmedical record system.

The following HL7 version 2.4 messages and events have been identified as required, please indicate which of these messages are currently available in production systems:

A01 Admit/visit notification

A02 Transfer patient A03 Discharge/end visit

A04 Patient Registration

A08 Update Patient Information

A11 Cancel admit/visit notification

A12 Cancel transfer

A13 Cancel discharge/end visit

A17 Swap patients

A19 Patient Query

A19 Patient Query Response

A21 Patient leave

A22 Patient return from leave

A28 Add person information

A29 Delete person information

A31 Update person information

of 73


Technical requirement DetailsA40 Merge patient information

S12 Notification of new appointment booking

S13 Outpatient Rescheduled appointments

S14 Notification of appointment modification

S15 Notification of appointment cancellation

S16 Confirm outpatient completion

S26 Outpatient did not attend

What information derived from the PAS via the HL7 interface is stored or used by the system, and for what purpose.

Is the system able to integrate with an Enterprise Master Patient Index to link together multiple UR schemes from multiple PAS instances and/or interfaces.

State the PAS configurations that the proposed solution has been successfully integrated with, according to the HL7 interface above, in a production environment in Australia.

It is desirable that the system be able to accept a URL direct to an individual patient record to enable the scanned medical record system to be accessed and displayed without having to re-enter a UR number.

The tenderer should detail this interface cost if additional development is required.

4.3.4 Active Directory/LDAP

of 73


Technical requirement DetailsTo reduce the impost of user management the system must authenticate users using credentials and particulars stored in an LDAP directory (such as Active Directory) managed by the health service.

It is mandatory for the system to use group membership in the LDAP directory to determine a users access rights, resources or roles.

Users must be authenticated using the phcn.vic.gov.au domain based on; entry of a current valid username and password and membership of an Active Directory group that grants access to the system.

It is mandatory for the system to use the Active Directory to allow a user to log in.

It is highly desirable for the system to use group membership in the Active Directory to dictate access rights, resources or roles.

It is optional for the system to require no user maintenance within the system itself, using only Active Directory to govern user access and privileges.

Note that the system being tendered can use LDAP or another secure Active Directory compatible means of authenticating users in the manner prescribed above.

4.3.5 Electronic Documents

It is mandatory that at “go-live” clinical documentation ie outpatient correspondence, digital photos, wave files can be imported, stored and displayed within the system.

Pathology – Ultra

of 73


Technical requirement DetailsThe Peninsula Health Pathology Service is currently contracted to Dorevitch who use the laboratory system Ultra. The CIS is currently used within Peninsula Health to electronically view all laboratory results. It is desirable that at “go-live”, a HL7 interface is provided to enable all laboratory results to be directly imported from the Ultra system and displayed within the system as an electronic document.

This interface must include all electronically transmitted details from the laboratory report including reference values.

It is desirable that the system allow for the on-the-fly graphing and trending options.

It is mandatory that the system present results in a cumulative view.

The tenderer should detail the costs of the HL7 feed from the Ultra system as an additional item when submitting tender offers.

If the above interface is unavailable at “go live” it is desirable that the system can call the CIS results view for the patient selected i.e. the UR number from the patient selected within the medical record system would be electronically passed to the CIS without the need for the user to separately log into the CIS and enter the UR number. The tenderer should detail the costs of this option separately.

Radiology – Kestral

The Peninsula Health Radiology Service use the radiology

of 73


Technical requirement Detailssystem Kestral. This is in the process of being upgraded to Karisma. The CIS is currently used within Peninsula Health to electronically view all laboratory results. It is desirable that at “go-live”, a HL7 interface is provided to enable all laboratory results to be directly imported from the Kestral/Karisma system and displayed within the system as an electronic document.

This interface must include all electronically transmitted details from the laboratory report.

The tenderer should detail the costs of the HL7 feed from the Kestral system as an additional item when submitting tender offers.

If the above interface is unavailable at “go live” it is desirable that the system can call the CIS results view for the patient selected ie the UR number from the patient selected within the medical record system would be electronic passed to the CIS without the need for the user to separately log into the CIS and enter the UR number. The tenderer should detail the costs of this option separately.

Pharmacy – iPharmacy

Peninsula Health currently use the iPharmacy system for dispensing. It is desirable in the future to integrate the medication information such as the medication discharge summary, dose predication calculations, alert information and pharmacist patient notes from the iPharmacy system into the medical record system using HL7.

The tenderer should detail the costs of this interface as an additional cost.

of 73


Technical requirement DetailsEmergency Department Information System

Peninsula Health currently do not operate a third party EDIS, however this is currently under consideration. The Scanned Medical Record solution needs to be capable of linking to an EDIS in the future. Describe how this will be achieved.

It is desirable that the system be able to accept a URL direct to an individual patient record to enable the scanned medical record system to be accessed and displayed without having to re-enter a UR number. The tenderer should detail this interface cost if additional development is required.

If known the tenderer may optionally price this interface as an additional cost.

Clinical Information System

Peninsula Health is currently using the CIS for the electronic discharge summary. It is desirable in the future to integrate the electronic discharge summary and other clinical documents from the CIS into the medical record system.


PACS

Peninsula Health has implemented the PAC system through the HealthSMART project. It will be desirable to have the ability to store the URL of the image within the medical record system to enable direct access to the image.

of 73


Technical requirement DetailsIf known the tenderer may optionally price this interface as an additional cost.

ECG System

Peninsula Health is currently implementing the Phillips ECG management system. It is desirable to have the ability to store the URL of the ECG record within the medical record system to enable direct access to the image.If known the tenderer should price this interface as an additional cost.Medical Director & Pracsoft

Peninsula Health is currently investigating the implementation of Medical Director as one of the systems to support the Super Clinic. It will be desirable in the future to have the ability to integrate some information/results stored on Medical Director in to the medical record system.The tenderer should detail the costs of this interface as an additional costBirthing Outcomes System - BOS

Peninsula Health is currently using BOS for the birthing outcomes. It is desirable in the future to integrate the birthing outcome information and other clinical documents from BOS into the medical record system.


PJB

Peninsula Health is currently using PJB for the subacute outpatient services, assessments and referrals. It is

of 73


Technical requirement Detailsdesirable in the future to integrate the information from PJB into the medical record system.


Switch

Peninsula Health is currently using Switch for Community Health. It is desirable in the future to integrate the information from Switch into the medical record system


Exact

Peninsula Health is currently using Exact for Dental Health. It is desirable in the future to integrate the information from Exact into the medical record system.


Emdat – Transcription System

Peninsula Health is currently using Emdat for transcription of Outpatient letters, Operation reports and other correspondence. It is desirable in the future to integrate the information from Emdat into the medical record system.


4.3.6 Server Infrastructure

Operating System and Environment

of 73


Technical requirement DetailsPeninsula Health current standard Operating System environment is Windows Server 2003 SP2. Dell is our preferred provider of servers.

Please state if your system supports this environment.

Other Operating Systems are allowed; if they are to be employed this must be stated by the tenderer.

Microsoft Forefront v:1.0.1703.0 server and v:1.5.1973.0 client is the Antivirus product used within Peninsula Health. Any exceptions to its utilisation on all servers for the system must be stated.

Tape backup is generally performed using Backup Exec V12.5. Any exceptions to its utilisation on all servers for the system must be stated.

Remote server management is generally performed using Windows Terminal Services (Remote Desktop). Any exceptions to its utilisation on all servers for the System must be stated.

Patching of Server Operating Systems

Peninsula Health servers are updated within Microsoft Operating System patches within one month of release if the patch is for a severe issue/vulnerability. The tenderer must certify full system functionality no more than one month after the release of these patches.

Peninsula Health servers are updated within Microsoft Service packs within 6 months of release. The tenderer must certify full system functionality no more than six months after release of these service packs.

Primary Server

of 73


Technical requirement DetailsState the recommended server hardware configuration for your proposed solution.

Secondary Server

The secondary server will be of the same specification as the primary server and may be located remotely.

The tenderer should state if this remote configuration is supported.

Storage

State recommended storage infrastructure required to implement the solution.

The system must be capable of using the full capacity of this array for all record storage, with full backup capability.

The tenderer should state if the above storage configuration is sufficient to store medical record data for a minimum of 3 years.

Backup

A full tape backup will be performed on a weekly basis. Differential backups will be performed daily. Tapes are stored remotely when not in use.

The tenderer should state whether the system supports this backup schedule.

A tape backup will not be performed on the secondary server. However, if the servers are not operating in a redundant manner, tape backup will be installed as per the primary server. The system running on the secondary server must in that instance be capable of

of 73


Technical requirement Detailsoperating backup as per the specification for the primary server.

Database Server Environment

The database environment that resides on the server must be a recognised or standard system.

The Peninsula Health preferred standard for large database applications is Microsoft SQL. Other database environments may be used.

The tenderer must state if this is not the preferred database environment.

The tenderer must state server or client licence requirements.

It is preferable to include an ODBC-compliant connection to the system database, to allow other systems to query the data in the system as needed.

The proposed solution should not require any additional proprietary databases or software licenses.

The scanned medical record system is required to be in full operation 24 hours a day, 7 days a week.

The system must operate with some level of real-time back-up and redundancy, using two servers. Tenderers should state recommended deployment topologies.

The Tenderers should state if the applications will run under a VMware VSphere 4.0 virtual environment and indicate resource requirements.

4.3.7 Health service Operations and User management

of 73


Technical requirement DetailsReference Files

Where possible reference lists i.e. ward table, doctor lists, are to be stored in single tables for all campuses.Internal Users

Users must be interfaced to the Peninsula Health Active Directory using their phcn.vic.gov.au accounts.It is desirable that the system must record against each user the campus from which the user primarily works. However, all users should be able to work from multiple campuses.

External Users

It is desirable that read-only access to the system be provided to nominated General Practitioners or medical specialists.Quality Control and Document Management

All retrieval / access of the record must be possible using web-based client

The web-based client must have minimal or no dependence on Active X or Java (offerer must provide details of any ActiveX or Java components)

All records captured from other electronic systems (eg Pathology – and all those specified in Part A &B of this document in Section 3 Interfaces) must be viewed in-line with scanned pages, with little discernable difference in functionality

It is desirable for users to add documents from recognised standard formats, eg Microsoft Word, and file them against a patient record

of 73


Technical requirement DetailsIt is mandatory for records to be stored in a common, non-proprietary format such as JPEG, TIFF etc.The system should be able to load/display documents of any MIME typeThe system has the ability for a user to be able to view / access both the scanned document as well as the 3M CodefinderThe system will have longevity and be able to easily migrate data from existing versions to new versions developed.User interface / “User Friendliness”

The user interface will meet generally accepted standards for accessibility of web pages.The web-based system will be customisable to include hyperlinks to and from other systems, at the Health Service’s discretion.

of 73


Capabilities/Capacity Details4.4.1 Support

Support will be available via a telephone help desk between 8.30 am and 5.00pm Eastern Standard time, on all weekdays excluding public holidays.

Please quote a price for providing support 24 x 7 x 365 days

The Tenderer will be on site during the installation of the system, and remain on site until the installation is successful.

The Tenderer will preferably remain on site, (or be able to be on site within one hour), for a defined period (at least 2 weeks) after the installation and implementation, to ensure the successful installation, customisation and implementation of the system.

4.4.2 Implementation

Tenderers should indicate their preferred approach to implementation of the system and provide details of the proposed implementation strategy.

This strategy should include indicative dates from contract completion and identify milestones in the project. The allocation of resources to each phase of the project should also be provided.

4.4.3 Training

Tenderers should detail the system training that will be provided (including provision of user guides and training manuals) to Peninsula Health. This training will cover all facets of the system including

of 73


Capabilities/Capacity Detailsfunctional modules, technical training, system administration, reporting, and specific hardware training (eg hand held devices).

Details of training to be finalised as part of the Contract

Where workshops or planning days are required, please specify the time frames in which these need to occur.

of 73


4. Alternative Tender

Where a Tenderer submits an offer which meets Peninsula Health’s specific requirements in an alternative and practical manner taking into account the totality of the requirement, it shall include any supplementary material, together with associated prices, which demonstrates in detail that such an alternative will fully achieve and/or exceed all the specified outputs, functionality, and requirements together with references as to why the additional features may be advantageous. The details should be cross referenced to the appropriate reference in ‘Compliance with Specification Table’ above

Word limit: half a page

5. Confidentiality Statement

Tenderers are to execute a deed of confidentiality and undertake to keep contents of the RFT and other such information supplied confidential.

Please enter response in the box below (response required: understood and agreed). Please attach a signed deed of confidentiality (contained in Attachment B) to this document.

6. Service Delivery

Provide details of the proposed planning arrangements and reporting mechanisms to be implemented in the provision of the Services, in particular meeting deadlines.

Word limit – 250 words

ReferencesProvide three referees that Peninsula Health could contact regarding your ability to provide to the Services required under the Specification. Referees must be from a health organisation.

Note: Peninsula Health reserves the right to contact any of the Tenderer’s previous customers.

of 73


REFERENCE 1:

Client and contract details:

Description of service:

Period:

REFERENCE 2:



Period:

REFERENCE 3:



Period:

of 73


7. Financial viability

Tenderers are required to demonstrate that they have the financial capacity to provide, over the term of the contract, all the requirements specified in this RFT. Accordingly, you are required to provide the following information.

Please provide a ‘yes’, ‘no’ or ‘partial’ in the space provided below. If the answer to any of the following questions is ‘yes’ or ‘partial’, please provide an explanation.

(f) Are there any significant events, matters or circumstances which have arisen since the end of the last financial year which may significantly affect the operations of the Tenderer?

(g) Are there any mergers/acquisitions either recent (within the past 12 months) or which are imminent?

(h) Are there any proceedings, either actual or threatened, against the Tenderer, its parent or associated entities or any director of the Tenderer, its parent or associated entities or have there been any such proceedings within the past five years? If so, what (if any) remedial action has been taken in respect of such proceedings?

(i) Are there any bankruptcy actions against a director of the Tenderer, its parent or associated entities, or has there been within the past five years?

(j) Are there any de-registration actions against the Tenderer, its parent or associated entities on foot, or have there been any within the past five years?

(k) Are there any insolvency proceedings, actual or threatened (including voluntary administration, application to wind up, or other like action) against the Tenderer, its parent or associated entities on foot, or have there been any within the past five years?

of 73


(l) Is the Tenderer, its parent or associated entities currently in breach or default of any agreement, contract, order or award that would or would be likely to adversely affect the financial capacity of the Tenderer to provide the Services contemplated by this RFT?

(m) Are there any other factors which could adversely impact on the financial ability of the Tenderer to successfully perform the obligations contemplated by this RFT?

(n) Is the Tenderer solvent and able to meet its debts as and when they fall due in the normal course of business?

In addition to the information required above, Tenderers are required to undertake to provide to Peninsula Health (or its nominated agent) upon request (usually during the short listing stage) all such information as Peninsula Health reasonably requires to satisfy itself that Tenderers are financially viable and have the financial capability to provide the Services for which they are tendering. This may include:

a) A summary of charges (registered or otherwise), liens or encumbrances affecting the assets or the ownership of the Tenderer;

b) Details of the Tenderers Bank and details of Overdraft facilities, Bills and or Bank Guarantees currently in place.

c) Details of the existence of Cross Guarantees by the Tenderer with its parent or associated entities.

d) Details of the actual, expected or Contingent Liabilities of Tenderer and its parent entity, at the Closing Time, which may affect the Tenderer’s ability to provide the required Services.

e) Any changes to company structure or ownership or to directors as can be notified; either recent (within the past 12 months) or which are imminent

f) Audited financial statements comprising profit and loss account, cash flow statement, balance sheet and supporting notes for the preceding three years for the Tenderer and related entities (eg. Parent company);

g) Where audited financial statements are not available for the Tenderer or related entities, management accounts for the Tenderer or its related entities, including all profit and loss information, for the preceding three years;

h) Where there has been a period greater than three months between the end of the Tenderer’s most recent financial year and the Closing Time for this Tender, the most recent management accounts of the Tenderer and its related entities, including profit and loss statement, cash flow statement, balance sheet and other relevant financial information;

of 73


i) Details of the proposed means of funding which will, in the short and long term, provide for the acquisition of sufficient assets and working capital to meet the requirement of this contract. A cash flow statement may be required.

j) A statement from a recognised accounting firm (being a member of the Australian Society of Accountants or the Institute of Chartered Accountants in Australia or a similar organisation if the Tenderer is based outside Australia) attesting to the financial capability of the Tenderer to provide the Services;

k) Details of the full corporate and ownership structure of the group of which the Tenderer is a member entity, including a group structure chart showing ownership details.

l) Details regarding principals of the Tenderer (directors, partners including key staff) qualifications and business experience.

m) Details of the Tenderers contract performance history for the past 24 months including past projects, type and amount of contract.

n) Details of current Work in Progress including details of current contracts with Government departments; State and Federal.

o) Details of Licences held by the Tenderer relevant to the contract

p) Any other factors the Tenderer will support its position by demonstrating its financial capacity to provide the Services.

Provide your undertaking to comply with this request.

Risk management strategies

Provide details of all risk management strategies and practices of the Tenderer that would be applicable or relevant in the context of the supply of the Services.

8. Conflict of interest

Provide details of any interests, relationships or clients which may or do give rise to a conflict of interest and the area of expertise in which that conflict or potential conflict does or may arise and details of any strategy for preventing conflicts of interest.

Outline the processes you have in place to handle any future conflict of interest (actual or perceived).

of 73


9. Ethical Purchasing Policy

It is a condition of tendering for purchases of goods or services valued at $102,500 or more or where the tenderer participates in a high risk industry that shortlisted tenderers are required to complete an Ethical Employment Statement (RFT Part D) demonstrating that they satisfy the ethical employment standard set out in the Victorian Government Ethical Purchasing Policy (www.vgpb.vic.gov.au). Shortlisted Tenderers who do not comply with a request to provide Part D within the timeframes specified by Peninsula Health will be disqualified from the Tendering Process.

The names of Tenderers who submit an Ethical Employment Statement and are assessed by Peninsula Health as not satisfying the Ethical Employment Standard will be placed on the Ethical Employment Reference Register.

Please enter response in the box below. Response required: Understood and agreed.

10. Any other matters

Detail any matters which have not been covered in previous sections, and you believe need to be taken into consideration when your Tender is evaluated.

11. Disclosure of Contract Information

The Conditions of Tender include a provision for disclosure of contract information (refer Attachment A to this Part C). Identify any information in your Tender which you consider falls within the following categories and which you consider should not be published.

(o) Trade secrets

(p) Unreasonable disadvantage

of 73

http://www.vgpb.vic.gov.au/


Attachment A

(Refer to Section 11: Disclosure of Contract Information)

Contract disclosureThe Government has a strong presumption in favour of disclosing contracts and, in determining whether any clauses should be confidential, specific freedom of information principles (including a public interest test) will apply. However, even if certain clauses are excised from public contracts, the Government cannot pre-empt the workings of the Freedom of Information Act 1982 (Vic) or constrain the Auditor General's powers to secure and publish documents as he or she sees fit.

The Conditions of Tendering (Part A) includes a provision for the disclosure of contract information (paragraph 6.6).

This provision is consistent with the Government's presumption of the full disclosure of contracts. Any non-disclosure of contract provisions must be justified by the successful Tenderer by applying the principles for exemption under the provisions of the FOI Act. Section 34(1) of the FOI Act provides that information acquired by an agency or a Minister from a business, commercial or financial undertaking is exempt under the FOI Act if the information relates to trade secrets or other matters of a business, commercial or financial nature and the disclosure would be likely to expose the undertaking unreasonably to disadvantage.

If a Tenderer wishes to withhold the disclosure of specific contract information, the Tenderer must clearly outline how the release of this information will expose trade secrets or expose the business unreasonably to disadvantage.

Trade secretsIn considering whether specific information should be categorised as a trade secret, Tenderers should assess:

the extent to which it is known outside of the Tenderer’s business; the extent to which it is known by the persons engaged in the Tenderer’s business; any measures taken to guard its secrecy; its value to the Tenderer’s business and to any competitors; the amount of money and effort invested in developing the information; and the ease or difficulty with which others may acquire or develop this information.

Unreasonable disadvantage

In determining whether disclosure of specific information will expose a Tenderer’s business unreasonably to disadvantage, you should consider section 34(2) of the FOI Act. Broadly, you should consider:

whether the information is generally available to competitors; and whether it could be disclosed without causing substantial harm to the competitive

position of the business

Peninsula Health will consider these applications in the Tender evaluation and negotiations with Tenderers.

of 73


Attachment B

(REFER SECTION 5: CONFIDENTIALITY STATEMENT)

DEED OF CONFIDENTIALITY

1 INTERPRETATION

Definition

" Information" means information, documents and data stored by any means and any information made available to the Confidant in the course or his or her dealings with Peninsula Health

and includes information relating to:

(a) any intellectual property rights of the Peninsula Health(b) to the financial position or reputation of the Peninsula Health (c) the internal management and structure of the Peninsula Health (d) the personnel, policies and strategies of the Peninsula Health(e) Peninsula Health’s clients or suppliers

and information of Peninsula Health that has any actual or potential commercial value to Peninsula Health or to the person or corporation which supplied that information.

2 NON DISCLOSURE

2.1 The Confidant will treat as secret and confidential all Information to which he or she has access or which is disclosed to him or without the prior written consent of Peninsula Health.

2.2 If Peninsula Health grants its consent, it may impose conditions on that consent. In particular, Peninsula Health may require that the Confidant obtain the execution of a Deed in these terms by the person to whom the Confidant proposes to disclose the Confidential Information.

2.3 The obligations of the Confidant under this Deed shall not be taken to have been breached where the Confidential Information is legally required to be disclosed.

3 RESTRICTION ON USE

3.1 The Confidant will use the Confidential Information only for the purpose of its dealings with Peninsula Health (whether directly or indirectly).

3.2 The Confidant will not copy or reproduce the Information without the approval of Peninsula Health, will not allow any other person outside Peninsula Health access to the Information and will take all necessary precautions to prevent unauthorised access to or copying of the Information in his or her control.

of 73


4 SURVIVAL

4.1 This Deed will survive the termination or expiry of any contract between Peninsula Health and the Confidant providing for the performance of services or the provision of goods by the Confidant (whether directly or indirectly).

5 POWERS OF PENINSULA HEALTH

Production of Documents

5.1 Immediately upon request by Peninsula Health, the Confidant must deliver to Peninsula Health all documents in the possession or control of the Confidant containing Confidential Information.

5.2 If at the time of such a request the Confidant is aware that documents containing Confidential Information are beyond his or her possession or control, then the Confidant must provide full details of where the documents containing the Confidential Information are, and the identity of the person who has control of them.

6 APPLICABLE LAW

6.1 This Deed shall be governed in accordance with the law of Victoria.

of 73


Executed as a Deed

SIGNED SEALED AND DELIVERED

by ..................................................... .....................................................

[print name of person requesting Confidential [signature]

information]

position……………………………………

organisation ………………………………

in the presence of ................................... .....................................................

[insert name of witness] [signature]

SIGNED SEALED AND DELIVERED

by ............................................................. ....................................................

[insert name of supervising officer] [signature]

position……………………………………

organisation ………………………………

in the presence of .................................….. .................................................

[insert name of witness] [signature]

of 73

RFT Part D – Tenderer’s Response · Web viewPeninsula Health. Scanned Medical Records Tender....

Documents

Transcript of RFT Part D – Tenderer’s Response · Web viewPeninsula Health. Scanned Medical Records Tender....