IES Medical: Master Files

IES Medical: Master Files

Purpose

The purpose of this Document is to introduce the Master File options in the Medical system.

Introduction

The Master File function is selected directly from the main Medical menu.

Current Consultations

This option is the same as offered on the ‘Consultations’ function, and is included here for convenience. It leads to selection of a current Consultation and presents the Consultation screen for transacting.

New Account Holder

This option is used to create a new Account Holder, and is also automatically entered when a new Consultation for a new Patient is opened and when the Account Holder record does not yet exist. The system assigns the Key for the new Account automatically.

The Account Holder record consists of fields which are in some cases forced, and in others are optional. All are quite simple and requires little further explanation. For this screen, as for others discussed below, you can also check the on-line help for more information on the current field being captured or edited (e.g. F1 or Help icon), and if you are not sure whether a field is forced (it usually indicates so on the help, i.e. whether or not) you can try to bypass it – if it is mandatory the system will beep and advise that you have to fill that field.

Current Account Holder

This option is used to change, update or otherwise maintain exiting records. It will ask whether you know the Account number or want to search for it. Once the record is selected, it is the same as shown above for new records.

New Patient Record

As is the case with a new Account Holder, this option is also automatically initiated when a Consultation is opened and the Patient is new. When the Account Holder (person responsible for payment) happens to be the same person as the Patient, then the system will automatically cross default the information already captured on the one or the other. Patient record keys are also assigned by the system, as for Account Holders. Below, we show a Patient record for the same person we have shown the Account Holder above.

Once again, there are simple fields to capture, some optional, some forced. There are also some other functions, e.g. ‘New Title’ is used if, while capturing a new Patient record, there is no suitable title to select, and then there is no need to leave the current screen – you can simply define a new title and return to where you have left off.

There are also options (top right) to drill into the linked Account Holder, Customer Account, etc.

Current Patient Record

This option is used to maintain an existing record, or simply to drill into related links to the Patient record.

Whenever you have to select a Patient, the system presents the ‘Locate Patient Record’ wizard –

You can use ‘fast find’, or specify a known Patient number or Patient ID number to locate the correct Patient record.

Help for the ‘fast find’ function states the following: -

Patient retrieval may be done by means of the standard lookup or direct-type searching on multiple criteria: -

01) To use the standard lookup, press F2 or click the Lookup (dbl-click and

choose Lookup).

02) To use an implicit multi-rule lookup, use a dot (.) and use any of the

following: -

part_name.part_tel_no.part_address

part_name..part_address

part_name.part_tel_no

..part_address

.part_tel_no.part_address

.part_tel_no

part_name.

in other words, use any 1, 2 or 3 parts to search on, separated by dot(.) and where part of the family name, if specified, is always BEFORE the 1st dot, and the tel no always after the 1st dot but before the 2nd dot, and the address pattern, if present, is always after the 2nd dot.

Examples: -

a) finding by part name -

souw.

which would find something like 'Rossouw'

b) finding by name and address -

rossouw..sunset boul

which would find 'rossouw' living on 'sunset boulevard'

c) finding by name, tel no and address -

osso.5553.sunset

which would find the same patient where the tel no includes '5553'

d) finding by address only -

..sunset

which would find patients living on 'sunset boulevard', 'sunset rd', etc.

IF NO DOT (.) IS USED, THEN THE INPUT DATA IS CONSIDERED TO BE THE TYPING OF THE PATIENT NAME, I.E. NO LOOKUP IS ENTERED.

Access Profiles

Access Profiles is quite a big subject in IES. Every User of the system has access profiles (menus) for each module he or she has access to. In addition, many modules also have additional ‘business profiles’ that describe other privileges in the selected module, and the Medical module has this also. This option enters the ‘special privileges’ profile for Medical.

Hint: For other Medical Menus and access rights to these, see the Access Profiles Manuals.

Essentially, each User of the Medical module either has the right to close Consultations or does not have it. For Consultation Notes, Prescriptions and Lab Tests, all of which may be regarded as potentially sensitive or confidential information, each User has a privilege level – cannot see at all, may see but not update, may update ‘own’ or any … (see the on-line help for more).

Titles

This is a typical Parameter Master File option. Each Patient and Account Holder is assigned a Title, but the title is not typed, i.e. it is selected by code only. This prevents the same thing from having multiple versions, like ‘Mr’ and ‘Mister’.

Religions

