This project will extend the Scheduled Reporting functionality included in OpenVPMS 2.0 to support calculated date parameters.

This will allow standard OpenVPMS reports to be easily scheduled. Currently these must either:

• be modified to calculate the date range to query
• have the parameters configured manually, before the report is scheduled to run

For each date parameter, the following list of options will be available:

• Today  - the current date
• Yesterday - yesterday's date
• Tomorrow - tomorrow's date
• Now - the current date/time
• Start Of Month - the first day of the current month
• End Of Month - the last day of the current month
• Start Of Last Month - the first day of the previous month
• End Of Last Month - the last day of the previous month
• Date - a specific date, to support the existing behaviour

With the exception of the Now option, the date will be calculated and supplied to the report with a 00:00:00 time component.

User Interface

Each date parameter will have a dropdown next to it, allowing the user to select from one of the above options. If Date is selected, a date-chooser will be displayed to select the date.

Archetype Changes

The entity.jobScheduledReport archetype needs new hidden paramExprType1...paramExprType14 and paramExprValue1...paramExprValue14 nodes to store the expression type and value.
The expression type will be 'date', but could be expanded to support jxpath expressions in future.

Migration

Existing Scheduled Reports will need to be migrated

JIRA: OVPMS-2059

1. Overview

At present, OpenVPMS uses a mixture of HL7 and document imports to support laboratory systems.

This project will:

• provide an API to enable 3rd parties develop plugins to integrate laboratory services with OpenVPMS
• provide support to submit orders to laboratories as part of invoicing, as is the case with the existing HL7 support
• extend the Investigation Type, to allow the tests to be included to be specified
• provide user interface support to configure the plugins

2. Laboratory API

The API will:

• provide support to place and cancel orders
• provide support to add results to patient history
• enable laboratory services to be discovered
• enable the tests that a service provides to be discovered
  This will allow Investigation Types to list which tests to order
• enable laboratory services to cancel orders

2.1 Order API

The Order API will enable OpenVPMS to:

• submit orders to laboratory services during invoicing
  This will occur automatically, when charging products that have an Investigation Type linked to a laboratory
• cancel orders during invoicing
  This will occur automatically, when a line-item associated with an order is changed or deleted

2.2 Results API

The Results API will be provided to enable laboratory services to add results to patient history. This will attach results to an existing Investigation, versioning it if there is prior results.

2.3 Services API

The Services API will provide methods to discover and synchronise laboratories and their available tests, in OpenVPMS.
For services that don't support laboratory discovery, it will provide a method to preconfigure a laboratory to use the service.

3. Data Requirements

3.1 Laboratory

OpenVPMS already has two objects to support HL7 laboratories:

• Laboratory - sent orders for patient Investigations, for a single Practice Location
• Laboratory Group - groups multiple Laboratory services so they can be treated in the same way for the purposes of invoicing

These are used by Investigation Types to determine where orders are sent.

The existing Laboratory will be renamed HL7 Laboratory to better reflect its function.

The Laboratory Group will be repurposed to allow both HL7 Laboratory objects and a new Laboratory type.

This will contain:

• location - the practice location where the laboratory may be accessed.
  This may be configured after plugin deployment.
• user - the user to use when submitting orders. Optional
  This will be configured after plugin deployment
• service - a link to the laboratory service
• tests - a lists of tests supported by the laboratory

3.2. Plugin Archetype Requirements

Laboratory Service

Plugins will be required to define and install an archetype with the prefix entity.laboratoryService. E.g. entity.laboratoryServiceAbaxis

This must contain the following fields:

• name - the laboratory service name
• description - optional description
• active - determines if the service is active or not.

The archetype may contain additional fields to determine how the service is configured.

Species and Breeds

Each laboratory typically has its own species and breeds, which need to be mapped to the OpenVPMS equivalents.

It is envisaged that laboratories will provide archetypes to map these i.e.:

• lookup.species<Laboratory>
• lookupRelationship.speciesMapping<Laboratory>

and if breeds are supported:

• lookup.breed<Laboratory>
• lookupRelationship.breedMapping<Laboratory>

Typically, OpenVPMS users are free to add their own species and breeds so the mapping will likely be a manual integration step.

