This section contains information on various concepts used in OpenVPMS. It is also functionally a glossary of terms used in the system.
The sub-sections are ordered aphabetically.
OpenVPMS includes only enough financial processing as is necessary. Whilst it keeps track of invoices, payments etc for the veterinary side of the business, it does not keep full track of your bank accounts. Hence you will almost certainly need to run a separate accounting system.
However, since it does handle all the customer and supplier invoicing and payments, there is no need to export the detailed invoice and payment information to your accounting system. Your accountant should be quite content with the data from the Bank Deposit Report. (This shows the total of the cash and all the detail of the EFT, credit card, and cheque payments.)
On the supplier side, since you need to make payments to the suppliers, you will need to enter the individual supplier invoices into your accounting system so that they can be paid and it can track the payments. However, you can omit the line item detail because OpenVPMS will handle this as it tracks the orders and deliveries.
The Accounting Cycle
Typically this proceeds as follows:
Note that the system does not support multiple accounting periods. That is, you cannot have a group of customers with monthly accounts and another with quarterly accounts.
Period End Processing & Statement Generation
These two facilities (invoked using the Reporting|Debtors screen) look at all or selected customer accounts and do as follows:
Payments and Invoices
Since the system allows you to receive payment for an invoice after it is finalised, there is a tendency to think that the system marks indivual invoices as being paid. This is not the case: payments are applied to all outstanding invoices, starting with the oldest and allocating the payment to each one until all of the payment amount has been allocated. This follows standard accounting practice.
Thus consider a customer with an invoice for $100 and an account balance of $100. If we now create a new invoice for $150 and the customer pays $150, then when the $150 invoice is printed, it will show the Amount Paid as $50 (because $100 got used to pay the older $100 invoice) and the account balance will now be $100 (ie $100+$150-$150).
Error Correction
The system has a concept of 'finalising' transactions so that they cannot be altered. To correct a finalised transaction (for example to change the payment type on a payment), you have to Reverse the erroneous transaction (which creates a reversing transaction match the reversed one) and then enter a new one containing the correct data. This reversal facility is only available to users who are categorised as Administrators.
Hidden Transactions
In many cases the above correction procedure can be safely hidden from the customer. That is rather than the statement showing the original erroneous transaction, its reversal and the new correct transaction, the system allows the first two to be hidden so that the statement shows only the correct transaction.
This hiding of the erroneous transaction and its reversal is only possible when correcting a transaction in the current accounting period (ie since the last Opening Balance transaction). If you reverse an earlier transaction then the hide flag will not be set for either of the reversed and reversing transactions.
For administrators, the Customers|Account screen has a Hide and Unhide button so that, if necessary one can adjust the hide flag for individual transactions. This needs to be used with care so the statement appear correct in the sum of all the amount shown matches the outstanding balance, ie that all the hidden transactions balance one another out.
Transaction Dates
When a transaction is created, it is timestamped with the current date (and time). When it is finalised, the timestamp is updated. This ensures that the account's finalised transactions are in the proper order for statements and balance calculations. Note that transactions that have line items (such as invoices) then the line item timestamps are not updated at finalisation time and will retain their initial value.
We need to keep old items (customers, patients, products etc) in the system, but we want to be able to ignore these most of the time.
For example, if a given product is no longer used, we can't just delete it, because there will be other references to this product recording its use. In fact, a good working rule is 'NEVER DELETE ANYTHING'. Essentially the only time you should be deleting things is immediately after you created them and you made an error creating them. [A good example is creating a new product with the wrong type, ie you set it as merchandise rather than medication. You can't change the type, so you have to delete and re-create the product.]
To suppress unwanted items you deactivate them by un-ticking their 'Active' checkbox.
If you need to find deactivated items, just set the 'Active' pull-down to 'No' or 'Both' on the search screen.
The system is designed to handle location addresses in a structured manner, ie one or more address lines, a suburb, a postcode, and a state. Note however that you do not explicitly set the country - although this is implicit in the state (since each is associated with a country).
If you have to hold addresses in different countries, there are two possible approaches:
The second approach will potentially result in a long list of states (since it will include those from all countries). Hence the best approach is probably the first.
Alerts can be set for both customers and patients. A common usage of alerts is to flag important customers, bad debtors, aggressive patients, and patient allergies.
Alerts can be given a reason, an end date and notes.
Alerts can also be displayed for all customers of a given Account Type.
Customer alerts display in the left panel when the customer is displayed, and similarly for the patient alerts. Once the end date of an alert has passed, the alert is no longer displayed in the left panel. On the Workflow - Scheduling and Worklist screens, if you select an appointment or task the customer & patient's summary information is shown in the left panel and this shows the alerts as in the snippet shown on the left. The administrator creates the available alerts with different ones for customers and patients. (Hence if you want an Aggressive alert that can be shown for both patients and customers, then the administrator needs to create one for customers and and one for patients.)
|
Alerts can be flagged as being Mandatory Alerts. These require users to acknowledge them if a customer or patient is selected that has the alert.
Mandatory alerts will be displayed:
Mandatory alerts only require acknowledgement once in a 24 hour period.
Note that acknowledgement is managed at a user level, so if a practice uses shared logins, mandatory alerts are less effective. This is because the first user session sees the mandatory alert, and subsequent sessions don't.
The system supports the use of barcodes so that you can use a barcode scanner to quickly and accurately enter product identification.
That is, instead of entering 'Advantix X Large Dog 3 Pack (25Kg+)' (probably by keying 'adv' then pressing Enter and then selecting from the long list of Advantix products), you can use the scanner to enter its barcode, and this will be used to find the product.
To get this to work, you need to enter the barcodes as product identities for each of the products that you want to be able to scan, and the scanner will be really useful when you enter this data as it saves keying the 12 digit number.
What is actually happening is as follows: if you enter a product (say on an invoice) as a number, then the system does an identity search of the products for that number, and if it finds only one, then it uses that product, otherwise it displays the select screen.
Note that there is no reason why you should not 'barcode' your own products and services. There are free programs available that will generate the required graphics, and you could print up a page listing these and keep it near the work station so that scanning calls up 'Consultation (9pm-Midnight)'.
A final warning: if you do use your own barcodes, make them long. As explained in identities, the IDs are also searched, so a barcode of 123 will find any IDs starting 123.
OpenVPMS allows you to categorise and classify products, customers and suppliers. You don't have to use these, and the system does not require them to be set up. They are simply to enable you to report on breakdowns of categories and classifications.
For each, the available values are set via the Administration|Lookups facility. The following table gives the name of the lookup for each classification and category.
Classification/Category | Lookup |
---|---|
Product Classification |
Product Group Product Income Type |
Customer Category | Customer Type |
Supplier - Organisation Category |
Supplier Type Supplier Account Type |
Supplier - Person Category | Supplier Type |
Supplier - Veterinary Practice Category | Practice Type |
Supplier - Veterinarian Category | Veterinary Specialty |
User Category | User Type |
Customers, Suppliers, Users, Practice Locations, and the Practice itself all can all have 'Contacts' defined.
The screen shots below are taken from the Customer Edit screen (and hence the other tabs).
There are three types: Email, Location, and Phone. See also Fax Contacts. The entity can have zero, one or more of each type of contact. Each contact can be set as the default contact for each type, and each can be given 'purposes'.
The available purposes are set via Administration|Lookups|Contact Purpose. Each contact can have zero, one or more purposes. In general these are just for information purposes. However, in two cases they are very important. As discussed in Reporting|Reminders, the system looks for a contact with the purpose 'Reminder' in order to decide how to send out reminders. Similarly, as discussed in Reporting|Debtors, the system looks for an email contact with the purpose 'Billing', and if found emails the customer's statement rather than printing it.
To set the purpose(s) use the arrows to move the selected item from the Available list to the Selected list and vice versa.
The fields are as follows:
Name - this is the 'name' of the contact - by default it is set as per the following table. However, you can set it to anything useful - for example 'Eastside Vets (Accounts Dept)'. Note that email addresses created in versions prior to 1.8 will have 'Email Address' as the default name - but when the email address is used 'Email Address' will be replaced by the default shown in the table below.
Entity | Default Email Contact Name |
---|---|
Customer | Company Name if set; else firstName lastName if both set (eg Joe Bloggs); else lastName |
Supplier (Organisation) | Company Name |
Supplier (Person) | firstName lastName (eg Joe Bloggs) |
Veterinarian | firstName lastName (eg Joe Bloggs) |
Veterinary Practice | Practice Name |
User | user’s Full Name |
Practice | Practice Name |
Practice Location | Location Name |
Email Address - the email address - note that this is checked to have a valid format, but not to see if it exists - if it does not exist then you won't know until an email that you send to the address results in a failure message to the sender
Preferred - check this box if this is the preferred email address. See also below.
The fields are as follows:
Name - this is the 'name' of the contact - by default it is set to 'Location' but you can modify it to anything more useful
Address - as discussed in Concepts|Addresses this can either be the address lines (not including the suburb etc) or a complete address including the country
Suburb - choose the suburb from the pull-down list - those available are set via Administration|Lookups|Suburb. For international addresses, use 'None'.
Postcode - enter the postcode/zip code
State - choose the state from the pull-down list - those available are set via Administration|Lookups|State. For international addresses, use 'None'.
Preferred - check this box if this is the preferred location. See also below.
The fields are as follows:
Name - this is the 'name' of the contact - by default it is set to 'Phone Number' but you can modify it to anything more useful
Area Code - the area code part of the phone number
Telephone Number - the phone number
Preferred - check this box if this is the preferred phone number. See also below.
Allow SMS - check this box if SMS is possible via this number. Note that if you flag multiple numbers as SMS capable, then when you send a SMS, there will be a pull-down list to select the required number.
For Fax contacts:
Note that the system cannot send faxes - this information is just for documentation purposes.
As from release 1.8, fax contacts are held as Phone Contacts with purpose Fax.
Note also that there are service providers who allow you to send them an email which will be sent on to a fax number. Typically you send the email to 98765432[at]efaxes[dot]com and they send a fax to the number 98765432. If you will be using a service like this, you will need to set the 'fax contact' as an Email Contact.
Preferred Contacts
The first contact of given type that is created will be set as Preferred. When you add another contact of the same type, then by default its Preferred box will not be ticked. However, if you do set this as the new Preferred contact of this type, then the previous contact that was the preferred one will become un-preferred - ie there can only ever be one preferred contact of each type.
Departments represent areas of a practice (e.g. Consulting, Surgery, Emergency) and are used to:
There may be any number of Departments; these are independent of practice Locations.
To use Departments, support need to be enabled on the Practice by selecting the Enable Departments option. When enabled, the current Department will be shown at the top-right of the screen, next to the practice Location.
Departments may be viewed and edited in Administration - Organisation.
By default, users can select from all Departments. To restrict this, assign the Departments a user can select from on their Departments tab.
Each charge item may be assigned a Department. This defaults to the current Department.
If there is a service ratio associated with the Department, this determines the price of the product.
Department Service Ratios can be used to apply a multiplier to prices for products of a given product type for a Department. They can also have a calendar, to determine when the multiplier applies.
The multiplier is used when generating charges. This facility is designed to enable:
Department Service Ratios are similar to Location Service Ratios except they provide finer control over pricing. Department Service Ratios take precedence over Location Service Ratios.
The Deposit Accounts represent the actual bank accounts that you deposit money into. Each location can have its own account(s) or the accounts can be shared between locations.
Note that these Deposit Accounts are not like the bank accounts in your accounting system - ie they do not hold all the account transactions and you don't reconcile them. The Deposit Account record simply holds sufficient information to print deposit slips.
The only time you need the deposit account is when you use the Reporting|Deposit screen after having cleared the till.
The deposit accounts are set up by your administrator using Administration|Organisation|Deposit Account
There is an extensive discount system. Discounts can be provided at the customer, patient, and product level. You can also give a discount at payment time, and disable discounts entirely.
Discount Types
The Administrator defines the various Discount Types using Administration|Types|Discount. For each (eg Staff Discount, Valued Customer, ...) they define the type (percentage or fixed or at-cost), the rate, and whether the discount applies to the fixed component of the product price as well as the unit component.
One or more discount types can be included in a Discount Type Group (see Administration|Types|Discount Group) in which a start & end date can be specified for each Discount Type.
Customers and Patients
For each customer and each patient you can define what discount types and/or discount type groups they have, and their start/end dates.
Products
For each product you can define what discount types apply to the product and their start/end dates. However, since you can specify discounts for each product type (see Administration|Types|Product Type), it is normal to set the discounts at the type level rather than for each individual product. If there are discounts on both the product and type, then they will be merged. If a discount appears on both a product and its type, it will only be applied once.
Calculation
When the charge is calculated, the only discounts that apply are those that are common to both product and customer/patient.
Hence if the customer has a staff discount, but the product they are buying has no staff discount, then they don't get the discount.
If the same discount has been set for both the customer and the patient, then the discount is only applied once.
However, if there are different discounts set (eg Valued Client for the customer, and Blood Donor for the patient) then both apply (provided that the product has both set).
If there are multiple At-cost discounts, then the one with the lowest rate is selected, as that gives the greatest discount. If there are other discounts as well, these will also be applied.
If the discount resulting from all the applicable discounts exceeds the maximum discount set for the product, then the maximum discount is used. If you want to use At-cost discounts for your staff (say 5%), you must be careful to set the product's maximum discount to allow this. The formula
D = (M-R)/(100+M)
gives the discount percentage D where M is the Markup percentage and R the At-Cost discount percentage. Hence for M=100 and R=5, then D=47.5.
Hence setting the product's maximum discount to less than this, say 30% will result in the staff paying more than cost+5%. For them to pay cost+5%, you need to set the maximum discount to 47.5% or more.
If the calculated discount is such as to reduce the price below the cost price, then unless:
a) there is both a fixed and unit price, and both have a 100% maximum discount
or b) there is only a fixed or unit price, and it has a 100% maximum discount
the following warning will be displayed:
Clicking Yes will set the discount amount to 0.
Note that all the above logic simply calculates and displays the applicable discount. The user creating the invoice/charge can override the calculated discount.
Quantity Breaks
These are not currently supported by the system. There is a proposed design for them, but it's not a currently funded project.
Payment Discounts
You can give a discount at payment time. When the payment is being entered, select a payment type of 'Discount' and enter the discount amount. Thus if the customer is paying $1234, this can be 'paid' by a $1000 cheque and a $234 discount. The Till Balance report will show these discount payments and their total.
Discounts can be disabled by selecting the Disable Discounts flag on the Practice Location.
See Reports, Forms, Letters and Documents for background. See Reference|Reports and Documents if you need to build reports and documents.
The system has the ability to store documents for patients, customers and suppliers.
Products and emails can also have documents attached - see here and here respectively.
First a word on 'document templates' - as described here, these control things like what the document contains, and how and where to print it. Each template has a 'type' and this defines how information is provided when the document itself is generated using the template. Thus a 'Patient Form' is provided with information about the current patient, a 'Customer Form' is provided with information about the current customer, etc.
For patients, customers and suppliers, there are three types of documents as follows:
Attachments - these can be uploaded from any file that you have access to. They can be pdf files, word processing documents or spreadsheets, or plain text document - anything. They can also be image files - so you can keep a photo of each of your customers etc if you want. Note however, that for patients, there is a specific image facility to add images.
Forms - these are things that are based on document templates of type Patient Form, Customer Form, or Supplier Form depending on whether you are attaching the form to a patient, customer or supplier. As part of the process of creating the attached form, the template will be used to generate the form with the appropriate patient/customer/supplier details inserted, and this is stored.
Letters - these are things that are normally based on document templates of type Patient Letter, Customer Letter, or Supplier Letter depending on whether you are attaching the letter to a patient, customer or supplier. As part of the process of creating the attached letter, the template will be used to generate the letter with the appropriate patient/customer/supplier details inserted, and this is stored. However, the template used is also stored. For both the generated letter and template, the system stores the actual word processing document and a pdf that can be used to print it. Hence for letters, you can either print another copy of the letter, or download the word processing document and edit this to make changes to the letter.
However, you can also bypass the use of the document template, and upload any file just as you can with an attachment. The downside is that you are bypassing the template's ability to insert the customer's/patient's/supplier's details into the document. The upside is that anything you upload is classed as a letter - even if it is the scanned image of something that you typed up and signed, or even hand wrote.
Note that for all three types:
Patient documents also include Images and Investigations. Images work in exactly the same way as Attachments (and in fact you can happily add a text or pdf file as an 'image'). Images are simply there to allow you to logically separate them from other sorts of attachments.
Investigations are also like Attachments in the sense that any sort of file can be attached as the Investigation 'Report'. However, as discussed in Concepts|Investigations, there is built-in support for tracking the status of the investigation and automatically attaching the report files to the Investigation record.
OpenOffice and Microsoft Word documents stored in OpenVPMS can be edited. An External Edit button is provided to launch OpenOffice for the selected document in:
You can attach documents to a product. Here you are not attaching an attachment, form or letter, but instead a document template. When you use the product (ie call it up in an invoice) then the required document will be generated from the template and can be printed etc. The obvious use is to attach a vaccination certificate to a vaccination product. Note that because what you have attached is the template (and not the actual certificate) the generated certificate can include the patient and product details.
Emails
You can attach two sorts of things to emails: files and documents. Files are any files that you can access on your workstation, documents are customer, patient and supplier documents stored for the current customer/patient/supplier.
ESCI stands for e-Supply Chain Interface - it is a facility for automating the orders/deliveries/invoices dialog between the practice and its suppliers.
You don't have to use it, and it requires setting up at both the OpenVPMS and supplier ends. Both Lyppards and Provet in Australia have implemented their parts.
To quote from the documentation:
The OpenVPMS ESCI (e-Supply Chain Interface) is a standards-based API to enable OpenVPMS to electronically place orders on suppliers and to receive order responses and invoices from suppliers . It is based on the exchange of Universal Business Language (UBL) 2.0 documents via web services.
ESCI defines a number of web services which are implemented by the supplier, namely:
It works as follows:
If you are going to set up ESCI, then this link provides useful information.
If you make an error entering data you will get an error screen like the one below. (Here we have omitted to enter the product - a mandatory entry.) You will see at times, that you could have suggested a better message like 'Please select the product - you must have one'. The messages are generated automatically and are not all individually created. However, you will always be able to understand what the problem is. Simply click OK and try again.
If an internal error occurs you will get screen like the one below. Note the extra 'Report Error' button. This indicates that the problem should not have occurred and perhaps should be reported to OpenVPMS. If you do not want to report it, simply click OK.
If you click the Report Error button, then the screen below will appear.
The email address defaults to that for the Practice. If desired you can change this - say to that of a technical staff person. You are encourgaged to provide an email address, but if you really want to send in an anonymous report, then you can untick the 'Include my email' checkbox.
Press the Send Error Report button to send the report, otherwise use Don't Send. If you click the blue 'click here' link a screen like the one below will appear. If you are not a programmer, it's gobbledygook, if you are it's useful.
Note:
An 'estimate' is a quotation for work to be done and/or goods to be provided. You create and manage estimates using the Customer|Estimates screen. You can also access the estimates for the current patient on the Estimates Tab of the Visit Editor.
On the estimate you can provide, for each line item, an estimate of the fixed price and low and high limits for the unit prices and quantities.
The estimate can be printed and given to the customer. It can also be used to create the invoice for the services and goods quoted for.
By default, estimates expire after 30 days. This can be changed via the Estimate Expiry interval for the practice using Administration|Organisation|Practice.
The External Edit facility allows users to edit OpenOffice or Word documents linked to OpenVPMS records, using OpenOffice. The document is edited in place; there is no need to download it first to edit it.
An External Edit button will be displayed for records with an editable document if they are:
In order to use External Edit, the following must be installed on the user's computer:
When launching External Edit, the browser will display a dialog like:
Allow this site to open the jnlp link with Launcher for .jnlp
applications according to JRS-56?
[ ] Always allow <site> to open jnlp links
Click Open Link to launch External Edit, which will start OpenOffice with the document to edit.
On the first launch, OpenWebStart will download supporting libraries before OpenOffice starts.
Check the OpenWebStart logs. The location of these can be determined by running the OpenWebStart Settings application.
Health Level Seven (HL7) is a set of standards for Healthcare Data Interchange and Interoperability.
OpenVPMS can send and receive HL7 2.5 messages for select events as follows, using the MLLP protocol.
Patient admission, discharge and update messages are can be sent to registered Patient Event Services and Pharmacies.
See HL7 Patient Administration Messages for a list of messages sent and the events that trigger them.
Pharmacy orders can be be placed with external pharmacies during invoicing, using the HL7 RDE O11 message type.
Orders are placed for products or product types that specify a Pharmacy or Pharmacy Group.
Pharmacy dispense messages (i.e. HL7 RDS O13 messages) can be received from external pharmacies. These are used to create Pharmacy Orders or Pharmacy Returns, which may be automatically invoiced during charging, or via Workflow - Customer Orders.
See HL7 Pharmacy Messages for the supported messages, and the events that trigger them.
For instructions on configuring OpenVPMS to interface with a pharmacy, see How To - HL7 Pharmacies
Laboratory orders can be be placed with external laboratories during invoicing, using the HL7 ORM O01 message type.
Orders are placed for investigations with Investigation Types that specify a Universal Service Identifier and a Laboratory or Laboratory Group
Order cancellation messages (i.e. HL7 ORM O01 messages with CA for ORC-1 - Order Control) can be received from external laboratories. These are used to create Laboratory Returns, which may be automatically invoiced during charging, or via Workflow - Customer Orders.
See HL7 Laboratory Messages for the supported messages, and the events that trigger them.
For instructions on configuring OpenVPMS to interface with a laboratory, see How To - HL7 Laboratories
Almost everything in OpenVPMS has an 'ID'. This is simply a number and it is unique - ie if there is a customer with ID 1234, then there cannot be a patient with ID 1234. Most of the time you don't need the ID. However, it can be useful in identifying the exact patient, customer etc, and hence it is normally printed on things like invoices. Thus if there are two Mr Smith's each with a dog called Rover, the ID will identify which Mr Smith and which Rover.
An Identity search includes a search of IDs. Thus, when you search for say a customer with an Identity 1234, those found will include those with ID's starting 1234.
Although almost everything has an ID, the ID is normally not displayed unless there is a mechanism to search for it. Thus it is displayed on the on the customer, patient and supplier information screens, but not on the Workflow|Scheduling screen - although each appointment does have an ID.
A number of things such as customers, patients and products can be given 'identities'. There are a number of different types of identities such as Alias, Microchip, Barcode, etc. These are essentially just different ways of identifying the item.
The select screens, where applicable, allow you to search by identity. Note that when doing so you are not able to search a specific type of identity, the search is done across all identities as well as the IDs.
Hence searching patients for the identity '123' will return any that have microchips, pet tags, aliases, or IDs starting 123.
OpenVPMS can:
PetSure VetHub provides online claims support.
This:
See Online insurance claims with PetSure VetHub for more details.
Claims can be submitted via email. The email will contain:
Claims can be printed, for insurers that don't support online submission.
For insurers that receive claim via email or post, OpenVPMS includes a default insurance claim form.
For insurers that have specific form requirements, the Insurer has a Claim Form field. This should be assigned a Document Template with Type set to Insurance Claim - Custom.
For an example template, see the default claim form at: <OPENVPMS_HOME>/reports/Patient/Insurance/A4/Insurance Claim.jrxml
Investigations are any internal or external clinical test or procedure. The facilities to support these are as follows:
The tools to set up and use investigations are:
Each investigation has a Status - one of:
Each investigation has an Order Status - one of:
For online orders, the Order Status is set by the laboratory.
For manual orders, they can be set by the user.
The information presented here is generally applicable but does not include conventions and procedures used in your own local practice.
If your practice does have specific ways of doing things, your administrator may have created local documentation that can be accessed via a bookmark or other mechanism such as the Help item in the top menu of the OpenVPMS screen. (See here for how to set this up.)
Macros are similar to the "auto correct" facility in Microsoft Word where a small string of text can be expanded into a sentence or even paragraphs of text. The macros can also be set up to use the prefixed number, eg so that 5@w expands to 'for 5 weeks'. They can also be set up to include relevant data like the customer's name so that @dear expands to 'Dear Joanna' (assuming that the current customer's first name is Joanna). Finally it is possible to call a report to generate text for things like a referral email that includes the patient's medical history.
Macros can be used in any text field. Note however that certain macros will be context dependent. For example, the @bid macro is designed for use when creating a Dispensing Label and uses information from the product record. If you use @bid when there is no current product, then the macro simply will not expand and the '3@bid' that you typed will be left unaltered.
You don't need to remember the macros, pressing Alt-M will display a Macro Select screen like that shown below. You can simply click on the macro you want to invoke it.
Note that the search facility searches both the code of the macros and their names. Hence entering say 'dg' will find all macros with code starting 'dg' and all macros whose name starts 'dg'.
The macros are set up by your administrator using the Administration|Lookups|Macro and Administration|Lookups|Report Macro facilities.
Macros can include {__} tokens that indicate text that needs to be replaced by the user. Pressing:
This allows users to progressively fill in text. E.g. a macro could generate:
Reason: {__} History: {__} Current medications: {__} What Preventative health cover is being used and do you need to purchase any today? {__} Vaccination: {__} Worming: {__} Flea control: {__} Heartworm Prevention: {__} Examine: {__} Mentation: {__} Body condition score: {__} MM: {__} CRT: {__} HR: {__} RR: {__} LN: {__} Temperature: {__}
NOTE: this facility is not supported in the Mail editor.
Patient medical records are automatically locked to prevent them being edited, after a period of time.
Once locked, a record may not be not edited nor deleted except in specific circumstances - see Exceptions below.
The following records support locking:
Medical record locking is enabled by the practice level configuration option Record Lock Period. This defaults to 24 hours. If set to zero, locking is disabled.
Medical records are locked by setting their status to Finalised. This is done automatically by a background task that runs periodically to set the status on all In Progress or Completed medical records with:
Start Time < now - period
where:
There are a number of exceptions to the locking rule:
To support changes to Notes and Medication records that have been locked, an Addendum record can be added. This is displayed after the record in the history that it annotates
A record can have multiple Addendum records. They are displayed in increasing chronological order e.g.
20/10/2015 - Consultation - J Smith [Completed] (8 years) 20/10/2015 Note J Smith S: P presents for a 5-6 day history of rear limb weakness and crying out in pain in the mornings. O: PE unremarkable. A: Differentials: IVDD, vascular event, etc P: Treat symptomatically for now with prednisone and methocarbamol. 23/10/2015 Addendum A Bern Above note was saved incomplete: O has tramadol at home and told o to continue to give tramadol for the next 5-7 days. Recheck in 7-10 days if does not resolve. 24/10/2015 Addendum A Bern Another addendum to the note 20/10/2015 Medication J Smith Amoxil Tablets 200mg Qty: 1
An Addendum may only be created if the selected record is a Note or Medication. Adding an Addendum to another Addendum is not supported as it may make the chronology unclear.
The ability to enable or disable locking is available to administrators. A new Audit Message will be logged to Workflow - Messaging when locking is changed. e.g.
1/10/2015 10:00 - Medical Record Locking Interval set to 1 week by admin
or:
1/10/2015 10:32 - Medical Record Locking was disabled by admin
This message may be read, but not deleted.
Investigations need to support some updates after they have been locked:
All other fields are read-only.
Prior to editing an In Progress medical record, a check is performed to ensure that it may still be edited based on the locking criteria. This is required as the background task may not have got round to change its status to Finalised.
The system includes a simple messaging system that enables messages to be sent to other users and user-groups. You can reply to and forward messages. When initially received, the message is flagged as pending. After it's read by the addressee it is flagged as read. When a message is finished with, you can either delete it completely or flag it as complete.
There are two types of messages, user and system. System messages are those used by scheduled processes to notify of status updates or errors. (Currently only the ESCI system generates system messages.)
Note that the messaging system is very simple. Specifically:
Global ToDo list: Because messages are not private, you can set up a global todo list. The administrator creates a user called ToDo (with a password known only to the administrator so that nobody can login as ToDo). Messages sent to ToDo can be seen by everyone, and individuals can respond to and delete these messages. Thus we have a public todo notice board. You could also create a Work List for this 'todo' function but there is the benefit of being able to easily reply to or forward the messages.
Administrators note: since Message Delete is a specific 'authority' it is possible to block the deletion of message by specific users if you want them to only be able to set complete status when a message is finished with, rather than deleting it.
Almost everthing (ie customers, patients, products, reports, etc) has a name. The names do not have to be unique - this is obvious for things like patients (where there are likely to be many Rovers, Busters and Scruffys) but less obvious with things like reports.
Everything has an ID and this is unique. Hence the system can quite happily handle two products named 'Best Dog Biscuits', or two reports named 'Stock Listing', but users will get confused.
Hence it is best to use unique names where appropriate.
Over The Counter (OTC) transactions are used to perform sales where no customer and no patient is to be recorded. There is an OTC button on both the Workflow|Scheduling and Workflow|Work Lists screens. This allows reception staff to quickly make OTC sales.
There is normally one OTC account per Practice Location - though it is possible for multiple locations to share the same OTC account. They are set up using the Administration|Organisation|OTC facility.
The OTC account is effectively a special customer account where the customer is anonymous.
Note that there is also a concept of a 'Counter Sale' to a given customer (accessed via Customer|Charges|New|Counter Sale) where the customer is recorded but there is no patient recorded. If you need the patient recorded, then you use Customer|Charges|New|Invoice.
As indicated above, the OTC account is a special customer account. If you call up the Customers|Charges or Customers|Account screen and then press the Select button, you will find that there is a Type pull-down - see below. Choosing OTC will allow you to access the account.
The Customer|Account screen - see below - is the most useful. Most of the time, the only OTC transaction you need is the sale - accessed using the OTC button of the Scheduling and Work List screens. However, if you need to reverse the transaction or print the payment receipt again, this is where you come. It works in exactly the same way as the Customers|Account screen for a normal customer.
The system allows for customer payments by the following methods:
You can also include a discount at payment time. ie the amount payable is $100 and this is paid by $80 credit card payment plus a $20 discount.
One payment can also consist of multiple types, ie $100.75 can be paid by a $100 cheque and 0.75 cents cash.
The system also supports a payment type of 'Other', and Administration|Lookups|Custom Payment Type is used to define these.
The system also support payments by BPAY (an Australian payment portal) in that a facility is provided to generate the required Customer Reference Number to be shown on the invoice.
OpenVPMS structures the business as consisting of a single 'practice' with one or more 'practice locations'. These locations may represent branches at different addresses, or another component of the business (eg the after hours clinic) that operates at the same address.
It is normal (but not mandatory) to have different tills, bank and OTC accounts, and stock locations for each practice location.
The currently selected Practice Location (shown at the top right of the screen) is used as follows:
There is no concept of customers (and their patients) 'belonging' to a practice location. That is, a patient can 'visit' any practice location. However, it is possible to set a preferred Practice Location for each customer. This is used as follows:
By default all products are available at all locations. However, it is possible to limit what products are available at each location - see here.
OpenVPMS provides support for managing and using prescriptions. The features are as follows:
As indicated above, you do need to set the Prescription Expiry interval for the practice using Administration|Organisation|Practice.
OpenVPMS has a powerful and flexible product pricing system.
Products have two components to their price:
Fixed - this is the fixed component - it is effectively the 'flag fall'
Unit - this is the 'per item' component
Hence if something has a fixed price of $10 and a unit price of $1, then the total price for 4 is $14.
In general things that have no overhead such as cans of food will have no fixed price, and only a unit price. Things that have an overhead - such as tablets where you want to charge a dispensing fee as well as the per-tablet price, will have a fixed price representing the dispensing fee and a unit price for the tablet. You can also use this approach for services, where you might want to set a fixed price for some surgery, and a unit price that represents the per-hour charge for the theatre time. [Note that an alterative to this appoach is to have mutiple fixed prices - see below - so that you have different prices for different length operations.]
Fixed and unit prices may be entered both exclusive and inclusive of tax.
The exclusive tax price is stored, whilst the inclusive tax price is calculated from the tax-exclusive price and the tax rates associated with the product, product type or practice.
The practice Show Prices Tax Inclusive option determines if fixed and unit prices in Products - Information and during product selection should be displayed inclusive or exclusive of tax.
When setting the price, you can provide:
The Cost and tax-exclusive Price can be expressed to 3 decimal places; the tax-inclusive price is rounded according to Price Rounding below.
Prices also have from/to applicability dates. This allows you to keep previous prices for reference purposes. It also allows you to set future prices, ie one that will take effect on some future date.
A product can have its price set from a 'price template'. This allows the Fixed price component of a number of products to be set from a standard value.
It is possible to set multiple fixed prices for a product, each with its own name. When the product is called up when generating an invoice, the fixed price field will have a pull-down which can be used to show the available prices (with their names) as follows. Note that here the 150/medium price has been set as the default and so is initially displayed.
Service Ratios can be used to apply a multiplier to prices for products of a given product type at a given Practice Location or Department. They can also have a calendar, to determine when the multiplier applies.
The multiplier is used when generating charges or estimates. This facility is designed to enable:
Department service ratios take precedence over Location service ratios, where both are defined.
1. Out of hours surgery
To charge surgery services at 150% outside of 7am and 7pm, and on weekends, at Clinic A:
2. Regular promotions
Promotions are typically handled via product discounts, but if you wish to promote a product or service on a particular day or time, a service ratio might be simpler.
E.g. to charge grooming services at 50% on Wednesdays between 10am and 2pm in August at Clinic A:
Prices can be assigned Pricing Groups to enable different pricing for a product at different Practice Locations. If a Practice Location is assigned a Pricing Group, it only sees the Prices that have:
To use Pricing Groups:
Pricing Groups are similar to Service Ratios in that they both support different prices for a product at different Practice Locations. Whilst Service Ratios are simpler to set up, Pricing Groups enable:
Tax-inclusive prices are rounded to the default number of decimal places for the currency.
This can be changed by specifying a Minimum Price on the practice Currency.
The practice currency can be selected in Adminstration>Organisation>Practice.
The currency is a lookup, the rounding can be changed by editing the lookup in Administration>Lookups
E.g., to round prices to the nearest 5 cents, specify 0.05 for the Minimum Price.
Tax-inclusive prices will be rounded to the Minimum Price:
Note that the Markup and Max Discount may be recalculated after the price is rounded.
Tax-inclusive prices will not be rounded to the Minimum Price:
You can set as price as a negative amount - although this is not really kosher. Negative prices are used with a product that is in fact a discount. This enables you to have a discount line item on the invoice. For the standard way to apply discounts, see Concepts|Discounts.
Prices in OpenVPMS can be updated:
To update a large set of prices, the latter is the preferred approach. The process is as follows:
Note that the format of the CSV file being imported must match that exported. You cannot have extra columns (such as 'Old Fixed Price') and the column headers must match.
A relatively simple way to achieve this is to copy all the data to a second sheet (called say Sheet1). On the top sheet you can then replace the original data by formulas where you want to do updates. Thus inserting the formula:
=IF(Sheet1!E2>0,ROUND(Sheet1!E2*1.2,2),"")
in cell E2 of the top sheet and then copying this to all cells below it in the E column will:
where there is an existing fixed price.
You then save the top sheet in CSV format and import that.
This technique can be used to both create and update prices. To maintain a price history, it is recommended to create new prices.
To create new fixed prices:
1. Clear the Fixed Price Id column contents
Clear the D column, starting in cell D2. This ensures that new fixed prices are created rather than updating existing fixed prices.
2. Change the Fixed Price column
E.g. to increase fixed prices by 50%, add the following to the E2 cell, and copy to the remaining E column cells:
=IF(Sheet1!E2>0,ROUND(Sheet1!E2*1.5,2),"")
3. Change the Fixed Price Start Date column
The prices should be given a new start date, so that they don't overlap existing fixed prices. The existing fixed prices will have their To Date set to the Fixed Start Date with time 00:00:00. Thus if the new start date is 2/May/17, the old price will apply until midnight on 1/May/17, and the new price will apply from 00:00:00 on 2/May/17.
E.g. to date the prices 30 days from the existing prices. add the following to the H2 cell, and copy to the remaining H column cells.
=IF(Sheet1!H2>0,Sheet1!H2+30,"")
The Default Fixed Price column can be used to specify if a fixed price is the default price. This only applies if multiple fixed prices are active for a product at a given time. Valid values are false and true.
To update fixed prices, retain the Fixed Price Id column contents, and change the Fixed Price, Fixed Cost, Fixed Price Start Date, Fixed Price End Date and Default Fixed Price columns as required.
To create new unit prices:
1. Clear the Unit Price Id column contents
Clear the L column, starting in cell L2. This ensures that new unit prices are created rather than updating existing unit prices.
2. Change the Unit Price column
E.g. to increase unit prices by 50%, add the following to the M2 cell, and copy to the remaining M column cells:
=IF(Sheet1!M2>0,ROUND(Sheet1!M2*1.2,2),"")
3. Change the Unit Price Start Date column
The prices should be given a new start date, so that they don't overlap existing fixed prices. The existing unit prices will have their To Date set to the Fixed Start Date with time 00:00:00. Thus if the new start date is 2/May/17, the old price will apply until midnight on 1/May/17, and the new price will apply from 00:00:00 on 2/May/17.
E.g. to date the prices 30 days from the existing prices. add the following to the P2 cell, and copy to the remaining P column cells.
=IF(Sheet1!P2>0,Sheet1!P2+30,"")
To update unit prices, retain the Unit Price Id column contents, and change the Unit Price, Unit Cost, Unit Price Start Date, and Unit Price End Date columns as required.
To change the Printed Name of a product, enter a value in the appropriate Product Printed Name cell.
Exported fixed prices can include prices linked from Product Price Templates if the "Include Linked Prices" option is selected when exporting prices.
Where this occurs, a warning will be displayed in the Notes column. E.g.:
Warning: fixed price is linked from Basic Surgery Fee (1047)
Linked prices cannot be updated via the product that links them; the Product Price Template must be updated instead.
If you are changing the price group or adding new prices with a price group, remember that the Price Group is specified by its code, not its actual name. For example, if its name is say 'Price Group 3' then its code will be PRICE_GROUP_3, and if you edit the price group to change its name to say 'Group 3', its code will remain unchanged. For this reason it is best to use the Export facility to export some prices with the relevant prices groups so that you can ascertain what the actual codes are.
The system is quite flexible when it comes to printing. The standard print request window enables you to print to any available printer, but also to email and preview the document. If you request a preview, the pdf file will be downloaded to your browser from where you can save it or print it.
For many documents, ie invoices, receipts, etc, the system maintains a 'Printed' flag. If set it means that someone has printed the item. However, note that previewing or emailing it does not count as printing.
The administrator can set a default printer for each practice location using Administration|Organisation|Practice Location.
It is also possible to set a default printer for each type of document. More correctly, you can specify the default printer for each document template - see Administration|Templates. You can also set the document to print to a specific printer without displaying the print request window. This is useful with dispensing labels where you always want these printed on the label printer rather than on a standard printer.
These templates also allow flexible control of when documents are printed - see the above link.
Note that these printers are the printers that are available to the server running the database and application. Unless you are running everything on your own machine, the server's printers may be different from your own. If the server has no printers then you can still print - a pdf will be generated and downloaded just as though you pressed the Preview button.
If you have a situation in which your office is split over two floors and you want different default label and standard printers for each floor, then you can accomplish this as follows:
Note that if you are using reports that report stuff by practice location, you will need to combine the the information for Main-Upstairs and Main-Downstairs in order to get the totals for the Main location.
The system provides the clinician with the ability to create a "Problem" in a patient's medical records, and then enter notes and medication against that problem.
The Problem can have a lifetime that spans multiple visits and provides a way of looking at the notes and medication related to the problem. When looking at the the Medical Records summary, the items belong to the problem will be spread throughout the medical history, however, by using the Problems tab, one can see all the items associated with the one problem gathered together.
Note however, that caution should be exercised if medication entries are made against the problem because these will not be charged for, ie no invoice line item will be created for the medication.
The problem has a status which is set to either Un-Resolved or Resolved.
Products that have limited lifetimes or warrant explicit usage tracking typically have batch identification and expiry dates.
Product batches can be tracked during charging and dispensing.
This can be used to:
Batches are created via the Product|Batches screen, or by finalising a delivery that contains batch information.
OpenVPMS has a number of ways of grouping or classifying products as follows:
Type of Product
There are five types of product as follows:
Service
|
These just have a name (and other optional attributes like prices, discounts, taxes etc etc). They are not stocked items and you cannot run out of them. Example: Consultation |
Merchandise |
Things that are sold and hence also have a Selling Unit (eg Box, Vial, Unit etc) and associated supplier details. Example: Dog Collar |
Medication |
In addition to the details held for Merchandise items, these can have drug labels, dispensing notes, a drug schedule and list of active ingredients. Example: Baytril Otic |
Product Price Template
|
These just have a name and a price and are used to set common pricing for a number of products (by linking the fixed price of the product to this template rather than setting its own). Example: Dispensing Fee - Standard |
Template |
These are used to group a number of products together. They are commonly used for procedures. When you use the template product when creating an invoice, it will be expanded into its component items. The template can include a note to be put on the invoice, and a note to be added to the patient's medical record. Hence, sometimes it is useful to have a template that includes only one product - because of this ability to automatically generate these notes. Product Templates:
Example: Cat Spay |
Note that some things that are logically services - eg cremations (and in fact any services that you offer which are in fact drawn from an outside supplier) need to be set as Merchandise so that you can record the supplier of that service.
Product Type
(Note that ‘Product Type’ is not the same as ‘Type of Product’.)
Each Service, Merchandise and Medication product can be set to be one of a number of Product Types. Examples might be: Administration, Anaesthesia, Consultation, Consumables, Desexing, Dental, etc. As well as enabling reporting by the sort of product, discounts can be set by product type. Also one can determine the appearance of invoices by the order in which items are shown and whether or not items of the same type are combined into one line item.
Product Classification
This is another method for grouping or selecting products for reporting purposes. Your administrator can set up Product Groups and Product Income Types, and you can set a product to belong to one or more of the classifications.
OpenVPMS has a powerful and flexible system for sending out reminders to clients that their animals are due for a vaccination, dental check, annual check, etc. Its features include:
Note that if you are interested in Appointment Reminders rather than Patient Reminders, see How To: Appointment Reminders
The tools to set up and use reminders are:
A reminder can be in one of 3 states as follows:
Each reminder will have one or more 'items', one for each method by which it will be sent out. For these, their states can be as follows:
For a full discussion of how reminders are processed, see Reporting|Reminders
There are various sorts of things that the system can generate for printing. They are as follows:
Reports - these are invoked for the Reporting|Reports screen. Typically a report has some input parameters (eg the from and to dates, the product type, etc). As well as printing the report, you can also generate a PDF file (which can bve previewed and sved, or emailed), or export the data for use in a spreadsheet. Reports can be give a 'level', and only users with a 'level' equal to above that will be able to run the report. A number of standard reports are included with the system distribution, more are available from the community resource. If you want/need to modify or create reports, this is possible but needs technical skills - see here.
Forms - these are what they sound like - forms that the system can generate that can include merged-in information about the current patient, customer or supplier. You can modify or create these with a standard word processor. See here for further information.
Letters - these are not quite what they sound like - in fact, they are just forms with input parameters. They are thus used where it is necessary to show information that is not available from the system. For example, if we have a 'Health Check for Purchase' form, then although the system can automatically fill in the patient details, comments on items like Eyes, Ears, Teeth & Mouth, Chest Auscultation, etc need to be provided by the vet. Rather than printing the form and then filling these in, the system can prompt for this information and enter it on the form. Since you can use macros when entering the prompted-for data, you can quickly enter standard information.
System Documents & Reports - these are the things like invoices, receipts, orders, statements etc that the system generates. The system distribution includes these, and in general you should not need to modify them because the Letterhead & Document Control facility should enable you to customise these documents for your practice. However, if you do need further customising then see here.
OpenVPMS supports sending SMS messages. The SMS messages are sent using plugins or via 'email to SMS' gateways provided by various companies.
SMS messages can be sent to any customer or supplier who has a Phone Number Contact with "Allow SMS" ticked.
SMS messages can be sent by clicking the SMS button:
SMS can also be used for both Appointment Reminders and Patient Reminders.
The message length is limited to the Maximum Parts setting on the SMS Configuration. By default this is 1, which allows for 160 GSM characters*, or 70 unicode characters. If a message contains a character that cannot be represented using GSM, it will be sent as unicode.
If the SMS provider supports multi-part messages, this can be increased. E.g.
Parts | GSM characters | Unicode characters |
---|---|---|
1 | 160 | 70 |
2 | 306 | 134 |
3 | 459 | 201 |
4 | 612 | 268 |
5 | 765 | 335 |
* GSM characters are 7 bit, so 160 characters usually fit into a single SMS. In practice, a few GSM characters need to be escaped and take 14 bits, so the actual length may be less.
Note that providers will charge each part in a message as a single SMS.
Two companies are supported via tailored configuration screens, SMS Global and Clickatell. Other companies can be accomodated via a general configuration screen.
See also Reference|Setup|SMS, Customers|SMS and HowTo|Appointment Reminders.
Schedules, Work Lists and Workflow - these are the things that make OpenVPMS easy to use. Reception staff and clinicians can almost carry out all their work starting from the Scheduling and Work List screens. The system has a concept called 'workflow' which automates many of the necessary steps to get from an appointment being made to having the visit and invoicing all completed and the patient happily checked out.
Note that you do not have to used either schedules or work lists - you can check a patient in from their Patients|Information screen. But it really does make life easier - the schedule(s) allow you set up an orderly system to enable customers to be serviced with minimum delay, and the work lists allow you to see the queue of things to be done and monitor what is happening.
This page contains the following headings: Schedules, Work Lists, Workflow, Check-In, Consult, Check-Out, Transfer, Follow-Up, Appointment status, Task status, Status Updates, Multi-Day Resource Bookings, Staff Availability, and Tools.
Schedules
A schedule is a simply a diary of appointments. The following features are provided:
Work Lists
A work list is at its simplest, a queue or list of things to be done. However, it can also be used to manage hospital occupancy, boarding kennels and other resources. While schedules contain appointments, work lists contain 'tasks'. The following features are provided:
Workflow
Buttons on the Scheduling and Work Lists screens enable you to proceed through the steps necessary to process a job from start to finish. These buttons are:
The normal division of labour is that the Reception staff create the appointments and check the patient in. The vet(s) then use the Consult button to enter all the visit related data using the Visit Editor, and then press it's Completed button when they are done. Reception then takes over and does the Check-out.
Check-In
The Check-In button is available on Scheduling and Patient Information screens. Pressing it does the following things:
Consult
The consult activity is much simpler. Pressing the Consult button (on either the Scheduling or Work List screens) displays a clinician prompt if required, and then brings up the Visit Editor screen. This is used to:
The Visit Editor can be exited using one of the following buttons:
Note that the In Progress and Completed buttons are only available on the Invoice tab of the Visit Editor.
Check-Out
Pressing the Check-Out button (on either the Scheduling or Work List screens) does the following:
Transfer
The Transfer Transfer button on the Scheduling screens is designed for use after a consultation in which it decided to admit the patient to hospital or for surgery. It does the following:
Pressing the Transfer button on the Work List screens simply allows you to transfer the selected entry from one worklist to another.
Follow-Up
The Follow-Up Task facility allows you to quickly add a task to a worklist that has been defined as usable for follow-up tasks. These can be any worklist, but it is normal to create specific worklists such as 'Reception to follow up' and 'Dr Bloggs To Do'. You can create a follow-up task either from the Patients workspace by clicking the icon next to the patient's ID in the left panel, or if the 'Follow Up At Check Out' option is set for the Practice, then the New Follow-Up Task window will be automatically displayed at checkout time.
You can define one or more follow-up worklists (in order of preference) for each user and each practice location. When the New Follow-Up Task window is displayed, the default worlist is set from those set the current clinician, or if they have none, then the current user, and if they have none, the current location.
Appointment status
The appointment status can be as follows:
Task status
The task status can be as follows:
The following table shows the change in status of the appointment (in the schedule), the task (in the work list), and the invoice as things progress from a new appointment to all being completed. The actions are the buttons that are pressed on the various screens. Where the same action is shown for both the Schedule and the Work List, this simply means that the button is shown on both screens and you can use either one.
Schedule | Work List | Invoice | Visit | |||
---|---|---|---|---|---|---|
Button | Status | Button | Status | Button | Status | Status |
New | Pending | - | - | - | ||
Check-In | Checked In | Pending | - | In Progress | ||
Consult | In Progress | Consult | In Progress | In Progress | (unaltered) | |
OK | (unaltered) | (unaltered) | ||||
In Progress | In Progress | (unaltered) | ||||
Billed | Billed | Complete | Completed | Completed | ||
Check-Out | Completed | Check-Out | Completed | Finalise=Y Finalise=N |
Finalised Completed |
Completed |
You can of course manually alter the status, but in general you should not need to do, the workflow will take care of setting the appropriate status resulting from each action. The exceptions are: placing an invoice on hold, and cancelling an appointment or task - you need to do these manually - but you won't need to do this often.
Note also that because the appointment and task are linked, changing the status of one will generally change the status of the other. Thus if you have an appointment checked in (and thus the task has been created and has status Pending), then the customer walks out, then you can simply change the status of either the task or the appointment to Cancelled and this will also update the other one automatically.
Multi-day Resource Bookings
This section discusses how to handle multi-day resource bookings.
The scheduler can handle appointments that span the midnight boundary, so you can make an appointment for a 7-day stay in a boarding kennel. However, this does not give you the optimum resource control. The trick is to use work lists (rather than the appointment schedule) and do things is as follows:
Because we have limited the number of slots in the work list, the system will tell you if you are trying to book boarding between dates where the number of cages/runs available on any day between those dates exceeds the maximum.
Staff Availability
It is useful to be able to show on the schedule periods when staff are not available. This can be accomplished as follows:
You can now create 'appointments' which indicate staff unavailability for various reasons.
Tools
The tools to set up the above facilities are:
OpenVPMS has a very capable stock control system. Its facilities include:
To track the progress of orders and deliveries, both these have a status, and the order also has a delivery status.
The order status can be one of the following:
Order Status | Meaning |
---|---|
In Progress | the initial status when the order is created |
Finalised | has been finalised, no more changes can be made |
Accepted | order has been accepted by the supplier |
Rejected | order has been rejected by the supplier |
Completed | order is complete - no more items to be delivered |
Cancelled | Order has been cancelled |
The order's delivery status can be one of the following:
Delivery Status | Meaning |
---|---|
Pending | no items have deen delivered yet |
Part | some items have been delivered |
Delivered | all items have been delivered |
The status of the actual delivery can be one of the following:
Status | Meaning |
---|---|
In Progress | items are being delivered |
Posted | delivery is finalised, either because all items have been delivered (in which case the Delivery Status or the order will be 'Delivered') or they have not (in which case the Delivery Status or the order will be 'Part') |
Cancelled | the delivery is cancelled |
In OpenVPMS the term 'supplier' includes all the entities that supply things:
Note that the use of this split into organisations and staff is not mandatory, and you could just use Supplier Personnel and Veterinarians. However, since staff change, it is probably best to set up the Supplier Organisations and Practices, and then add the appropriate staff entries.
On the accounting side, the supplier transaction set is not nearly as rich as the customer transaction set. Specifically there are no initial balance or adjustment transactions, nor a Check Balance facility. As indicated elsewhere, OpenVPMS does not attempt to provide a complete accounting system for the business. Hence on the supplier side, it provides just enough to handle orders and deliveries.
If you are setting up the system and do want to bring in the current balances for your existing supplier accounts, then the work around would be to create a product say zz-prior-supplies with Printed Name say 'Prior Supplies' and create supplier invoices or credits using this product. Then deactive the product so that it will not be available for normal use.
OpenVPMS provides support for item level tax systems where each invoice item is individually taxed, ie the GST used in Australia, the VAT system used in the UK, and the State taxes used in the USA.
Also it can be configured (via Administration|Organisation|Practice ) to display amounts as either 'tax-included' or a 'without tax' or 'ex-tax' basis. The standard invoice etc document templates are sensitive to the current locale (ie country) and inc/ex tax setting and are formatted appropriately. Hence in Australia with inc-tax we have:
and in the US with ex-tax we have:
Where relevant, the standard reports provided with the system have options to show either inc-tax or ex-tax amounts.
Tax Settings
Taxes can be set at the product, product type, and practice levels. One can also define multiple taxes.
In a simple 'same for everything' situation, it is only necessary to set the tax for the practice.
If different types of products are taxed differently, then the taxes can be set at the type level. Note also that the tax percentage can be set to zero. Thus in a situation where everything is taxed at 10% but one type of product is not taxed, then the simplest way to handle this is to set a 10% tax for the practice, and a 0% tax for the tax free product type. Similarly, if one type of product attracts an extra tax, the standard tax can be set for the practice, and the 'extra tax' product type set as having both the standard and the extra tax.
If there are only a few products with different tax rates, then it may be easier to set the taxes for the individual products.
Customers with special tax status can be accomodated since it is possible to set excluded taxes for any customer.
The system does not support location dependent taxes. That is, it is not possible to have different practice locations with different taxes.
Product Pricing
Product prices can be entered as either inc- or ex-tax amounts. They are displayed on the product screens as either inc- or ex-tax depending on the setting for the Practice.
For each product, a cost price and a markup can be entered, and the system will calculate the tax-included price as follows:
price = (cost * (1 + markup/100) ) * (1 + tax/100)
The tax rate to use is selected as follows:
Alternatively, if desired, the tax included price can be entered directly without any cost or markup.
Customer Transactions
When a product is entered on an invoice (or credit-note etc) the system first uses the logic above to decide the applicable taxes. It then checks if the customer has any tax exclusions, and if so removes these.
The amounts displayed on the invoice (or credit-note etc) screen are always inc-tax irrespective of the Practice inc-/ex-tax setting.
The tax included amount and the tax amount are calculated and stored for each line item. The invoice (or credit-note etc) record holds the total tax-included amount and the total tax amount.
Note that the line-item record also holds the cost and tax-inc amounts of the fixed component of the price, and the quantity and the cost and tax-inc amounts of the unit component. (See also Concepts|Pricing) Hence it possible to construct reports on the achieved sales margins by product, product type, customer, patient breed and so on.
The tills represent the actual tills that the practice uses to hold money. They track not only the cash payments that you receive, but all the other types of payment types (such as cheques, credit cards, EFT, etc) and also any refunds. There will normally be one till for each location but there can be more, and multiple locations can share a till.
At suitable intervals, normally at the end of the day, you will want to check what's in the till, and take out what should be deposited in the bank. This is done using the Reporting|Till Balancing screen. Using this you can print a report of what the system thinks is in the till; you can adjust the cash amount if there have been counting errors; and you can 'clear' the till to remove everything that should go to the bank. It is normal to leave a small cash 'float' in the till so that you have money on hand for change (and cash refunds) at the start of the next day.
Note that the system allows you to balance the till without stopping/pausing the business. Hence practices that operate around the clock are supported.
So the process is print, check and if necessary adjust, then clear.
After you have cleared the till, the money can only be deposited in the bank - it is not available for any refunds. The deposit operation is done using the Reporting|Deposit screen.
The tills are setup by your administrator using Administration|Organisation|Tills.
Users are set up and maintained via Administration - Users.
Users have:
These determine what the user can do. See User Requirements for the requirements of particular users.
User Groups can also be created via Administration - Groups. These are used only to allow messages to be sent to multiple users and cannot be used to set categories and roles for groups of users.
Users have a unique Login Name, used to log in to OpenVPMS.
There is no restriction against multiple people logging on to the system at the same time, with the same Login Name.
If you choose to operate with logins that reflect functions (such as reception, pharmacy, and nurse) rather than names, multiple people can log in as 'reception' at the same time. However, in this environment there will be less tracking of who did what.
Users have a Password, used to log in to OpenVPMS.
Passwords should be at least 8 characters long, and contain a mixture of uppercase and lowercase characters, numbers and special characters. This makes it harder for attackers to guess passwords.
Passwords requirements are determined by the Password Policy, configured in Administration - User.
Passwords can be set:
This requires:
For security, codes expire after a short period of time and there is a limit to the number of times they can be entered incorrectly.
Users have Name, Description, Title, First Name, Last Name and Qualifications fields.
The Name is used for querying and display purposes, e.g. GB, George Brown, or Dr George Brown.
There is benefit in using short names (like GB), because it makes it easier to quickly enter them.
If you are using short names, then the user's description should be set to the full name, e.g. Dr George Brown or even Dr George Brown BSc(Vetbiol), BVMS(Hons). This can then be displayed on forms and certificates.
The Title, First Name, Last Name and Qualifications fields are optional, but should be entered as they are often required by 3rd party systems. They can also be used for reporting.
Users have a 'colour' which determines how their names are highlighted on certain screens - notably the Scheduling, Work List, and Rostering screens.
The system comes with four categories:
Additional categories can be added using Administration - Lookups - User Types. A user can belong to more that one category e.g. a user could be both a Clinician and an Administrator.
Administrators get:
Only users with Clinician category displayed in the 'Clinician' pull-down list shown on various screens.
The following roles are included for web application users:
Role | Authorities |
---|---|
Administrator Perform all operations. |
|
Base Role The base role for all web application users. |
|
Account Manager Manage customer accounts |
|
Account Administrator Administer customer accounts
If a user is granted this role, they should also be granted Account Manager |
|
Clinician Create and remove Prescriptions |
|
Insurance Claims Create and remove Insurance Claims |
|
Practice Manager Manage all customer and patient information |
|
Schedule Manager Create and update Calendar Blocks and Shifts |
|
Schedule Administrator Remove Calendar Blocks and Shifts
If a user is granted this role, they should also be granted Schedule Manager. |
|
Stock Manager Manage Product Batches, Adjustments, Transfers, Orders and Deliveries, create and update Suppliers. |
|
Stock Administrator Manage Products, remove Supplier Orders and Deliveries, remove Suppliers
If a user is granted this role, they should also be granted Stock Manager. |
|
The following roles are defined for system users, such as plugins or web services.
Role | Authorities |
---|---|
Online Booking Make appointments
This is a restricted role for users created to enable external services to make online bookings (e.g. PetYeti, Vetstoria). |
|
Each user has a 'level' from 0 to 9. Reports also have a level. A user cannot run a report with a level higher than their own.
Different sorts of users have different Category and Role requirements.
User | Categories | Roles |
Account Administrators |
|
|
Account Managers |
|
|
Administrators | Administrator |
|
Clinicians | Clinician |
|
Nurses | Nurse |
|
Practice Managers |
|
|
Receptionists | Reception |
|
Schedule Administrators |
|
|
Schedule Managers |
|
|
Stock Administrators |
|
|
Stock Managers |
|
A 'visit' is what it sounds like - a meeting between the vet and the patient. The visit entry in the medical records acts as a heading to group together all the items associated with the visit. Thus under a visit one can have notes, documents, problems, medication and charged items.
The Medical Records Summary is displayed in visit order with the latest visit at the top. Within the visit itself, the items can be displayed in either ascending or descending date/time order.
There is no concept of 'finalising' a visit so that it cannot have entries added to it, or the existing entries deleted or edited. However, you cannot delete or add charges to a past visit.
The visit is normally created when you check-in the patient - but see also below. You then use the visit editor to add items to the visit. See also Schedules, Work Lists and Workflow.
The 'visit' will normally be a real vet-to-pet meeting, but could also be a phone call to the owner (and thus on the Medical Records screen there is an 'Add Visit & Note' button to allow this call to be easily recorded).
Visits are created in the patient's medical record:
In the first three cases, and existing visit may be added to rather than creating a new one. This occurs in the following circumstances (note that 'event date' means the appointment or task date or the date of the invoice line item):
Notes:
As indicated in Introduction|Screen Layout, the system provides a number of different (Customers, Patients, Suppliers, ...) 'workspaces'.
These are so called because the system preserves their contents as you switch between them. Thus if you call up a customer in the Customer workspace, then go to say the Workflow workspace (by clicking on Workflow in the top menu line, or typing Alt-W), and then go back to Customers, your customer display will be unaltered.
Similar 'remember what was displayed' behaviour occurs within a workspace. For example, in the Workflow workspace there are four topics: Scheduling, Work Lists, Messaging, and Investigations. The displays for each of these is remembered separately so that you can switch between the screens without losing anything.
There is one problem with this 'remember what was displayed' behaviour - what happens if something has changed - ie another user entered a new appointment. When you return to the Workflow|Scheduling screen, it will be as you left it. In order to get an up-to-date view, you need to click the Find button or press the Alt-F key.