The Patient’s religion is often recorded (though optional), as religion can often have a bearing on treatment or allowed procedures. It is always useful information anyway. As for Titles, Religions are recorded by code and description.

Medical Aids

Medical Aids, when in use, require some address and contact detail to be specified. Below, we just show a portion of the Medical Aid Master File screen.

Relation Types

Once again, similarly to Titles and Religions, Patient records indicate ‘others’ who may be contacted, and the relation type, e.g. Sister, Friend, Spouse, etc.

Doctors

Each Doctor in the Practice is recorded with a Code and the Doctor’s name. If on-line prescriptions are performed, then the relevant header text for the Doctor, to be printed on Prescriptions, is also defined.

Laboratories, Lab Categories, Lab Tests

These options generally consist of a Key and a Description or Name, and are used with the Lab test functions. Quite often, a Practice will use only 1 Laboratory, but there can be many. The Lab Tests define the codes that may be used for requesting a Lab Test of a specific nature, and this list may be expanded all the time. The Categories are simply used to group the different Tests into groups, e.g. Blood Tests, Allergy Tests, etc.

Prescription Codes, Prescription Classes, Med Substances, Diagnosis Codes

Prescription Classes are the groups for Prescription Codes, the latter being the actual drugs or medicines that are prescribed.

Med Substances are locally defined for the practice and used primarily to indicate Patient allergies.

The Diagnosis Codes are also as defined for local needs, and are used to classify Consultations, by attaching 1 or more Diagnosis Codes to a Consultation. If this convention is followed, then the Statistical wizard can produced useful information about how many such and such cases were encountered in a specific period, etc.

Retail Catalog

The Retail Catalog option is not shown on the Medical Master File wizard, and is accessed in the Retail module from the File Maintenance options, but we discuss it here, because although it is documented in the Retail User Manuals, the screen takes on a different view when used in a Medical system, due to different capabilities offered in the Medical context.

Hint: The Retail Catalog is very important, since it includes all the standard Charges that are used on Patient Invoices.

Below, we show the 1^st page of the Retail Catalog screen, and comment as follows.

Each Catalog Item has a Key or Code, and when this code is used on an Invoice, the charge is passed to the Invoice. (Hint: Of course, it is not necessary to know the code, you can simply type a part of the description for an auto search, or use the lookup …). The Key is usually numeric, but alpha characters are allowed if you prefer. As such, you can use your own numbering system and introduce any items in your Catalog that you need.

The Description not only indicates what the item is, but is also passed on to the Invoice (or Statement). Therefore, if a 2^nd language is used in the system for Invoices and Statements, it is a good idea to include the alternate language description as well, immediately below the English description. When an Invoice or Statement is processed, it will always show the English description on screen, but when the Invoice or Statement is printed or generated, and it is intended to be in the alternate language, then the 2^nd language description will be used if it is indicated, and if not indicated, then the English is used.

Each Item MUST have a current Price, whereas the claim price and the price units are optional. If a claim price is not indicated, it is assumed to be the same as the Price, and if it is indicated, then the difference between the two is what is called ‘excess’. In the case of Medical Aid claims, if the claim price is lower than the Price, then the Medical Aid will only pay the claim price, and the excess must then be collected from the Patient (or rather the Account Holder for the Patient).

Price Units are used to internationalise rates. For example, for all Catalog items where the ‘price unit’ is indicated, new prices can be automatically calculated whenever they increase (usually annually), based on the number of units, by simply specifying the latest financial value for 1 unit. In other words, a Consultation Session may be internationally classified as worth 4 units. In the USA, the unit value may be $20, whereas in South Africa, the unit value may be ZAR25, therefore, the new price for the US Catalog would be $80, and in South Africa it would be ZAR100. (Hint: The use of price units is optional, but beneficial for managing your Catalog. These standards are not applied in all countries.)

The Income / Cost of Sale indicator determines how the transactions are recorded as Income and Cost of Sale in the Financial system, and your standard codes are usually set up during implementation, but can be expanded as needed. (Hint: See the File Maintenance option called ‘Income Ledger Routes’ in Retail.)

The next item on the Catalog Item is called ‘Ratebooks’. Ratebooks represent a method whereby different Patients (Customers) may be charged different prices for the same items. Ratebooks are defined from Retail, File Maintenance and once a Ratebook is defined a Customer or Patient Account can be linked to a Ratebook by specifying it on the Account Holder master record. After that, when that Ratebook appears with a price on a Charge Item in the Catalog, then that Patient is charged on the basis of that Ratebook rather than the standard price. On the Catalog Item therefore, any number of Ratebook prices can be indicated, and just as for the normal Price, a claim price may or may not be indicated.