4. Integration

The following changes are required to integrate the Laboratory API:

• invoicing needs to use laboratory service plugins to submit and cancel orders, when there is laboratory service linked to an investigation type
• the Administration - Organisation (or Types?) workspace needs to be updated:
  • to support configuration of entity.laboratoryService* instances
  • synchronise services
• the Investigation Type will be updated to list the tests to order
  If an Investigation Type is linked to a Laboratory Group, each Laboratory in the group must support the same tests

5. Exclusions

• If an investigation is cancelled outside of OpenVPMS, any changes to the customer invoice must be done manually (see OVPMS-2178)
• The existing HL7 Laboratory support could be re-implemented as a plugin, using this API. That is out of the scope of this project.

JIRA: OVPMS-2082

1. Overview

This project is an enhancement to the Patient Insurance project.

It will include:

• support for gap claims
• a claim wizard
• improved policy validation
• insurance reporting

2. Gap Claims

A gap claim is one where an insurance claim is submitted to the insurer, and the insurer calculates a benefit amount. The customer pays the gap, which is the difference between the total claim and the benefit amount.

Gap claims will only be supported for online claims. It won't be possible to create a gap claim for insurers that accept offline (i.e. paper/email/fax based) claims.

Gap claim functionality will be provided by adding the following fields to Claims:

• Gap Claim - a check box to indicate if the claim is a gap claim or not.
  This is disabled if the insurer doesn't support gap claims, and hidden for offline claims
• Benefit Amount - a read-only field indicating the benefit amount
• Benefit Notes - a read-only field containing a response from the insurer regarding the claim
• Gap Claim Status - a read only field indicating the status of the gap claim. One of Pending, Received, Cancelled

2.1 Submitting Gap Claims

Gap claims may be submitted by:

1. Creating a new Claim, and ticking the Gap Claim checkbox
2. Adding finalised unpaid invoice(s)
3. Clicking Submit

On submit, a dialog will be displayed with the title Submit Claim and message:

Waiting for <Insurer Name> to provide a Benefit Amount

This will poll the claim every few seconds to see if the insurer has updated it.
It will provide a single Close button, which will close the dialog, and return the user to the Insurance workspace.

If the Gap Claim Status is changed to Received while the dialog is displayed, a message will be displayed, along with any description from the insurer e.g.

<Insurer Name> is providing a benefit of: <Benefit Amount>
<Benefit Description>

The dialog will have two buttons:

• Pay Claim - launches a payment dialog to make a gap payment against the selected claim
• Close - closes the dialog without making a payment.

2.2 Gap Claims Hours of Operation

Insurers may not provide 24/7 support for gap claims. When selecting the Gap Claim checkbox, a warning will be displayed if the insurer doesn't support 24/7 claims e.g.:

<Insurer Name> is accepting gap claims until 5:00pm today

or:

<Insurer Name> is not accepting gap claims at the moment.
Gap claims may next be submitted on Monday 19/3 at 9:00am

3. Claim Wizard

In OpenVPMS 2.0, users must create a Policy prior to submitting a Claim.

Often, the customer doesn't know their policy number, or when their policy expires. For some insurers, a valid policy number isn't a requirement, so to streamline the process of creating new claims:

• A claim wizard will be provided to create claims, without knowing the policy details beforehand
• Policies will be de-emphasised in the UI i.e. the Insurance tab will display claims by default; policies will be excluded

When no policy is selected, the Claim button will display a dialog with the options:

Create a new claim using:

    Existing policy: <Policy List>

    Insurer: <Insurer Selector>

The Existing policy option provides a list of policies associated with the patient, most recent first.

When selected, and the Insurer is:

• Online, it validates the policy. If the policy is:
  • valid, it launches a new claim dialog, with the policy pre-populated, as is the case now.
  • invalid, displays an error message. The user can re-select from the options above
• Offline, it launches a new claim dialog, with the policy pre-populated, as is the case now

The Insurer option enables users to select from insurers. If the insurer is:

• Online, and the insurer supports policy number discovery, the policy number will be queried
  • If found, a new claim dialog will be displayed, with the policy populated
  • If not found, and the insurer:
    • supports claim submission without a policy, a placeholder policy will be created and the claim dialog displayed
    • requires a policy number, an error will be displayed. The user can then re-select from the options above
• Offline, a message will be displayed:

<Insurer name> does not support policy number discovery.
Please enter the policy number:

The user can then enter the policy number, and the claim editor will be displayed, or re-select from the options above.

4. Policy Validation

In OpenVPMS 2.0, insurers can indicate that policy numbers are invalid via the Check Policy button.

This has the following limitations:

• Users cannot correct policy numbers or insurers, once a claim has been submitted
• The policy cannot be automatically updated with the correct the policy number, or the insurer.

This will be changed to:

• allow the claim plugin to return a corrected policy number and/or insurer for a policy
• warn the user if the policy being claimed against is not valid, and update it with a corrected policy

NOTE: A new policy will only be created if the insurer is available in the system. If the insurer list is not updated (e.g. hasn't been synchronised), the claim will not be updated. No facility will be provided to update the claim in this instance.

5. Insurance Reporting

A new Insurance Claims workspace will be provided in Reporting.

This enables claims to be queried by:

• Insurer - defaults to all insurers
• Claim identifier - defaults to all claims
• Status - defaults to Pending
• Gap Claim Status - defaults to None
  When querying by Gap Claim Status, the Status will be set to Submitted
• Date range
  Allows claims to be filtered by creation date. Defaults to all claims

It also provides buttons:

• Find - find claims matching the criteria
• Submit - submit a Pending or Finalised claim
• Pay Claim - launches a payment dialog to make a gap payment against the selected claim
• Benefit Paid - acknowledges receipt of a benefit payment from an insurer
• Benefit Unpaid - cancels acknowledgment of receipt of a benefit payment from an insurer
• Print - print a listing of claims matching the criteria.
  This can be used to help reconcile benefit amounts.

Claims matching the criteria will be displayed in a table including the:

• Insurer
• Claim identifier
• Customer
• Patient
• Status
• Gap Claim Status
• Benefit Amount
• Benefit Paid

The Benefit Paid button is used to acknowledge payment of a gap claim benefit from an insurer, and is used to reconcile claims with payments received from an insurer.

It only applies to claims with Status = Settled and Gap Claim Status = Paid.
It updates the Gap Claim Status to Settled.

The Benefit Unpaid button is used to correct claims that have been erroneously marked as Settled.
It only applies to claims with Status = Settled and Gap Claim Status = Settled.
It updates the Gap Claim Status to Paid.

6. Plugin API

The plugin API will need to be extended support gap claims and policy validation.

JIRA: OVPMS-2034

This project will provide an option to display Communications (i.e. those from Patients - Medical Records - Communications), in Patients - Medical Records - Summary.

This will:

• make it easier to see the flow of events for a patient
• remove the need to duplicate communications as notes in a patient's history.

Display

In the patient history, the Note communication will be displayed as Communication to distinguish it from clinical notes.

As communication records can be large, only the To address  (if any) Subject line and of a communication will be displayed; the full communication can be accessed by double-clicking on it.

Where a communication falls within a Visit it will be displayed amongst the Visit items, otherwise it will be displayed on its own line e.g.:

05/02/2018     Phone Log        04123456 
                                Called owner re: results
04/02/2018 - Checkup - J Smith [Completed] 12 years
    04/02/2018 Note             some note
               Investigation    some investigation               
               Email Log        "Anne Blogs" <ann[at]nosuchmail[dot]com>
                                Information on Fido's condition
03/02/2018     Communication    Groomer reported seeing lump on Fido's abdomen. Advised owner to make appointment   

Creation

Communications may be created, edited, and deleted from within the Summary. They will appear listed in New Medical Record list, when clicking New to create a new record.

Configuration

Display of communications will be enabled through user preferences.

Record Locking

Communication records are not subject to record locking, as they don't form part of the patient history.

Printing and Insurance Claims

Communications will not appear in printed history, nor will they be submitted as part of insurance claims as they do not represent clinical history.

At present, any customer and patient alerts are displayed in order of priority

• on the left hand side of the screen
• when creating appointments

This project will introduce a Mandatory Alert flag to both Customer Alert Type and Patient Alert Type that when selected, will display the alert in the popup window.
The user must click OK on the alert before proceeding.

The alerts will be displayed when:

• a customer is selected in
  • a customer workspace (e.g. Customers - Information)
  • an act (e.g an appointment or task)
• a patient is selected in:
  • a patient workspace (e.g. Patients - Information)
  • an act (e.g an appointment, task, invoice, or estimate)

A single customer or patient alert will only be displayed once for a user, within a 24 hour period.

JIRA: OVPMS-2084

At present, users go through a number of steps in order to Check-In a patient:

1. Select Patient - only required if the appointment doesn't have one

2. Select Work List - if the schedule is associated with work lists

3. New Weight - record the patient's current weight

4. Customise Flow Sheet - creates a Smart Flow Sheet for the patient, if the selected work list requires one

5. Print - print documents associated with the schedule/work list

Each of these steps display a new window, and each window requires a click to get to the next step. On completion of the steps, the Edit Visit window is displayed. 

To reduce the number of clicks, the steps will be displayed in a single Check-In window. This will contain:

• Clinician
  The clinician to assign to any records created during Check-In.
  If the practice Use Logged In Clinician option is:
  • enabled, this will default to the current clinician, or the appointment clinician if the current user is not a clinician
  • disabled, this will default to the appointment clinician
• Patient
  If a patient is present, this will display the name of the patient.
  If not, a binocular field will be displayed to select one of the customer's patients.
• Work List
  Only displayed if the schedule is configured with work lists.
  Displayed as a binocular field.
  May be left blank
• Smart Flow Sheet
  If the Work List indicates a Smart Flow Sheet is required, this will enable the Department, treatment Template and Duration of Stay to be customised
• Weight
  Displays the current weight.
  Provides fields to enter the new patient weight, units, and clinician.
• Print
  Provides a list of documents to print, based on the Schedule and Work List selection.

The window provides OK and Cancel buttons.

The OK button is only enabled if a patient is selected. Clicking it:

1. creates a Task, if a Work List was selected
2. records the patient weight, if any
3. creates a Smart Flow Sheet, if required
4. prints any selected documents
5. continues the Check-In workflow

The Cancel button cancels Check-In.

JIRA: OVPMS-2106

When creating or editing patient Notes, the patient history cannot be accessed directly:

• users must have a second window open and switch between the two
• existing notes can only be copied by:

1. editing them
2. selecting the text
3. pressing Ctrl-C
4. editing a new note
5. pressing Ctrl-V

This is because the Summary display has row selection enabled, which prevents the copying of text

This project will simplify note editing by displaying the patient history beneath the Note. The history will have all of the features of the Patients - Medical Records - Summary tab, with the exception of the buttons to edit, delete. In addition, it will be possible to copy text from the patient history as row selection will be disabled.

For practices using HL7 pharmacy orders, orders are discontinued at the time of invoice finalisation.

That is, any pharmacy order that was submitted as part of invoicing can no longer be dispensed once the invoice is finalised.

For some practices, this does not meet the requirements of their workflow. For these practices, a facility is required to delay the discontinuation of orders for a period after finalisation.

This will be supported by providing:

• practice level options:
  • Discontinue Pharmacy Orders which may be one of:
    • On Invoice Finalisation - reflects the current behaviour
    • After Period - indicates to discontinue orders after finalisation
  • Discontinue Period used when After Period is selected, and determines the period after invoice finalisation when orders should be discontinued
• a job to discontinue pharmacy orders, when After Period is set
  This will be automatically configured when Discontinue Pharmacy Orders is changed. i.e. it will be configured to run when After Period is set, and disabled when On Invoice Finalisation is set.

Migration

To support this change:

• a hidden Status will be added to invoice items to to indicate that orders have been submitted/discontinued. This will replace the existing ordered flag. The status may be one of:
  • empty - no orders have been submitted
  • ORDERED - one or more orders have been submitted
  • DISCONTINUED - all orders have been discontinued
• a hidden End Time will be added to invoices and invoice items to indicate when the invoice was Finalised

Note that this status will not be used to indicate the status of laboratory orders.

Existing invoices will not have their End Time set.

JIRA: OVPMS-2114

Configuration and Monitoring

A new Plugins tab will be added to Adminstration - System, to:

• configure the directory where plugins are deployed from
• monitor plugins
• install new plugins

Plugin Services

The following plugin services will be provided initially:

• ArchetypeInstaller - allows plugins to install archetypes into OpenVPMS
• PluginConfigurationService - allows plugins to manage their configuration
• PluginArchetypeService - limited version of the ArchetypeService, to allow plugins to access the database

Packaging

The release distribution will be updated to contain a pre-packaged version of Apache Felix, containing a number of OSGi bundles required for plugins to function.

Overview

The Services Ratio support introduced in OpenVPMS 1.8 allows product types to be assigned a service ratio per Practice Location. This ratio is used to calculate a new product price from its existing price, when it is used in a charge or estimate.

This facility is designed to enable different Locations (such as those used for over-night emergency or house-call operations) to charge more for products of certain types.

It will be extended to associate a calendar with the Service Ratio, to determine the dates and times that the ratio applies.
Note that the ratio is fixed; the calendar will only determine if the service ratio applies or not. It cannot be used to set a different service ratio at different times.

It will remove the need for supporting different charges via:

• a separate practice location to handle out-of-hours or weekend services
• different products for the same service
• different fixed prices 

Examples

1. Out of hours surgery

To charge surgery services at 150% outside of 7am and 7pm, and on weekends, at Clinic A:

• add a Service Ratio of 1.5 between the surgery Product Type(s) and Clinic A
• attach a calendar with the following repeating slots:
  • Start Time: 00:00, End Time: 07:00, Repeats: Daily, 365 times
  • Start Time: 19:00, End Time: 00:00, Repeats: Daily, 365 times
  • Start Time: 00:00, End Time: 00:00, Repeats: Every Saturday and Sunday, 52 times

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:

• add a Service Ratio of 0.5 between the grooming Product Type(s) and Clinic A
• attach a calendar with the following repeating slots:
  • Start Time: 02/08/17 10:00, End Time: 02/08/17 14:00, Repeats: Every Wednesday, until 01/09/17

Estimates and Charges

Calendar-based service ratios will apply to individual line items in both estimates and charges, and will be applied at the creation time of the estimate or charge item.

If a product attracts a 150% charge after 7pm, charging it at 3pm will attact the normal price, whereas charging it at 9pm will attract the higher price. An invoice can therefore have two line items for the same product, at different prices.

Apply Service Ratio

To allow users to control if a ratio should be applied, an Apply Service Ratio flag will be displayed for estimate and charge items. This will:

• be selected, if a ratio has been applied
• revert to the normal price if deselected
• be disabled if there is no service ratio

The Apply Service Ratio flag will only be displayed at locations that have service ratios configured.

Invoicing Estimates

When invoicing estimates, the invoice inherits the prices from the estimate.

If an estimate contains items where the service ratios are different between when the item was created and the current time, a confirmation will be displayed:

One or more items have a service ratio that do not apply at this time.

Charge items at the:

• estimate price
• current price

Selecting 'Charge items at the estimate price' is the default, and will invoice items as per existing behaviour.

Selecting 'Charge items at the current price' will determine the prices based on the current time.

Once invoiced, the Apply Service Ratio flag on each line item can also be toggled to further customise how a product is charged.

Configuration

Calendars

Service Ratio Calendars will be configured in Administration - Types.

The Calendar will display dates as columns, and times as rows. 24 hours will be displayed in 30 minute slots.

A Block button will be provided to create a new block indicating when the service ratio applies. It will have the same options as blocks in Workflow - Scheduling.

Service Ratios

Service ratios will still be configured via the Practice Location. However they will feature an option to select the appropriate Service Ratio Calendar by name.

Exclusions

Permissions

There is no requirement to restrict which users can toggle the Apply Service Ratio flag.

Reporting

There is no requirement to indicate that an estimate or charge is subject to a service ratio i.e. this does not need to be displayed in printed estimates or invoices.

JIRA: OVPMS-2054