WO2004034179A2

WO2004034179A2 - An endoscopy treatment management system

Info

Publication number: WO2004034179A2
Application number: PCT/SG2003/000242
Authority: WO
Inventors: Kian Chung Benjamin Ong; Khek Yu Lawrence Ho; Christopher Khor; Yock Young Dan; Fong Yee Kwok; Yin Kee Foo; Serene Yap Sp; Lai Choo Foong; Jocelyn Ramos Jawili; Jonhendro
Original assignee: National University Hospital (Singapore) Pte Ltd
Priority date: 2002-10-11
Filing date: 2003-10-09
Publication date: 2004-04-22
Also published as: WO2004034179A3; AU2003272182A1; SG113434A1; AU2003272182A8

Abstract

An endoscopy treatment management system including a data entry means to allow information to be entered into the system, an electronic storage means to allow data to be stored, a display means, a processing means, and an endoscopy image capture means, wherein the processing means manages the treatment of a patient by requesting data from a user through a display on the display means, the data being requested in a predetermined order so as to step the user through a pre-determined ordering of steps in an endoscopy procedure, and entered through the data entry means and stored in the storage means, the data including endoscopy images captured by the endoscopy image capture means.

Description

AN ENDOSCOPY TREATMENT MANAGEMENT SYSTEM FIELD OF THE INVENTION

The present invention is directed towards an improved system for the treatment management of endoscopy patients. BACKGROUND OF THE INVENTION

The correct diagnosis, treatment and management of patients facing endoscopy procedures is essential. Whilst the technology exists and procedures are in place to allow for such procedures, the management and support of such treatments are not ideal.

There is certain amount of information which must be collected from each patient before a procedure begins. This can include such information as the patient's age and any possible allergies. It is also necessary for the treating physician to order appropriate endoscopy procedures so as to obtain images of the area in question. These images are usually saved to a database so as to enable the physician to refer back to them at a later date if necessary. Following the procedure, it is not uncommon for the physician to prescribe various treatments. This entails the physician completing a prescription which details the drugs to be prescribed to the patient. So as to ensure patent safety It is incumbent upon the physician to ensure that these prescribed drugs do not conflict with any known allergies of the patient In some cases the physician may also wish to request that any specimens taken during the endoscopy procedure are subjected to histopathological and/or cytological examinations.

At any time during the procedures, the physician may be required to produce a report on the patient. In order to prepare this report it is necessary for the physician to review the various files on the patient and access the relevant systems so as to provide a complete report. This could include accessing patient details through a clinical database and also stored images of the endoscopy procedure from the storage database.

Each of the various systems that are operated by the physician are designed so as to provide the necessary output required. For example, hospital admissions do require accurate details as to the patient and also various other contact details. Similarly, the endoscopy images should be in a particular format for later analysis, and to provide a prescription, full details of the patient such as their name, is essential to be included along with the prescribed drug.

The existing systems have been designed with the users of the output in mind. For example as noted above, the pharmacist does require certain information in a certain format. Accordingly, the systems were designed so as to facilitate this output. This required the physician to have sufficient training to operate the system to thereby enable the system to generate the required output. Accordingly, a physician required much training to enable them to operate the various systems so as to produce the various outputs required.

As in most cases each of these systems operate independently of each other, it is often necessary for the same information such as for example the patients name, to be added numerous times. An example of this situation is that commonly during the initial consultation with the patient, the physician asks the patient various questions and enters the answers directly into a computer. Concurrently, another assistant in the same room is entering this into a separate computer so as to operate another system. This means that the physician and assistant could enter the data differently. Such redundant entry of data is both time consuming, and also introduces the possibility of human error in the data entry. Further, it is possible through error of fatigue for physicians to not enter or update areas of the systems or follow preferred procedures.

The various instruments utilised by the physicians are largely standalone instruments designed to perform a specific function, for example the capture of endoscopy images. Further, none of the instruments which are required by the physician are totally compatible or use similar data formats. For example, an endoscopy machine which is currently available makes use of a video capture card library to access bits and bytes of the pixels being transferred by the machine. This involves lower level pixel handling which is not supported by readily available report generators. Further, whilst a particular format may be generated, the pictures would need to be extracted in the correct sequence, labeled, and individually manipulated for display. Accordingly, it is not possible to date to simply link the various components into a single system for ease of use. Rather, it is still necessary for the physician to utilise and operate numerous instruments for a simple procedure. Some attempts have been made to improve on these procedures, although these improvements are largely restricted merely to the improved capture of the endoscopy images. However, the existing systems still can not process and handle these images. Other systems have attempted to reduce some of the redundant data entry, but still do not insure that all the procedures are followed and easily accessible.

An endoscopy procedure can also be a day treatment. In this circumstance, it is necessary for a report to be generated and issued to the patient prior to their discharge. As noted previously, this requires the physician to be able to access the various systems and as necessary insert further data so as to produce the required reports. The various systems are essentially a series of stored records which are largely text based as opposed to a tool which can be used by the physician to facilitate the management of the endoscopy treatment.

