Best Practice Guidelines: Medical | Dental | Allieds

In Diary Administration, the following configurations and practicalities need to be considered:

Doctors

• A Doctor/Practitioner is a person who is trained and licensed to treat sick and injured people.
• There are different types of Doctors/Practitioners:
• those working in the practice as owners, employees or locums; or
• those working with the practice as assistants.
• A Doctor/Practitioner can be listed in the software as:
• A Treating Doctor/Practitioner
• The Practitioner responsible for the treatment of the patient.
• Their practice number will be switched to the medical aids.
• Locums can be added under a Practitioner's practice number, with their own MP-number.
• A Referring Doctor/Practitioner
• The Practitioner referring the patient to the Treating Practitioner for further or more advanced treatment.
• Some specialities must include a referral letter and details of the Referring Doctor to receive payment from medical aids.
• An Assistant Doctor/Practitioner
• The Practitioner assisting in theatre or a procedure that requires more than one Practitioner.
• The Assistant Practitioner is not an employee or contracted party and is not the Treating Practitioner.
• An Assistant will be added as a creditor in the software and there are options for how they could be paid for their services, e.g. immediate payment for services or payment once the Treating Practitioner's account was settled.
• The Assistant can also invoice in their own software as a Treating Practitioner instead of being invoiced in the software of the main Treating Practitioner.
• A Surgeon
• The Practitioner who operates on the patient.
• A Surgeon must be added when using the Theatre Management function so that theatre lists can be populated with the necessary information.
• A Practitioners Portal like grandXchange can be used to share the live theatre list and all details of the Patient with the involved Practitioners, e.g. the surgeon, anaesthesiologist and physiotherapist.
• Practitioners sharing information with a group of Treating Practitioners should include a notification to Patients that the Patient's Personal Information will be shared with the group of Treating Practitioners to best protect the interests of the Patient.
• Staff
• The Practitioner who assists the Treating Practitioner with patients, e.g. a nurse or dental assistant. 
• Doctors/Practitioners need to be linked to the patient's electronic file for:
• Booking of the correct Treating Practitioner.
• Managing the Diary for each Treating Practitioner.
• Ensuring claims to be paid based on the correct practice number
• Third-party Practitioners databases:
• Maintains updated information of all registered Practitioners.
• Update the practice's information with all medical aids & third party databases, e.g banking details and contact details.
• Certain functions will be available for the practice when the Practitioner is linked to a third-party practitioners database, e.g. Medpages.
• Correct setup of the information is crucial and must be kept up to date at all times.
• Examples of information that is important in the day to day operations can be:
• the practice number
• the contact Information
• the speciality.
• Doctors not employed at the practice need to be deleted or marked as inactive to avoid being linked incorrectly to patient files.

List of Entities

• Every GoodX installation can host many entities, which is useful for bureaux and group practices.
• Entities are separate businesses and should be managed individually.
  
• Each entity must be configured with its own practice number.
• The first entity for a group practice / incorporated company must be either the group practice number or the leading practitioner's number.
• Suppose a managing company manages the practice and uses the software for bookkeeping purposes. The first entity will be for the managing company, and the field for the practice number will be populated with 1234567 since they will not have an HPCSA number. Further entities will be used for the Practitioners.
• For switching purposes, up to four practice numbers are switched to the medical aids:
• the leading practitioner's practice number or the group practice number; and
• the Treating Practitioner's practice number; and
• the Referring Practitioner in certain specialities; and
• the Assistant Practitioner for surgical procedures.
• Entities must be configured with the correct Practitioners to ensure the proper processing of data.
• If you need more information on how to start a practice, you are welcome to read the free book in our Learning Centre: "How to start your practice?" To find the book, click on the Best Practice Guideline Books on the bookcase.

Service Centres

• A service centre represents a physical place where the patient is consulted or treated, e.g. at the hospital, consultation room or at the patient's home.
• A service centre plays a vital role in:
• the billing rates that are allowed:
• Billing structures will be linked to different service centres to ensure that correct tariffs are used for billing.
• managing where the patient will be treated:
• E.g. if the patient is seen in the hospital, the practice needs to know if the Practitioner requires extra travel time; and
• if the patient is treated in the practice's consultation room, a consultation room should be available.
• stock management:
• A service centre is linked to a warehouse and then the stock will be invoiced from the correct warehouse (the location where the stock is physically kept).
• service centre linked to a booking type
• a service centre can be linked to a booking type, when the booking type is used on the appointment the default service centre will then be the one that is linked to the specific booking type and not the default service centre for the practice.