Under the ‘Settings’ heading, we find the Transaction Status, Tax Parameter, Unit of Sale and Claim Code.

The Transaction status can be ‘Open’ or ‘Closed’. When an Item is no longer used or allowed for charging, then the status is set to ‘closed’, which effectively prohibits it from being used on an Invoice. The reason for this, rather than deleting the Item from the Catalog is that the system may be full of historical Invoices where that same Item appears. As such, it is retained, but no longer transacted.

The Tax Parameter, of course, indicates to the system whether to charge Tax (e.g. VAT / PPN / GCT / GST) on the item, and what kind specifically.

The Unit of Sale indicates the Unit in which the Item is charged, e.g. ‘each’, ‘box’, ‘dozen’, etc.

Under the ‘Catalog Hierarchy’ we find fields for BOM (bill of materials), Swops, Groups, Sub Groups and Sub Sub Groups.

A BOM is a useful method for combining a number of separate Items into a single code. For example, when details of the constituent Items are required on the Invoice (often because the Medical Aid needs to see the Items being charged separately), then the Items can be defined as a BOM (Retail, File Maintenance). For example, let us suggest some vaccination item. Possibly, this charge consists of (a) performing the injection, (b) the syringe that is used and (c) the vaccination fluid itself. These 3 Items may be combined as a BOM code, which is then indicated on a Catalog Item, and when the Catalog Code is used on an Invoice, then the system automatically inserts 3 lines instead of 1 on the Invoice, listing each separate Item.

A ‘swop’ is always another Catalog code, and whenever the 1^st code is used, and a swop is indicated, the system switches to the swop code and uses that. In other words, a swop can be used for superceding old codes, or even to call a different BOM.

The Groups, Sub and Sub Sub groups are really used to ‘organize’ the Catalog, and be able to report on it more easily in different ways. This is quite useful for large Catalogs, but in a small Catalog it is not very important, and in that case you can just use ‘DEF’, to indicate that you are not really using Groups to any significant extent.

The Retail Master has another ‘page’ to the screen, which we show below. This part indicates whether the Catalog Item is simply a Services Item or in fact Stock that is kept in Inventory. For Service Items, a “*” is indicated for the Store No, meaning that it is not really a physical Stock item. If it is Stock, then the Stores it may be traded from are listed.

Further, if it is actually Stock, a Bin Code may be indicated, and it is also possible to indicate that Stock Tracking is required. For example, medicines are commonly manufactured in ‘batches’ and stamped as such. If a batch is at any stage found to be problematic and the Manufacturer recalls it, then you should be able to see which Items you still have that are from this batch number, and which Items may be have been dispensed and to whom, when, etc.

Although your Catalog will be set up for you during implementation of your system, you may from time to time have to make changes and or introduce new Catalog items. To make changes, i.e. update the Catalog, and to make new Catalog Items, you will use the same File Maintenance option. For an existing Item, you retrieve the Code (or use the lookup or search functions to retrieve it), change any fields as required, and choose SAVE. To make a new Catalog Item, you will simply choose a Code that is not yet in the Catalog, and then the system will know you are making a new item.

In the example shown below, we simply typed ‘new’ as a new code, and the system then offers any templates it currently has to choose from –

Once you select a Template, then the system will fill in most of the fields as pre-specified on the Template, and you just capture the remaining Fields. If there are no Templates, then you will have to capture all the fields yourself. Once all the mandatory Fields are satisfied, you may choose SAVE and then you have created a new Catalog Item.

All the Fields of the Retail Catalog (as for all screens in the system, in fact) have on-line help which may be initiated with F1, or clicking the Help icon, or clicking

Icon Functions and choosing Help. You can also read more about managing your Catalog in the Retail User Manuals.

Enquiries

The Medical system also offers enquiry equivalents for most of the Update screens offered on the Master Files function. Enquiries are often used by Users who do not have access to the UPDATE options, i.e. are allowed to look at information without being allowed to change the information. In the Medical system, there is no specific menu for enquiries, but whenever a User chooses a Master File option to which he / she does not have UPDATE access, then the system will automatically offer an enquiry, i.e. if he / she has access to that.