There is therefore a need for an improved system which reduces redundant data entry whilst still being simply and insuring proper patient care. OBJECT OF THE INVENTION

An object of the present invention is therefore to provide an improved system which seeks to avoid redundant data entry and also ensure ready access to data and adherents to preferred procedures. SUMMARY OF THE INVENTION

With the above object in mind the present invention provides in one aspect an endoscopy treatment management system including: a data entry means to allow information to be entered into the system; an electronic storage means to allow data to be stored; a display means; a processing means; and an endoscopy image capture means; wherein said processing means manages the treatment of a patient by requesting data from a user through a display on said display means; said data being requested in a predetermined order so as to step said user through a predetermined ordering of steps in an endoscopy procedure, and entered through said data entry means and stored in said storage means; said data including endoscopy images captured by said endoscopy image capture means. Ideally the data entry will be assisted by a template driven data entry system wherein predetermined data is selectable by the user. This template driven system can effectively take the form of the decision tree allowing a user to step through the various options following each selection.

In the preferred embodiment, the system may also provide for production of prescriptions, and in this arrangement would also check for any known allergies prior to issuance of the prescription. BRIEF DESCRIPTION OF THE DRAWINGS

Figures 1 through 18 exemplify screen shots of the preferred system.

Figures 19 through 27 show a possible flow diagram of the preferred system. DESCRIPTION OF PREFERRED EMBODIMENT

In regard to figures 1 through 18, in the preferred arrangement the user (usually the doctor/endoscopist) accesses the endoscopy system through an Internet browser, e.g. Microsoft Explorer. This can be done from any workstation linked to the server via an intranet or the internet. In this arrangement no other software application needs to be installed. In another arrangement the system could form a part of a much larger system, and thus be accessible from within the larger system. For example it is envisaged that hospitals in the future may have a series of modules directed towards different procedures such as endoscopy which may be accessed from a common interface.

The system takes the user through a series of screens, each relating to a step in a workflow. In the preferred system these are:

Patient List (appointments)

Pre-procedure

Capture Images

Post-procedure

Prescription

Patient Disposition

Histo/Cyto Order

Report Generation

The first screen (fig 1) shows the Patient List. This is a list of patients who have made appointments for the day and could also include walk in patients who may have been registered by the hospital. The doctor selects the relevant patient and the patient's file, which should contain all the patient's details, is called up and the user enters the pre-procedure screen (fig 2). The preferred system will also include a patient procedure list in the patient list page which will enhance the retrieval of the patients procedure history. Doctors will be able to retrieve historical records by procedure date, patients HRN Number, and endoscopist. If a record is selected from this screen, it will also lead to the procedures screen and display the latest procedure done to the patient.

The Pre-Procedure screen (fig 2) displays patient information and also contains various data fields which may be filled in by the user, such as the nature of the procedure to be undertaken, name of the endoscopist and his/her assistant(s), room, indications for examination, clinical history, etc.

An example of a template driven data entry field is the Indications for Examination field. By clicking on the binoculars icon (as shown in the figures) at the right end of data field, a dialogue box is opened (fig 3). The dialogue box contains several lists of pre-determined data arranged in separate columns. These lists ideally operate like a decision tree. Clicking on selected data in the left most column will reveal further choices in the column to its right, and so on. When the "Add" button is clicked, the choices selected will be input in the data field below the data lists. Clicking "Save" below the data field will save the data and close the dialogue box. The selected data is now entered into the Indications for Examination field (fig 4). If appropriate, the user can amend the selected data in the Indications for Examination field by typing in the desired changes.

Next, the relevant endoscopy procedure is performed and images from the endoscopy equipment is saved and displayed by the system on the Capture Images screen (fig 5). The user can assign labels to each of the captured images (fig 6), again using pre-determined templates. The user can also select images for printing.

The next step is Post-Procedure (fig 7). Here the user enters data such as the procedure performed, medication (fig 8), extent of exam (fig 9), procedure technique (fig 10), findings, therapy, and endoscopic diagnosis (fig 11), each preferably using a decision-tree type template. Saving the information brings the user to the next screen. Next is the Order Prescription screen (fig 13). Known drug allergies of the patient should be shown prominently on the right of the screen. The chemical compounds can be cross-referenced to a database of generic and branded drug names. Should any conflict occur between drug allergies and the drug prescribed, the system can then warn the user. The system can also check for drug interactions. The information entered here can be transmitted to a Prescription or pharmacy system which can instruct a dispensary to dispense the prescribed drugs to the patient. The dispensary or pharmacy could be a separate entity to the hospital and thus operate on a different system. In this arrangement the present invention could communicate with the pharmacy system. In this case the pharmacy would record the drugs actually dispensed, which may be different to these prescribed, and message or transfer this data back to the system of the present invention.