Multi-Diary / Multi-Doctor View

• The Multi-Diary / Multi-Doctor View allows the receptionist to view multiple Practitioner diaries simultaneously.
• If a user is responsible for managing and updating more than one Practitioner's Diary, they can use the Multi-Diary / Multi-Doctor View.
• The User can select which diaries to show on the Multi-Diary / Multi-Doctor View Screen in User Entity Settings.
• All the Functions available in the Main Diary are also available on the Multi-Diary / Multi-Doctor View Screen but can be set not to show all information, e.g. the Clinical data can be hidden from users who shouldn't have access to that information.
• The Multi-Diary / Multi-Doctor View helps manage appointments quickly on the same day between multiple doctors.
• The Multi-Diary / Multi-Doctor View makes it possible to move appointments between different practitioners.
• The User can view all available slots for the day for all Practitioners on one screen.

Multi-Day View

• The Multi-Day View is a view that shows two or more consecutive days in one view on the user's screen.
• The Multi-Day View makes it easy to schedule new appointments and choose the best time for the practice and patient.
• The Multi-Day View assists the practice and practitioner to plan ahead and see where open timeslots are for the next week or the next working day.
• Moving appointments between days will be much more efficient and quick.

Audit Diary

• The Audit Diary function assists the user to ensure that all bookings have been finalised.
• Filters can be used to filter the bookings that have not yet been billed or paid.
• Some functions can be used directly from the Audit diary screen for an efficient workflow for follow up work.
• The Audit Diary is a good control function for Bureaux.

Render Policy 

Render Policies provide the user with different ways of viewing the diary in the Web App, e.g. a normal diary view or a worklist view. Every user can choose their render policy to satisfy their work requirements and workflow.

• Timeslot:  this view shows all the available and booked timeslots for appointments. It can be set as a stacked view (double bookings are shown as separate rows) or an overlapping view (double bookings are shown next to each other in the same row).
• Stacked by Time: this stack view shows booked timeslots below each other, and no available timeslots will be visible. New bookings can be made by clicking on a new booking and will place the new booking into the correct timeslot and order according to the time of the booking. Practices that accommodate mostly Walk-in patients and work on a first-come, first-serve principle will typically use this view.
• Stacked by Status: this stack view will order the bookings according to the booking status. The statuses and status orders are configured in the software settings. This view is designed for practices that are not working according to timeslots but that assist patients in the order of their appointment status. For example, Practitioners who want to see which patients are ready for treatments or Cashiers who need to see all patients ready to make payments. It can be configured so that the Stacked by Status view will group all awaited bookings and arrived bookings.
• Stacked by Type: This view will order the bookings according to the Type of the bookings. The types and type orders are configured in the software's settings. This view is designed for the triage of ER/Emergency Practices. For example, Green, Orange and Red types will give the ER a chance to prioritise Red (Urgent) bookings etc.

Use of the Sidebar (Control bar)

• The sidebar is a bar that displays shortcuts (in the form of buttons), information or navigation options to specific functions in the system.
• The sidebar will open when you click on a patient's appointment, debtor file or other specific places.
• Use of the sidebar will give you quick access to the main functions, e.g. the patient’s appointment, sending SMSs, emails and statements, doing validations, changing the reasons for appointments etc.
• View basic information of a patient like demographic information, clinical information, last transaction history, outstanding totals, billing, receipting and account details.
• Ensure a quick and efficient workflow and measure the time it takes from the arrival of a Patient to treatment.
  

Theatre / Surgery

• This function enables the practice to add and manage patients who will be going to one or multiple theatres, to the theatre list.
• The practice can build theatre sessions to reflect the time that practitioners should be available at the hospital(s) for operations.
• The whole theatre procedure can be captured, eg ICD10 codes, theatre time, procedures, CTP4 codes, staff involved, prostheses and risks.
• Send your theatre list from the diary directly to the hospital and other involved Practitioners via email, spreadsheet or via a live link to a third-party practitioner portal.
• Book all patients that are on the theatre list onto the diary.
• The Practice's theatre list should be linked to hospitals to automatically make theatre bookings at the hospitals.
• Billing can be done from the Theatre bookings on the Theatre list.
• The Theatre list with the bookings can be printed on a hardcopy for the Practitioner of the hospital. 

