RFT Part B – Specification - Peninsula Health€¦ · Web viewRFT Part B - Specification. ......

RFT Part B – Specification

Peninsula Health

Specification for Scanned Medical Records Tender

Peninsula Health: Scanned Medical Records TenderRFT Part B: The Specification23 February 2010

RFT Part B - Specification

Contents Page1 Introduction 3

2 Scope of Tender 5

3 Service Conditions 6

4 Statement of Requirements 7

4.1 Key Functional Requirements 7

4.2 Functional Requirements 11

4.3 Technical Requirements 29

4.4 Capabilities/Capacity 40

5 Quality Standards & Accreditation 41

6 Privacy & Confidentiality 41

7 Payment Terms 41

8 Further Information 41

of 42


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

Frankston HospitalHastings RoadFRANKSTON 3199

Rosebud Hospital1527 Pt Nepean RoadROSEBUD 3939

Mount Eliza CentreJacksons RoadMOUNT ELIZA 3930

Frankston Aged Care and Rehabilitation Service 125 Golf Links RoadFRANKSTON 3199

Frankston Community Health CentreHastings RoadFRANKSTON 3199

Frankston Community Care Unit4 Spray StreetFRANKSTON 3199

Michael Court Residential Aged Care Michael CourtSEAFORD 3198

Peninsula Community Mental Health Service15-17 Davey StreetFRANKSTON 3199

Rosebud Community Rehabilitation Service288 Eastbourne RoadROSEBUD 3939

Rosebud Community Health Centre1527 Pt. Nepean Road

ROSEBUD 3939

Rosebud Residential Aged Care Service Point Nepean RoadROSEBUD 3939

of 42


The Mornington Centre Cnr Separation Street and Tyalla Grove MORNINGTON 3931

Mornington Community Health Centre 62 Tanti Ave MORNINGTON 3931

Hastings Community Health Centre Cnr Cool Store Rd and Victoria St HASTINGS 3915

of 42


2. Scope of Tender2.1 Tenders

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

2.2 Mandatory Requirements The successful tenderer will be a legal entity with which Peninsula Health is able to

contract. The Tender response must describe and provide evidence of the legal status of the Tenderer, including their Australian Business Number (ABN).

2.3 General Requirements The tenderer will demonstrate an understanding of the requirements of the Tender.

The tenderer will describe the experience of the Tenderer in relation to the provision of similar services.

The tenderer will provide references from or contact details of at least two clients within the health industry for whom the Tenderer previously carried out similar activities. Referees will not be members of the Tender Evaluation Group (TEG) and should preferably be from outside Peninsula Health.

The tenderer will provide sufficient supporting documentation to enable Peninsula Health to satisfy itself as to the financial, technical, planning and other resource capability of the Tenderer to successfully undertake the service.

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

of 42


2.4 Service conditions 3.1 Code of Behaviour

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

3.2 Workcover The successful tenderer as Contractor shall be insured and be covered during the period

of the contract to the full extent against liability to his employees employed in the performance of the contract, under the laws enforced in the State in which the contract is being performed relating to Workcover and shall waive all rights of subrogation and indemnity against the health service and its officers, servants and agents given by such law to the Contractor (and the Contractor shall ensure that its insurer likewise waives its rights) in respect of claims by employees of the Contractor for injury (including injury resulting in death) arising from work performed under the Contractor

The Contractor shall be solely responsible to meet all payments, costs and expenses arising out of any claims and proceedings for damage, loss, death or injury or of to the Contractor and the Contractor’s officers, employees, agents, sub-contractors, invitees and licensees which may be sustained in the performance or work pursuant to the contract and the Contractor shall indemnify Peninsula Health, its employees and agents against any claims and proceedings made in respect of damage, loss, death or injury.

The Contractor shall on demand produce to the Chief Executive Officer of Peninsula Health for inspection, the cover notes, policies and premium receipts in proof of the existence of such insurance.

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

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

3.4 Terms and Conditions Venders must comply with the terms and conditions as specified on our website.

www.peninsulahealth.org.au. Any additional costs such as delivery costs, administration fees, handling fees, minimum order costs, etc. Will not be excepted unless specific written permission has been granted.

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

of 42


4.1 Key Functional Requirements

Key Functional Requirements Comments

Currently operational within a health environment

Ability to support the system with an office/support staff based in Australia

4.1.1 General

Access scanned record 24/7/365

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

of 42



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

of 42



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

of 42


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

of 42



as detailed within Section 9 of the Act must be met:

- “ …a method is used to identify the person…”