After prescribing drugs, the user proceeds to the Patient Disposition screen (fig 14). Here the user enters the principal diagnosis, secondary diagnosis (fig 15), recommendation and patient status. The principal diagnosis may be defaulted to the endoscopic diagnosis entered in the past procedure screen so as to minimise data entry and for easy editing. If a medical certificate is necessary, checking the Medical Certificate checkbox will display (fig 16) the medical certificate data fields to be entered by the user, for example the number of days medical leave, etc. Again fields may be defaulted so as to minimise data entry.

The Histo/Cyto Order screen (fig 17) allows the user to order Histopathological and Cytological examination of specimens taken during the endoscopy procedure. The data fields show the originator of the histo/cyto order and where the results are to be returned to, as well as the type of examination required, and describes the specimen to enable it to be tracked. Patient consent (or otherwise) for use of residual tissue for medical research may also be indicated here.

Finally, the Report Generation screen (fig 18) allows the user to select to print reports containing data exported from the data fields completed earlier.

The system preferably incorporates Appointment Data, Registration Data, Patient List, Pre-procedure data, Capturing of Images directly from Endoscopes, Post-procedure data, Patient Disposition Data, Prescription Data, Medical Certificate Data and Histology/Cytology Data, into one intelligent workflow-based knowledge system or wizard to produce desired reports like Endoscopy Report, GP Reply, Histo Order, Cyto Order, Medical Certificate, Prescription and Hospital Inpatient Discharge Summary, without the need for duplicate data entry and which guides the doctor in the necessary and relevant investigations, Diagnosis, Treatment and Documentation required clinically and administratively in an intuitive, wizard style that makes this approach of clinical practice in the area of Endoscopy complete, structured and consistent. In other words, it is relatively simple for the doctor to use the system as the correct screens will ideally be displayed automatically in accordance with the pre-determined workflow. The doctor need not have to think about which function and buttons to click next to produce the kind of reports that are required clinically and administratively. At the end of the whole process, all the reports that are required can be printed out.

This new wizard approach is an improvement from that presently available.

The overall arrangement of the preferred system can be seen in Figure 19. Obviously, it is necessary for a patient to register 1 before any procedure can commence. To improve and facilitate the sign in procedure, details can be taken from the appointment booking 3 which may have been made previously by the patient. This data should be checked for accuracy when the patient does register 1. Alternatively, if a patient is a "walk-in" patient in that they had no previous appointment, then data can be entered purely through registration 1. These registration details should then be stored for later use. If desired separate patient registration and procedure databases could be employed for greater confidentiality. The "registration" database could include information like registration data, visit data, billing data etc. A pre-determined set of this data, normally only data required by the doctor could be transferred real-time into the "procedure" database 6. This could include the patient's registration data, some of the visit data and appointment data. For example, if a patient is transferred from one ward to another, or changes his appointment, this is entered into the patent registration database and can then be transferred into the procedure database. Other data which is not required by the doctors, for example billing data, need not be transferred over. Alternatively a single database could be used. For security reasons, only certain persons should be entitled access to the database 6. The system may also keep a record of location, terminal ID, user ID, and any other pertinent information which may be relevant during review of the various procedures. In the preferred arrangement by knowing the user ID etc the system can "customise" the information displayed. For example, a doctor identified by his User ID accessing the system at his clinic may only have his patients' appointments displayed on the Patient List screen. Similarly, a terminal at a ward will display only patients in that ward and will not display any appointments. An advantage of this is that it minimises errors such as mistaken identity which could lead to a procedure being performed on the wrong patient.

The endoscopy system 9 will be linked to the database 6. The current preferred procedure to be followed by the system is as detailed in the previous screen shots shown in Figures 1 to 18. This includes, the modules Patient List 10, Pre-Procedure 11 , Capture Images 12, Post-procedure 13 and Patient Disposition 14. Following these stages, the user or physician will be able to produce prescriptions 15 or medical certificates 16, or order histopathological 17 or Cytological 18 examination, or finally produce reports 19 as required. These reports could include medical certificate (MC), Prescription (RX), an electronic hospital in-patient discharge summary (eHIDS), or GP REPLY which refers to a preferred function for generating a reply to the general practitioner who has referred the patient to the endoscopist. This could include information like what procedures were done, diagnosis (if any), etc.

Considering these modules in turn, And referring to Figure 20, the patient list 10 may be prepared and formatted to facilitate understanding. Appointment data 39 may be transferred from the previous appointment booking made by the patient. When the patient does present for the procedure, the patient proceeds through registration 1 which then provides the registration data 38. Figure 20 exemplifies how the system can determine how to display the patent list information. Whilst not essential to the overall system, in order to better manage the patients, it is preferred that the various patients are highlighted in some way. For example, patients who did not register even though they had a prior appointment 43 may be left unhighlighted. For those patients who did register and had a prior appointment, these may be highlighted in pink, and for patients who registered but had no prior appointment then these could be highlighted in yellow 45. The coloured list can then form the patient list 10. It will be appreciated that highlighting of the patients is not necessary, and certainly other colours could also be entertained. However, the highlighting can help the doctor decide which patient to see next. For example, if a patient makes an appointment for a specific time, the doctor will try to see the patient at the appointment time or as near to that time as possible. Thus walk-in patients have a lower priority than patients with appointments. The doctor will fit walk-in patients in if there is sufficient time. However, he will need information on the time of the next appointment and whether the patient with that appointment has arrived.