Print Diary

• If the practice is expecting a power outage/load-shedding or is scheduled for computer maintenance, the diary can be printed for use during those times.
  
• The diary can also be printed when the practitioner travels and will not have access to a computer or electronic device or access to the internet.

Diary/Booking Statuses

• The purpose of Diary Statuses is to show the practice where the patients are in the patient flow process of the practice.
  
• Example: If the patient arrives at the practice, their status changes from Booked to Arrived. When the patient has received treatment by the practitioner, the patient status can be changed to Treated so that billing can continue.
• Every Status can be configured with a unique colour or symbol as the user requires to assist in managing the diary more efficiently.
• The purpose of Diary status colours is to show the user what the status of patients is at a glance.
• Example: If a patient arrives at the practice and is set to Arrive, the Colour of the booking will change. Every time the status changes the Colour will change and in this way, the user can organise his diary and make sure every patient is billed and their account settled.
• The Status can be linked to certain actions, eg. when the patient is billed the status can move automatically to the receipt so that the user will know that the next step is to request the outstanding invoiced amount from the patient.
• Statuses can be configured and the orders can be designed and linked to the next steps.

Diary/Booking Types

• The Diary Types assist the practice to manage patients by the type of consultation or procedure that will be provided. This helps the practice to work quicker and more efficient.
• Examples of Diary Types: Consultation, Follow Up, Medicals, Root Canal, Extraction and Fillings, ER Units with Red, Orange and Green.
• The Diary Type will communicate the amount of time the practitioner will need for each type of appointment. It will also assist the billing expert to know what to bill as the correct tariff codes and stock codes can be linked to the different types for ease of reference.
• Diary Types can be linked to the correct Service Centre to assist with the correct billing structures and place of treatment.
• The Diary Types can be configured each with their own length time slots, and linked to their own Macros/Combinations.
• The Diary Types can be configured not to be eligible for billing, e.g. Out of Office, Lunch or Meeting.
• Create Diary Types and link them with pre-configured communications, e.g. consent forms, questionnaires or reminder SMSs.
• Every Type can be configured with a unique colour as the user requires to assist in managing the diary more efficiently. 
  
• The purpose of Diary type colours is to show the user what the status of patients is at a glance.
• Example: All the consultation booking types will be green and all the follow-up booking types will be orange.

Timeslot History and Appointment History

• The history of each Appointment and Timeslot can be viewed.
• When an appointment is moved or cancelled, the Appointment History will show which data was previously captured for that appointment, when a change was captured and by whom.
• The Timeslot History will show which changes were made on a Timeslot.
• The difference between a Timeslot and an Appointment is:
• The timeslot is the line on the diary for a specific time, any changes that happened on that timeslot on any date or time.
• The appointment is the booking that can be moved around and keep the history where the booking was moved to and who for example. Does not matter where the appointment has moved the history of that appointment will be available on that appointment history. 

New Timeslots and Deleted Timeslots

• The diary is pre-setup with default timeslots. 
• Sometimes bookings will not use the entire or allocated timeslot, for example, 15 min timeslot but the consultation is only 5 mins. 
• A new timeslot can be easily created to accommodate another patient in between the next timeslot by creating a new timeslot on the diary, just by creating a new booking with the correct time.
• A new timeslot can be added at any random time to assist extra appointments or emergency patients.
• A timeslot can not be deleted, but the booking on the timeslot can be deleted if the patient did not arrive, billing was done or clinical notes were made on the booking timeslot.

Tasks and Tasklist

• Tasks allow users to delegate or communicate important duties to each other.
• Certain Tasks or Task types can be set up and decided how the Task functionality will be used in the practice.
• Please refer to the Communication course in Practice Management for more information on how to implement Tasks and examples of tasks in the practice.

Booking notifications (Icons)

