Clinic Management System 3.0
User Requirements Specification
Version / Date / By / Description2.0 / 11 Mar 08 / HKMA & ISIA / Enhanced for RFQ
TABLE OF CONTENT
Project Requirements
1.1Introduction
1.2User Profiles and Characteristics
1.3Operating Environment
1.4Typical Scenarios
1.5Issues and Concerns
1.6Requirements Outline
1.7Functional Requirements
Project Requirements
1.1Introduction
CMS 3.0 is a new, open-source software system that provides a reliable, standard-compliant, yet easy to use electronic medical record system as well as a clinic automation solution for solo and small group practices.
1.2User Profiles and Characteristics
The CMS 3.0 target users are the private medical practitioners (PMPs) in Hong Kong. There are two main groups of PMP in Hong Kong, namely general practitioners (family physicians) and specialists, and the two groups of users often have different clinic workflows and requirements.
There are different groups of users in a clinic that would use CMS 3.0, including doctors, nurses, allied health professionals, clerks, accountants and administrators; however, especially in a small clinic, a single user may have multiple roles e.g. doctor-cum-administrator, nurse-cum-receptionist-cum-dispenser.
For general practitioners, patients mostly attend clinic without prior booking (walk-in cases); while for specialists, appointment booking is usually required (booked cases), except for certain urgent cases. In some situations both walk-in and booked cases are present, and the receptionist has to manage the waiting list dynamically such that both types of patients are seen in a fair and time-efficient manner.
Clinic nurses have a wide spectrum of roles and skill levels: in a clinic setting, nurses can take the role of receptionist, dispenser, assistant, therapist, as well as administrator, bookkeeper and stock taker; in many clinics, a nurse has more than one roles. Besides nurses, some clinics also have other allied health professionals such as physiotherapist, dietitian, pharmacist etc.
1.3Operating Environment
There are different sizes and settings of medical clinics, from a single-doctor solo practice in one or more clinics, to a multi-doctor multi-specialty polyclinic, and to a multi-clinic medical group; their mode of operation can also be vastly different.
Most clinics in Hong Kong have an internal dispensary, so that after the consultation a patient can get the prescription in the clinic immediately; however patients also have the right to get a prescription sheet from the doctor and have the drugs filled in community pharmacies. In a polyclinic multiple doctors may share the same internal dispensary, or each doctor may have a separate drug inventory.
There are two main types of payment method: cash (some clinics also accept cheque, credit card or EPS) and medical cards, and in most cases the bill is settled on the spot, after consultation completed and prescription received. There are various insurance companies and medical groups that offer medical card schemes, whereby card-holding patients can receive medical services (free or with a low co-payment) at participating clinics, and the clinic gets reimbursements from the scheme operators subsequently. There are numerous medical card schemes currently in Hong Kong, and each scheme has different coverage/ co-payment/ reimbursement criteria; managing these schemes can be a major administrative hassle for a PMP.
In its daily operations, a clinic will need to interact with various external parties. Drugs and other medical supplies are ordered from dealers through phone or fax and are delivered on site. Patients are often referred to/ from other medical practitioners with referral letters/ reply letters. Laboratory and radiological investigations are usually done in external laboratories/ hospitals and orders are placed using standard forms. Investigation results are currently mostly delivered physically by couriers, but electronic delivery methods are starting to be developed.
Clinics in Hong Kong currently have various degrees of computerization: 1) totally paper-based registration/ patient indexing, hand-written medical record and drug labeling; 2) computerized patient indexing with generic database software, paper-based medical record and drug labeling by hand; 3) implemented commercial CMS solutions, but still maintains paper-based medical record; and 4) totally digitalized operations. There are usually no dedicated in-house IT professionals, and doctors or nurses often took up the role of IT administrators.
CMS 3.0 will be adopted by these various kinds of clinics, and it should facilitate conversion from paper based, paper plus electronic; and totally digitalized systems. CMS 3.0 should also be able to co-exist with a paper record system, as it is often impractical for clinics to digitize the massive volume of existing paper-based medical records. Implementation of CMS 3.0 should not require major changes in a clinic's workflow, thus the system should be flexible and customizable.
CMS 3.0 is expected to run in a typical small business environment: standalone server (+/- UPS), PC terminals for consultation room, reception and dispensary, connected to a local LAN via a router (may be wireless), and with broadband connection to the Internet. Majority of user terminals will be Microsoft Windows-based, but the system should also support Linux and Mac OS X operating systems.
1.4Typical Scenarios
Case 1 – Solo Practice
In the simplest setting, a PMP is the only doctor in the clinic, and there are a few nurses assisting the clinic's operations. The clinic has a consultation room for the doctor, a reception area-cum-dispensary operated by the nurses, and a waiting area for patients. Two to three computer terminals are installed in the clinic: one in consultation room, one or two in reception and dispensary; they are all connected to the local server via a router. A document printer and sometimes a flatbed scanner are attached to the consultation terminal, and a label printer to the dispensary terminal. The clinic accepts both cash payment and medical cards.
When a patient arrived in the clinic, the reception nurse would ask for the patient's name and ID, or the patient would present a follow-up card/ medical card. The nurse would then enter the name/ID/patient number into the system; the record is found and the patient is put on the waiting list, pending to be seen by doctor. If no record is found (new case), the nurse would ask for the patient's demographic details (address, phone, etc.) and enter the information into the system. Usually patients on the waiting list are seen on a first-come-first-serve basis, except for some special cases (e.g. critically ill/ injury patients) – the reception nurse would need to re-arrange the waiting list accordingly. The reception nurse shall also retrieve the physical record (if any) from record storage racks.
A nurse may need to measure a patient's vital signs (body temperature, height, weight, blood pressure etc.) before doctor's consultation, and input the data into the system.
A patient is called/ escorted by the reception nurse into the consultation room. The doctor opens the patient's medical record by selecting from the on-screen waiting list, and confirm patient's identity match the record by asking for patient's name. The doctor would then ask for patient's medical history, perform physical examinations and make a diagnosis; he would then record the details of the consultation or only the diagnosis on the system.
After a consultation, the doctor would usually (but not always) prescribe drugs to the patient. The doctor would open the prescription function, and enter the drug name/ dosage/ duration etc. for each item. After confirming the prescription is inputted correctly, the order is processed by the system – drug labels are printed automatically in the dispensary terminal, and the patient is put on a dispensary waiting list. The dispensary nurse fills the prescriptions according to the waiting list and the drug labels generated. Each set of drugs is checked by the doctor before being dispensed to the patient by nurse. The patient receives the prescriptions, pays for the bill, and leaves the clinic; the whole patient encounter is then completed.
During the consultation, the doctor may decide that the patient requires laboratory tests or referral to other specialists; he would use the system to print order forms or referral letters to be given to the patient. Also the doctor may use the system to print sick leave certificates or attendance certificates as required.
When test reports are delivered to the clinic, the doctor would review the results, and type or scan the reports into the system. For some radiological or endoscopic investigations, a CD-R recording the images may also be available; the doctor may import those DICOM3 images into the system as well. The doctor would then add the patient to a reminder list, where nurses would call the patient back to clinic for follow-ups.
Some clinics accept appointment booking by phone/fax; the reception nurse would check the appointment booking function for available time slots, and insert a new appointment as appropriate. Patients may call to change or cancel appointments as well. Walk-in cases would be slipped in the unbooked time slots or at the end of a booked slot if the booked case is finished early.
If the patient uses a medical card, he would present the card during registration; the reception nurse would check validity of the card by phone or on a web portal, and a medical card voucher would be prepared. The doctor would provide services according to the card's coverage and charges. After the consultation, the patient would sign the voucher and pay the fees (co-payments) as required. Subsequently the nurses would fax or post the voucher to the scheme operator for processing/ reimbursement.
Some patients, for example with chronic illnesses, would require regular follow-up and regular medications. During the consultation, the doctor could conveniently book the next appointment for the patient using the system; alternatively this task may be done by the reception nurse after the consultation. The doctor could also prescribe the patient's chronic medications easily, by selecting the list of drugs from the previous prescriptions, and making adjustments if necessary.
The dispensary nurse or admin nurse monitors the drug inventory with the system's help. The system generates warning for drug stocks approaching expiry date, and the nurses would dispose/ arrange for exchange with the supplier. Likewise low stock level warnings are given by the system so that the nurses could place re-orders in a timely manner.
At the end of a day, the nurses would balance the book, and check that the cash received match the system's cashflow report. The doctor would want to know the number of attendances and the amount of income generated; he would also want to know the income from cash and medical card patients separately.
Case 2 – Polyclinic
In a polyclinic, there are more than one doctor practicing; in some cases the doctors are of different specialties. Each doctor would have his own consultation room, but they may share some resources like reception, treatment room, dispensary etc. Each doctor usually has a separate schedule and appointment list, and the reception nurses/ clerk would have to manage all the lists simultaneously without mixing up the cases. Each patient would have a designated/ preferred doctor, and would be documented in the patient record. If the doctors share the same dispensary, prescription orders from different consultation rooms would be queued together in a single dispensary waiting list. But Individual doctors need a separate statement on income and drugs dispensed. Otherwise, the settings and operations are similar to that of a solo practice.
Case 3 – Clinic group
In a clinic group, there are multiple geographically separated clinics operated under the same group/ brand, coordinated centrally, and the clinics may share some common services e.g. diagnostic laboratories, inventories and logistics etc. Personnel may also be shared among the clinics, e.g. doctors and nurses may need to work in different clinics in different times.
Because of the local client-server architecture of CMS 3.0, each clinic of a clinic group would need to run a local server independently. System settings, especially user profiles, clinic drug list and document templates, can be synchronized among the clinics by import/ export functions.
In the current version of CMS, automatic syncing of settings and/or the patient database is not expected. A function to facilitate transfer of a patient record from one clinic to another is desirable but not mandatory. Remote access/ maintenance functions would not be provided as part of CMS 3.0, but can be achieved by e.g. firewall + VPN + VNC.
1.5Issues and Concerns
CMS 3.0 will have to address the following issues and concerns:
- Performance – this is essential especially in a busy clinic, and is a major determinant of user acceptance/ satisfaction;
- Reliability – to ensure business continuity, that implementing the system would not cause undue downtime or adversely affect clinic operations;
- Security and confidentiality – safe-keeping of medical record is a legal requirement;
- Connectivity and standard compliance – to pave way to future e-health in Hong Kong;
- System flexibility – suitable from small solo clinic to large clinic group, and allows for business expansion;
- Expandability – as open software, possible for various parties to build additional modules/ functions to enhance the system or improve connectivity.
1.6Requirements Outline
The functional requirements consist of the following parts:
- General requirements
- Registration, scheduling and appointment booking
- Consultation
- Prescriptions
- Standardized documents
- Inventory and dispensary management
- Basic accounting
- Reporting
- External interfaces
- System configurations
- Backup, recovery and archiving
- User Interface
- Security and confidentiality
- Performance, availability and scalability
- Technical
- Support
1.7Functional Requirements
Functions considered of primary importance have the alphabet “M” marked on the right margin, indicating that the function described by the statement represents a mandatory requirement. Features considered desirable but not mandatory have the alphabet “O” marked.
The Vendor should review each of these requirements against their proposed system, and provide a detailed Statement of Compliance on each and every requirement listed below.
1General1.1System Characteristics
The system be a client-server architecture, and be able to run locally within a clinic / M
The system be a platform-independent Java application / M
The system supports multiple computer terminals and multiple concurrent users of different roles (e.g. doctors, nurses, physiotherapists, administrators etc.) / M
The system employs a modular, open framework to facilitate future expansion of system functions / M
The system must be user friendly with automatic installation and set up or having a full set of installation guide / M
1.2Operating Environment
The system runs natively on Microsoft Windows XP and after / M
The systems natively on Linux Kernel 2.4 and after / M
The system be usable on Apple Mac OS X / O
1.3Software Licensing
The system uses an open source licensing agreement (preferably BSD license or GPL) / M
The Vendor clears all licensing issues of external system softwares/ modules required by the system / M
1.4Data and Information Management
The system maintains data in a structured format ensuring a minimum of text-based data / M
The system checks structured data for formats and range-limits as appropriate at time of data entry / M
The system handles all text-based data in Unicode/ ISO 10646 format, and supports the Hong Kong Supplementary Character Set (HKSCS) / M
1.5Functional Integration
The system supports data fields (e.g. patient demographic data, diagnosis) to flow seamlessly between different modules, without requiring re-entry / M
The system integrates different modules and functions to support a smooth workflow for users of different roles / M
1.6User Profiles and Permissions
The system supports multiple levels of users in different roles, each user has customized user profile and access permissions / M
1.7Templates and Most-Used Lists
The system supports editing, storing and retrieving of templates for functions with text-based entries (e.g. Progress Note, Referral Letter, etc.) / M
The system supports storing and editing of most-used lists to improve data entry speed, including most-used drugs (and dosages), diagnosis codes and item charges / M
The system supports storing of different templates/ most-used lists per user profiles / O
2Registration, Scheduling and Appointment Booking
2.1Patient Indexing and Demographics
The system maintains a Patient Table with essential information and demographic details, to allow for continuity of care and easy retrieval of record by users / M
The system generates an unique, internal Patient Number for each patient record (as some patients may not have HKID or other official identification documents) / M
The system allows for entry of different types of official ID number, such as:
- HKID
- Birth certificate
- Passport
- Permit Number for Traveling to and from Hong Kong and Macau (Two-Way Permit)
- The system also allows entering the type of official ID (e.g. “Two-Way Permit”, “Canadian Passport” etc.)
- Official ID number can be absent in some patients (e.g. newborns)
- The system shall validate HKID/birth Certificate according to check digit mod (11) calculations
The system supports patient records with English and/or Chinese names, and supports the input, display, and print of both Traditional and Simplified Chinese characters, with separate fields for surname and given names / M