The Pre-procedure steps as shown in Figure 21 firstly require the procedure that is to be performed to be selected 11. The procedure could be any endoscopy procedure, for example a bronchoscopy or colonoscopy. The system then displays for selection the various details 46 associated with that procedure. These details require the physician to enter the various values to all the fields 47 as requested by the system. These fields do include the endoscopist, room for the procedure, the registrar, and the assistant etc. If the patient was referred 48, then the clinic or GP referring the patient should also be entered 49. Once the physician believes that all the fields have been entered, then the system will check to ensure that the mandatory fields 50 have been completed. If the entries are not valid 51 then the system will ideally prompt the physician to re-enter such values. If the entries are valid 51 then the data is saved 52 into the database 6.

Figure 22 shows the preferred arrangement of capturing of endoscopic images. The endoscope captures the various endoscopic images 27 which have been ordered by the physician. These images may be stored 28 in a temporary directory until the module is required to transfer them to the system. Once each image is captured 27, the system inquires whether further images 29 are required. Once all the images have been captured, the system ideally displays 30 all the captured images for review and labeling. The endoscopist can then label 31 each image and also tag 32 each image as to whether it is to be printed, archived, or deleted. By printing, the system may include both a physical hard copy print, or simply a storage to database. In the preferred arrangement printing will include both a physical hard copy and storage to database. If the image is printed 33, then it is also stored 36 in the database which may subsequently be archived in a networked storage device (networked attached storage) or other external storage device 37. If the image is not to be printed 33 but rather archived 34, then the image can be sent to external storage 37. Finally, the images which are not printed or archived may be deleted 35.

To do an endoscopy procedure, the doctor will first insert the endoscope (which is an instrument with a "tube" and a camera at the end) into the patient's organ. The video images will appear and change on the screen as the endoscopy is moved. When the endoscopist wishes to capture the image, the 'FREEZE' button on the endoscope is activated. Depending on the model of the endoscope, the endoscopist will release the freeze image using the same button, or the endoscopist may need to activate the "CAPTURE" button on the endoscope. Thus, the captured image is transferred from the video-endoscope to the Endoscopy system via a cable. The endoscopist can take as many images as required. Following the procedure, the capture 12 of required images, and examination by the physician then the post procedure 13 module can commence. The simple flow diagram for this is outlined in Figure 23. Again, the system can import the data from the previous modules. In particular, the pre-procedure 11 module should include all the background data. Once the system has imported this information, the physician is then prompted to enter 64 the post procedure information. This should include what medication if any was administered to the patient before or during the procedure, the extent of the examination and procedure techniques, and the findings and any other diagnostic analysis. Once the physician has entered these fields the system will again check to ensure that all mandatory fields have been completed 65. If a mandatory field, for example this could be findings, is not collected the system will again prompt the physician prior to progressing. Once all the fields have been entered, the information is saved 67 into the database 6.

If the physician orders a histopathological 17 or cytological 18 examination, then the system can follow the procedures as outlined in Figure 26. The system ideally uses default values 53 which have previously been entered either through the patient list 10 or pre-procedures 11. That is, details such as the patient's name, age and other various medical details do not need to be re-entered by the physician to request the order. The system thus determines whether a histopathological or cytological examination was requested 54. If histopathological examination 56 was requested, then the system prompts the physician to enter values 59 in any remaining fields which have not been completed through importing of the default values For example the default fields could include where the specimen is dispatched from, or where results are to be returned to. The system then ensures that all mandatory fields 60 are completed, and if the entries are not valid 61 again returns to the start of the module. If cytopathological examination 55 was requested then a similar process ensures. In both cases, the system may prompt to obtain the patient's consent 57 for a number of reasons or procedures. For example for use of residual tissue for medical research. Should the patient not give their consent, then the reason for this, if any, should be entered 58. If all the entries are validly entered into the system 61 , then the information is saved 62 into the database 6.

In the preferred embodiment, the system will also assist in managing and providing prescriptions to patients. Referring now to Figures 25a and 25b the preferred operation of this module can be seen. The system initially displays the medication history 75 of the patient. The doctor can then select whether he wishes to see what medication has been prescribed 76 to the patient. If this option is selected the system will display 77 the prescribed medication from the prescribed list 78. A doctor can also elect to determine what medication has been dispensed 79. Again, if this option is selected, the system displays 80 the dispensed medication from the dispense list 81. At this point the doctor can also view a display 86 of drug allergy data for the patient. A third option for the doctor is to consult the discharge list 83. If this option is selected, the system displays 84 the discharged medication from the discharge list 85. The fourth option allows the doctor to view the medication chart 87 of the patient. If this option is selected the system displays 88 the medication chart 89.