• The purpose of the booking notifications is to show that all the critical steps were completed for the patient from the first time they enter the practice (file opened and validated) up until they leave (treatment is done and account submitted to medical aid or settled by the patient). 
• The booking icons are located on the Diary screen on each booking. The icons are different for each notification type by using Alphabet Letters and Colours in circles.
• When you hover over the icons, their statuses will appear to show you the details for each specific icon.
  
• Questionnaire: Any custom questionnaires, e.g. Covid Questionnaire to determine the patient's risk OR medical history questionnaires
• C: Clinical Case 
• D: Documents
• S: Switch
• I: Invoice
• A: Account
• V: Validation
• Paper Icon: Open Notebook

• Different colours will indicate different statuses or information. 
• For example:
• Red for documents still outstanding on the Documents icon or patient is still owing money on the Invoice icon.
• Green for a fully paid account on the account icon or all Documents were received on the Documents Icon.

Medical bureaux can use the stack view of the diary as a worklist to help them manage all instructions they receive from clients. The opening of Debtors is the starting point of the workflow process as indicated in the above Medical Debtors Management diagram.

IF the Practice also uses the software, they must ensure that the Bureaux don't have any access to the Clinical Data of patients. The Practice can ask GoodX to set up the Bureaux settings so they don't have permission to view or access any clinical data.

The diary statuses can be customised to assist bureaux to follow the progress on claims, for example:

• Invoiced - yellow
• Submitted - purple
• Receipted - green
• Done - blue

Every day's instructions can be viewed as a batch and the progress will immediately be visible so that outstanding work and follow up work can be completed.

The booking types can also be used for information purposes, for example:

• Medical Aid claims
• Private patient invoices
• IOD claims

The following reports will assist bureaux to follow up on outstanding work and give quick progress reports to their clients:

• Booking status report - provides information on outstanding work to be done depending on the status that was configured.
• Turnover report - provides turnover per billing code (the practitioners can see which procedures are more viable for their business). 
• Doctor overview - provides turnover, journals, medical aid outstanding and patient outstanding totals.
• Daybook/Debtor Transaction Drilldown - provides turnover, journals, medical aid outstanding and patient outstanding totals processed between dates (daily or monthly).
• Age Analysis - displays all the Outstanding balances (both for Medical Aid and Private) of the Debtors on the system and the Age of the outstanding balance as per the information selected from the Report set-up.

Bureaux will be in a position to get a full overview of all instructions so that no claims will lapse due to human error.

Third-party Data Sharing Portals

The Patient Portal

The Patient Portal is a web and mobile application which is integrated into GoodX. The application makes doctor-patient administration a paperless and pleasant experience.

• Features available in myGC:
  
• Online bookings
• Paperless information sharing (eg e-scripts & sick notes)
• Telemedicine consultations (Web App)
• Interdisciplinary bookings
• Online patient payments
• Patient protocols (Web App)
• Dashboard
• Kiosks

The medical practice is connected with myGC via GoodX.

Patients are connected via the web and mobile apps. To register a profile on myGC, visit https://www.mygc.co.za.

• Kiosks
• Kiosks give patients control over their data, as required by the POPI Act.
• It allows patients to digitally:
• capture their information
• update their information
• sign consent forms
• complete questionnaires

This gives the practice the ability to comply with the POPI Act requirements that patient data needs to be correct and available to patients.

• Kiosks can be wall-mounted, desk mounted or stand mounted.
• ID and medical aid cards can be photographed by patients and imported and facial recognition gives the practice the opportunity to identify patients so that correct patient files will be made available to practitioners.
• All patient information can be imported into GoodX by the practice, which makes the whole file opening process paperless.

The Practitioners Portal

grandXchange is a data exchange portal for practitioners. The purpose of the Practitioners Portal is to:

• Share theatre lists & operation details for shared procedures: the surgeon(s) and anaesthesiologist(s) will be able to share data based on a shared theatre list.
• Send electronic referral letters.
• Receive feedback after referrals.

The portal is available to:

1. Practitioners who work on the GoodX Web App to be able to share data with other practitioners who do not have GoodX Web App; and
2. Practitioners who both work on the GoodX Web App so that they can sync data through Grand Exchange and work directly on their GoodX Web Apps.

Capturing data on Grand Exchange does not create debtors in any Practice Management Application, but creates a shared knowledge base for practitioners who are involved in shared procedures. Medical debtors can be opened in the software based on shared information.