- “… the method was as reliable as was appropriate for the purposes for which the information was communicated…”

If required to produce a document under law the requirements for production as detailed within Section 10 of the Act must be met:

- “…the method of generating the electronic form of the document provided a reliable means of assuring the maintenance of the integrity of the information contained within the document…”

- “ .. the integrity of the information contained in a document is maintained only if the information has remained complete and unaltered, apart from – the addition of any endorsement; or any immaterial change ….”

As described within Section 11 (c) all transactions within the system must contain sufficient detail to enable identification of the following;

- “the origin of the electronic communication”the time and date of the transaction

4.2 Functional Requirements

Functional Requirements Comments

4.2.1 General

Access scanned record;

24/7/365

Access scanned record from any terminal on the network

Access scanned record remotely

Access scanned patient record (to individual document level) by multiple users simultaneously

Process from scanning to saving in the system must be automated and integrated ie. minimal or no intervention by operator unless fails quality control processes

The system must be simple to navigate, user friendly, intuitive and require minimal training

of 42



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

of 42



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

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

of 42



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

of 42



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

of 42



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

of 42



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

Hyperlink the search results to the patient record

Patient record

of 42



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

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 42



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

of 42



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

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

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

of 42



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)

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 42



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

of 42



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

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

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

of 42



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 Enter/edit on e-forms

Ability 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 hierarchyMap barcodes to form identifiers

Print header sheets for non pre-barcoded forms where required

Print labels for non pre-barcoded forms where required

of 42



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

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

of 42



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

UR

Name

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.

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

of 42



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

of 42



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

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

of 42



Reporting – results view & endorse

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

Access audit trail

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

4.3 Technical Requirements

No. Technical requirement Comment4.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

of 42


No. Technical requirement Commentminimum 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

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

of 42


No. Technical requirement CommentThe web-based client must have minimal or no dependence on Active X or Java (offerer must provide details of any ActiveX or Java components)

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

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

of 42


No. Technical requirement CommentIt 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.

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

of 42


No. Technical requirement CommentState 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 medical 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

A40 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

of 42


No. Technical requirement Commentpurpose.

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

To 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

The Peninsula Health Pathology Service is currently contracted to Dorevitch who use the laboratory system

of 42


No. Technical requirement CommentUltra. 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 system 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

of 42


No. Technical requirement Commentseparately.

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.

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


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

of 42


No. Technical requirement Commentimage.

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 cost

Birthing 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 desirable 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

of 42


No. Technical requirement Commentsystem.


4.3.6 Server Infrastructure

Operating System and Environment

Peninsula 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

State 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

of 42


No. Technical requirement Commentimplement 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 operating 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.

of 42


No. Technical requirement Comment4.3.7 Health service Operations and User

managementReference 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

It 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 type

The system has the ability for a user to be able to view / access both the scanned document as well as the 3M Codefinder

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

of 42


No. Technical requirement CommentThe web-based system will be customisable to include hyperlinks to and from other systems, at the Health Service’s discretion.

4.4 Capabilities/Capacity

Capabilities/Capacity Comment4.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 functional 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 42


5. Quality Standards & Accreditation Tenderers are required to provide Peninsula Health with external verification of evidence

that demonstrate achieving and maintaining the requirements under the following Australian Standards:

The service provider will provide such assistance to Peninsula Health in respect of Australian Council on Healthcare Standards (ACHS) EQuIP accreditation as is reasonably requested.

6. Privacy and Confidentiality The service provider will be required to respect privacy and act in accordance with Peninsula Health’s policy in relation to patient confidentiality. This requires all staff of the service provider to keep in confidence all information pertaining to a patient, client or resident at Peninsula Health.

7. Payment TermsPayment 1 - 20% of agreed costs on signing the agreement and issue of purchase order

Payment 2 - 30% of agreed costs 60 days following payment 1, and on receipt of software and preliminary implementationPayment 3 - 30% of agreed costs following the successful testing of Peninsula Health’s live data by trained staffPayment 4 - 20% final payment of agreed costs following agreed sign off of all system requirements.

8. Further InformationEmilia PezziManager, Health Information Services

Email: [email protected]

Phone: 9784 7630

Fax: 9784 8502

08.30 – 17.00 business days

Peninsula Health is not bound to provide additional information outside of the tender documents. Any response or information will be provided to all Tenderers.

of 42

mailto:[email protected]

RFT Part B – Specification - Peninsula Health€¦ · Web viewRFT Part B - Specification. ......

Documents

Transcript of RFT Part B – Specification - Peninsula Health€¦ · Web viewRFT Part B - Specification. ......