Once the doctor has been shown the drug allergy data 86, the doctor is then able to select the item from a list 90. A doctor may in the preferred system have his own list 91 , in which case he can elect to use his own preferred list 93. Alternatively, a department preferred list 92 may exist, and the doctor may elect to select 94 from this list. Alternatively, a master list 95 may be consulted. Once the doctor has selected from the list he is then prompted to enter various data such as the dose form, strength and frequency 97. The system will then seek to validate and then check for any alerts 98.

If the selected drug is a controlled drug 100, such that it requires a hand written prescription from the doctor, then the doctor is again requested to enter the drug 97. A controlled drug is likely to be a drug having a very strong addictive component. In the preferred arrangement if the prescribed drug is not a controlled drug 100 the system will check as to whether it is G6PD deficient 101. G6PD deficiency refers to lack of a certain enzyme in the blood. A person with this condition should not take certain drugs. Thus the system should prompt the doctor if such drugs are prescribed. The system then checks whether it is a G6PD drug and if so prompts as to whether the doctor should continue with the prescription.

If the drug is not G6PD deficient 101 or a G6PD drug 104, or alternatively the doctor has elected to continue with the prescription 107 then the system checks for any drug allergies 102. If a drug allergy 102 is detected the system prompts the doctor 103 as to whether the prescription should be continued. The doctor may elect to continue with the prescription if he considers that the allergies that may be suffered by the patient do not outweigh the benefits of receiving the drug. If the doctor does not wish to continue 103 the system then prompts 96 for the doctor to again select the drug to be administered.

The system will then consider whether the drug is restricted 105 such that it is desired to limit prescriptions of the drug to a certain quantity, dosage or duration. If the drug is restricted then the doctor is given the option to continue 106. Should the doctor elect to continue then the preferred system will again request the doctor to confirm this action 108. If the doctor does not continue then the system again prompts 96 for a drug to be reentered. The system will next check whether there is any drug to drug interaction 109. In this regard the system is checking if there are adverse interactions among all the drugs that have been prescribed for the patient. For example, if a doctor prescribes both aspirin and warfarin for a patient, the system should alert the doctor as there is an adverse reaction between these two drugs. If there is drug to drug interaction, then the system will enquire of the doctor whether the prescription should be continued 110. The doctor may then elect to reenter a new drug 96, or proceed on. Once these tests have been done, the system checks that all the mandatory fields 111 have been completed and that the entries are valid 112. If they are not valid, the system will again require the doctor to reenter the drug details 96. If the entries are valid 112, the system will then save the prescription 113 to the database 6.

As shown in Figure 24, during the patient disposition 14 phase, it might be necessary to issue a medical certificate 16. Again, the system is able to import default values 68 which can be taken from any of the previous stages. The physician is prompted to enter in the various values such as a recommendation and the patient status 69. In preparing the medical certificate 70 the physician is prompted 71 to enter in all the relevant details. For example, the type of leave and the duration. The system again checks that all the mandatory fields 72 have been completed and if not again prompts the physician. Once the fields have been completed the information is saved 74 into the database 6.

Prior to discharge of the patient, and at any other time, it may be necessary for the physician to issue a report on the patient. The report generation 19 module is exemplified in Figure 27. The system may be defaulted such that a standard report is produced. Alternatively, the physician could select a specific report to be printed, for example a medical certificate or a copy of the cytological examination request. When these reports are requested, the system will import the necessary data under the fields previously entered by the physician, and then generate the required report. Previously, it was necessary for the physician to enter data in a specific format and order so as to generate a suitable report. Under the present system, it is possible for the physician to enter the data in a logical order from a physician's point of view, and the system then formats this data into a suitable output. Existing systems are unable to achieve this.

In essence, the present endoscopy system is a system which guides the doctor, an endoscopist, through all the administrative procedures and paper work which an endoscopy procedure will entail.

It takes disparate processes, such as drug prescription, medical certificate issuance, updating of patient records, capturing of images from the endoscopy procedure, etc and links them into one complete workflow. In so doing, the system also captures data and stores it in an organised, easily accessible way. What used to be separate repositories of information, e.g. images, prescriptions, patient data, etc, are now linked in one database which is accessible through one software application.

Previously, each process is handled by different applications or modules, mainly focussed on the output required, i.e. the various forms and paper work required to record and give instructions for the various processes to be carried out. The user is required to input information repeatedly into each application to generate the forms and paperwork. This information has been stored as separate database entities by the various applications or modules.

The new system by contrast is organised around the user who inputs the information. The user is guided through the data entry process in stages which correspond to his or her normal workflow. Information is input once and the system exports the relevant data to other related information systems and reports. The information can also be stored in a single database.

What is also useful in the context of endoscopy procedures is that an admission and discharge report is required even though there is no hospital stay. The system collates all the necessary information and generates this report conveniently. Previously, the doctor had to collate the information for the admission and discharge report.

Besides including all the administrative processes in a convenient workflow, the system can also provide templates of standard data commonly entered. In some cases the most likely or common entries can be pre-entered into the data entry fields by the system. By navigating through various decision trees, the user can drill down and enter the relevant information by selecting it from predetermined lists. Where necessary, the user is also able to change the information entered by typing in changes or additional information in the data field. This saves time for the doctor and reduces omissions and mistakes in data entry. Because of the standardisation of the way data is entered, it also makes searching and data mining easier. As the templates can be designed with the help of senior consultant endoscopists, the system also provides some form of guidance for doctors with regard to endoscopy procedures. This can be of particular benefit at a teaching hospital, and enables training interns to follow and learn correct procedures.

To further exemplify the present system, the following sample scenario is provided.

Sample Scenario: • Patient Details: o Pat_demo

This database table stores the demographic data of patients like

■ HRN No: SF7777777

^■ Patient Name: PAT JANE DOE

■ Patient record number: 999999997.

There is one record in this table for every patient. Each record is uniquely identified by the HRN (hospital registration number). In Singapore the HRN is the identity card number of the patient for Singaporeans & PRs, or in the case of foreigners, it is a unique system-generated number.

Appointment Details: o Appt

This database table stores the appointment data of patients like HRN No: SF7777777 Patient Name: PAT JANE DOE Appointment Date: 2002.01.15 Appointment Time: 09:00 Clinic: OT.

There is one record in this table for every appointment that the patient has made with the hospital. Each record is uniquely identified by the HRN, the Clinic, the Appointment Date and Appointment Time.

o Appt_op_detail This database table stores the appointment detailed data of patients like HRN No: SF7777777 Appointment Date: 2002.01.15 Surgeon MCR: 05569G Operation Table: 1 B Nature of Operation: OGD. There is one record in this table for every appointment that the patient has made with the hospital. Each record is uniquely identified by the HRN, the Appointment Date and Surgeon MCR.

• Patient Registration o Episode

This database table stores the visit data of patients like

■ Patient record number: 999999997

■ Account Number: 20021234500C

■ Admission Date: 2002.01.15

■ Admission Time: 09:00.

There is one record in this table for every patient visit to the hospital, be it an outpatient visit or an inpatient visit. Each record is uniquely identified by the hospital system generated Account Number.

This database table stores the doctor details of each patient visit like

■ Account Number: 20021234500C

■ Doctor MCR No.: 04717A

■ Doctor Type: A - Admitting Doctor.

o Bed This database table stores the doctor details of each patient visit like

■ Account Number: 20021234500C

■ Ward: ENDO

■ Room: 10

■ Bed: 10.

There is one record in this table for every inpatient visit to the hospital, be it a day surgery visit or an inpatient visit. Each record is uniquely identified by the hospital system generated Account Number.

o Pat_acct This database table stores the account details of each patient visit like

■ Patient record number: 999999997

^■ Account Number: 20021234500C

^■ Fee Schedule: 4.

• Procedure details o Procedure detail

This database table records the procedure details of each patient visit to Endoscopy Centre like

HRN No.: SF7777777

Account Number: 20021234500C

Procedure No.: 101

Session No.: 1

Procedure Date: 2002.01.15

Procedure Time: 10:00. There is one record in this table for every patient visit to Endoscopy Centre in the hospital, be it a day surgery visit or an inpatient visit. Each record is uniquely identified by the HRN No., Procedure Date, Procedure Time, Procedure No., Session No.

o Procedure_data This database table records the procedure details of each patient visit to Endoscopy Centre like

HRN No.: SF7777777 Procedure No.: 101 Item No.: 1

Data Type: PREPROC Data Code: ERC002

Data Values: ERCP W DILAT. OF BILIARY STRICT. There is one record in this table for every patient visit to Endoscopy Centre in the hospital, be it a day surgery visit or an inpatient visit. Each record is uniquely identified by the HRN No., Procedure No., Data Type, Data Code.

• Histo Order o Hrs_order This database table records the Histology ordering details of each patient visit to Endoscopy Centre like

- HRN No.: SF7777777

■ Account Number: 20021234500C

^■ Sequence No.: 12345

- Doctor MCR No.: 05569G.

There is one record in this table for every Histology order made during a patient visit to the Endoscopy Centre of the hospital. Each record is uniquely identified by the HRN No., Account No., Sequence No., Doctor MCR No.

o Hrs_ord_test This database table records the Histology Test details of each Histology Order made by a doctor at Endoscopy Centre for a patient. It records data like ^■ Sequence No.: 12345 - Test Code: RH1

■ Test Description: Routine Histology (Small).

There is one record in this table for every Histology or Cytology Test ordered for a patient at the Endoscopy Centre of the hospital. Each record is uniquely identified by the Sequence No.

• Cyto Order o Cyto_order This database table records the Cytology ordering details of each patient visit to Endoscopy Centre like

■ HRN No.: SF7777777

■ Account Number: 20021234500C

■ Sequence No.: 10001

■ Doctor MCR No.: 05569G.

There is one record in this table for every Cytology order made during a patient visit to the Endoscopy Centre of the hospital. Each record is uniquely identified by the HRN No., Account No., Sequence No., Doctor MCR No.

o Hrs__ord_test

This database table records the Cytology Test details of each Cytology Order made by a doctor at Endoscopy Centre for a patient. It records data like

^■ Sequence No.: 10001

■ Test Code: CY1

^■ Test Description: Gynaecological Smear.

• MC (Medical Certificate) o cpss_med_cert This database table records the Medical Certificate details of each MC given to a patient by a doctor during his visit to Endoscopy Centre. It records data like

HRN No.: SF7777777 Account Number: 20021234500C Serial No.: 12345

Leave Type: (HF) Hospitalisation Leave, Fit to Attend Court Unfit From Date: 2002.01.15 Unfit To Date: 2002.01.20 Issue Date: 2002.01.15. There is one record in this table for every Medical Certificate issued to a patient a visit to the Endoscopy Centre of the hospital. Each record is uniquely identified by the HRN No., Account No., Serial No., Issued Date.

• RX (Prescription) o presc_hdr This database table records the Prescription details of each prescription given to a patient by a doctor during his visit to the Endoscopy Centre. It records data like

Patient Record No.: 999999997 Account Number: 20021234500C Consultation Date: 2002.01.15 Prescription Type: DM - Discharge Medication Prescription Order No.: 1 Prescribing Doctor MCR No.: 04717A. There is one record in this table for every Prescription issued to a patient by a doctor during his visit to the Endoscopy Centre of the hospital. Each record is uniquely identified by the Patient Record No., Account No., Consultation Date, Prescription Order No.

o cpss_presc_dtl This database table records the Items Prescribed on each prescription given to a patient by a doctor during his visit to the Endoscopy Centre of the hospital. It records data like

Patient Record No.: 999999997

Account Number: 20021234500C

Consultation Date: 2002.01.15

Prescription Type: DM

Prescription Order No.: 1

Prescribing Doctor MCR No.: 04717A

Description of Item Prescribed: MIDAZOLAM 15MG (MALEATE)

TAB (DORMICUM). There is one record in this table for every Prescription issued to a patient by a doctor during his visit to the Endoscopy Centre of the hospital. Each record is uniquely identified by the Patient Record No., Account No., Consultation Date, Prescription Order

• Discharge Summary o Disch_details This database table records the Discharge details of each patient visit to the hospital. It records data like

■ Patient Record No.: 999999997

■ HRN No.: SF7777777

■ Account Number: 20021234500C

- Medical Service: 073 - GENERAL MEDICINE (GASTROENTEROLOGY)

- Diagnosis: CHRONIC OR UNSPECIFIED PEPTIC ULCER OF UNSPECIFIED SITE WITH PERFO.

There is one record in this table for every patient discharged by a doctor from the hospital. Each record is uniquely identified by the Patient Record No., HRN No., Account No.

• Endoscopy Report o Procedure_detail This database table records the procedure details of each patient visit to Endoscopy Centre like

HRN No.: SF7777777 Account Number: 20021234500C Procedure No.: 101 Session No.: 1 Procedure Date: 2002.01.15 Procedure Time: 10:00. There is one record in this table for every patient visit to Endoscopy Centre in the hospital, be it a day surgery visit or an inpatient visit. Each record is uniquely identified by the HRN No., Procedure Date, Procedure Time, Procedure No., Session No. The contents of the Endoscopy Report is extracted from this database table.

• GP Reply o Procedure_detail This database table records the procedure details of each patient visit to Endoscopy Centre like

HRN No.: SF7777777 Account Number: 20021234500C Procedure No.: 101 Session No.: 1 Procedure Date: 2002.01.15 Procedure Time: 10:00. There is one record in this table for every patient visit to Endoscopy Centre in the hospital, be it a day surgery visit or an inpatient visit. Each record is uniquely identified by the HRN No., Procedure Date, Procedure Time, Procedure No., Session No. The contents of the GP Reply is extracted from this database table.

includes eight main components, namely: o Patient List - To display the doctor's appointments and shows who is scheduled for an Endoscopy procedure and can also indicate whether the patient has already arrived. o Pre-Procedure - Allows doctors to record pertinent information before the procedure is done such as the Endoscopist who will perform the procedure, indications for the examination, patient's clinical history, endoscopy room as well as the assistants and GP doctor, if any. o Capture Image - Allows clinicians to capture the endoscopy images during the procedure. They can select which images to print, archive, or delete and they can also label the images based on the customized labels list. o Post Procedure - After they have completed the procedure, the clinicians will record relevant information such as the medications given to the patient during the procedure, the extent of examination, procedure technique, findings, endoscopic therapy/treatment, and endoscopic diagnosis o Prescription - To allow doctors to prescribe medications. o Patient Disposition - Allows the clinicians to record the principal and secondary diagnosis as well as the recommendation. Also allows doctor to prepare the Medical Certificate. o Histo/Cyto Order - Ordering of Histopathology and Cytology tests o Report Generation - Generation of various reports. In operation as the preferred system is workflow based, once the doctor has selected a patient (from the Patient List page), the system will go directly to the Pre-Procedure screen and after saving the data, the system will automatically direct the doctor to the Capture Images screen. The images can be captured while the doctor is performing the Endoscopy procedure. Once the procedure is completed, the clinician can proceed to label and tag the images for printing, deletion or archiving. After saving, the doctor can record the relevant information such as findings and diagnosis in the Post-Procedure Screen. After saving the data, the system will lead to the Prescription page where the doctor is able to prescribe medications that the patient is going to take home, if any. Otherwise, the doctor can proceed to the Patient Disposition Screen, where the diagnosis can be recorded together with the recommendations and a medical certificate if required. After saving from this page, the doctor will be directed to the Histo/Cyto Order Screen where the test required can be selected. Required information in the Histo/Cyto order form can be taken from the Post Procedure Screen. The report generation screen will follow and will allow the clinician to print all the necessary reports.

The data entered in the Pre-Procedure, Post-procedure and patient Disposition screen can be translated into the Endoscopy Report, GP Letter, Discharge Summary, Histopathology Order form and Cytology Order Form.

This preferred system is thus a workflow based system that caters to how the doctors work. Unlike existing vendor systems which address a part of the problem and wherein the users are the ones adapting to the system, the present system adapts to the doctor's requirements and needs. The present system is unique in that there is no endoscopy system in the market today that allows doctors to write the Endoscopy Report and at the same time is able to do prescribing of medications, ordering of histopathology and cytology test as well as preparing of Medical Certificate and Discharge Summary at one go.

Whilst the method and system of the present invention has been summarised and explained by an illustrative application, it would be appreciated by those skilled in the art that many widely varying embodiments and applications are in the teaching and scope of the present invention, and that the examples presented herein are by way of illustration only and should not be construed as limiting the scope of the invention.

Claims

CLAIMS:

1. An endoscopy treatment management system including: a data entry means to allow information to be entered into the system; an electronic storage means to allow data to be stored; a display means; a processing means; and an endoscopy image capture means; wherein said processing means manages the treatment of a patient by requesting data from a user through a display on said display means; said data being requested in a predetermined order so as to step said user through a predetermined ordering of steps in an endoscopy procedure, and entered through said data entry means and stored in said storage means; said data including endoscopy images captured by said endoscopy image capture means.

2. A system as claimed in claim 1 wherein said data entry means includes a template driven data entry system such that pre-determined data is selectable by said user.

3. A system as claimed in claim 2 wherein said pre-determined data forms a decision tree.

4. A system as claimed in any preceding claim wherein said data includes historical records of said patient.

5. A system as claimed in any preceding claim wherein said processing means enables said user to generate a prescription for said patient.

6. A system as claimed in claim 5 wherein said processing means examines said data stored in said storage means to check for any known allergies prior to generation of said prescription.

7. A system as claimed in claim 5 or claim 6, further including a communication means to transmit said prescription to a drug dispenser.

8. A system as claimed in claim 7 wherein said communication means receives details of drugs actually dispensed from said drug dispenser.

9. A system as claimed in any previous claim wherein access to said system by said user is controlled by pre-determined security settings.

10. A system as claimed in any preceding claim wherein said data entry means includes mandatory fields which require completion by said user to enable said system to progress.

11. A system as claimed in any preceding claim wherein said endoscopy image capture means enables said user to select which endoscopy images captured are to be printed.

12. A system as claimed in any preceding claim wherein said steps include: displaying a patient list of patients scheduled for an endoscopy procedure; entering required information prior to the endoscopy procedure; capturing and selecting endoscopy images to be printed; recording post procedure information; prescribing medications; recording diagnosis; ordering tests; and generating necessary reports.

13. A system as claimed in claim 12, wherein said required information includes the endoscopist who is to perform the procedure, indications for examination, patient's clinical history, endoscopy room, and any assistants.

14. A system as claimed in claim 12 or claim 13, wherein said post procedure information includes medications given to the patient, extent of examination, procedure technique, findings, endoscopic therapy, and endoscopic diagnosis.

15. A system as claimed in any one of claims 12 to 14, wherein said reports available for generation include endoscopy report, GP letter, hospital in patient discharge summary, histopathology request form, cytology request form, prescription form, and medical certificate.