Completed

Project will now be part of an official release.

Charge Reporting

Development Project Status: Completed

Total cost estimate (ex-Tax): 
$660
Due date for completion of this stage: 
10/01/2020
Release: 
2.2
Project funding: 

You can donate money to this project by entering the amount above and clicking the 'Add to cart' button. In the Checkout process you can either choose to pay now (via Bank Transfer, Cheque or Pay Pal) or you can pledge the amount by choosing the 'Pledge a payment for a Development Project' method. If you make a pledge, then when we have 100% funding commitments, you will be notified by email and you can then action your payment. Note that development will not commence until all funds are received.

Project description: 

This project will integrate functionality provided by a number of reports* into OpenVPMS:

  • search by invoice number
  • search by amount

These will be provided in a new Search workspace.

Search Criteria

Charges may be searched by:

  • Identifier (i.e. invoice number, credit number etc)
  • Type (Invoice, Counter Sale, Credit)
  • Customer Name
  • Status
  • date range
  • total amount
    For performance reasons, a 6-month date range will be required when searching on amounts
  • Practice Location

Printing

A Report button will be provided to print a summary of matches.
This will be similar to the existing Work In Progress report.

User Interface

The Search workspace will be provided as a tab under Reporting - Charges.

 

The existing Work In Progress workspace will be also be moved to a tab under Reporting - Charges

 

 

* https://openvpms.org/forum/search-invoice-number-0

 

 

JIRA: OVPMS-2239

Roster synchronisation with Deputy

Development Project Status: Completed

Total cost estimate (ex-Tax): 
$4950
Due date for completion of this stage: 
19/03/2019
Release: 
2.1
Project funding: 

You can donate money to this project by entering the amount above and clicking the 'Add to cart' button. In the Checkout process you can either choose to pay now (via Bank Transfer, Cheque or Pay Pal) or you can pledge the amount by choosing the 'Pledge a payment for a Development Project' method. If you make a pledge, then when we have 100% funding commitments, you will be notified by email and you can then action your payment. Note that development will not commence until all funds are received.

Project description: 

Overview

OpenVPMS 2.1 includes basic rostering support to roster clincians and other users.
Appointment scheduling is integrated with rostering to determine clinician availability.

This project will provide two-way synchronisation of OpenVPMS rosters with Deputy so that:

  • roster information can be established in Deputy, which provides comprehensive rostering support
  • changes can be made in OpenVPMS and they will be reflected in Deputy

Mapping

A user interface will be provided to enable:

  • OpenVPMS roster areas to be mapped to Deputy Areas
  • OpenVPMS users to be mapped to Deputy Employees 

Synchronisation

Several synchronisation methods will be used:

  • Polling
    Deputy will be periodically polled for updates.
    The frequency of polling, and how many days to poll will be configurable
  • Triggers
    Shift updates will be monitored, and propagated to Deputy.

Synchronisation Errors

If a shift cannot be synchronised, it will be highlighted in the user interface.

Exclusions

User and Roster Area Creation

This release will not support:

  • creation of Roster Areas and Users in OpenVPMS corresponding to those in Deputy
  • creation of Areas and Employees in Deputy corresponding to those in OpenVPMS

Missing resources must be created in their respective systems, and mapped.

Breaks

Deputy enables shifts to contain zero or more breaks (e.g. Meal, Rest).
This information will not be synchronised.
This may mean that clincians can be scheduled for appointments when they are on a break.

Updates to old shifts

If a shift is updated from a prior day, this will not be synchronised.

OAuth

Deputy provides both Permanent Token and OAuth 2.0 access, as described here: https://www.deputy.com/api-doc/API/Authentication

Initially, we will only support Permanent Token access.

 

JIRA: OVPMS-2189
 

Simplify emailing

Development Project Status: Completed

Total cost estimate (ex-Tax): 
$495
Due date for completion of this stage: 
19/11/2018
Release: 
2.1
Project funding: 

You can donate money to this project by entering the amount above and clicking the 'Add to cart' button. In the Checkout process you can either choose to pay now (via Bank Transfer, Cheque or Pay Pal) or you can pledge the amount by choosing the 'Pledge a payment for a Development Project' method. If you make a pledge, then when we have 100% funding commitments, you will be notified by email and you can then action your payment. Note that development will not commence until all funds are received.

Project description: 

To email documents in OpenVPMS requires selecting Print, and then Mail, to display the email dialog.

To reduce clicks, provide a Mail button next to each Print button. This should have a shortcut on M, which means that the existing M shortcut for the Administration workspace will need to change to D.

The existing Mail button in the Print dialog will be retained.

 

JIRA: OVPMS-2100

Improved patient search

Development Project Status: Completed

Total cost estimate (ex-Tax): 
$660
Due date for completion of this stage: 
19/11/2018
Release: 
2.1
Project funding: 

You can donate money to this project by entering the amount above and clicking the 'Add to cart' button. In the Checkout process you can either choose to pay now (via Bank Transfer, Cheque or Pay Pal) or you can pledge the amount by choosing the 'Pledge a payment for a Development Project' method. If you make a pledge, then when we have 100% funding commitments, you will be notified by email and you can then action your payment. Note that development will not commence until all funds are received.

Project description: 

This project will replace the existing patient search facility used in Patients - Information and Patients - Medical Records with the customer based one

This will allow patient selection by customer, patient and/or contact.

If a customer is already selected:

  • the Search field will contain the customer identifier
  • all patients for the customer will be listed
  • the focus will be in the Patient field
  • the Search can be changed to search on a different customer

If no customer is selected:

  • the focus will be in the Search field, to allow customer entry.

Results Display

If the Search field has the identifier of the current customer, then the results will display the:

  • patient identifier
  • patient name
  • patient description

If the Search field is anything else, then the results will display the:

  • customer identifier
  • customer name
  • patient identifier
  • patient name
  • patient description

Active Search

The Active drop down will allow searches for active or inactive or both active/inactive patients. Only active customers will be queried.
To find inactive customers, the customer search must be used in the customer workspaces (Customers - Information etc).

JIRA: OVPMS-2102

Rostering

Development Project Status: Completed

Total cost estimate (ex-Tax): 
$6600
Due date for completion of this stage: 
07/11/2018
Release: 
2.1
Project funding: 

You can donate money to this project by entering the amount above and clicking the 'Add to cart' button. In the Checkout process you can either choose to pay now (via Bank Transfer, Cheque or Pay Pal) or you can pledge the amount by choosing the 'Pledge a payment for a Development Project' method. If you make a pledge, then when we have 100% funding commitments, you will be notified by email and you can then action your payment. Note that development will not commence until all funds are received.

Project description: 

This project will provide rostering support in OpenVPMS.

  • users are rostered to an Area, which is linked to a practice Location
  • Areas can have zero or more Schedules
  • user availability is determined by roster events, which have a start time, end time and Area
  • extend the Booking API to enable clinician availability to be queried

Rostering Workspace

A new Rostering workspace will be added to Workflow, listed under Tasks.

Rostering will performed in a new Rostering workspace. Two views will be provided:
1. roster by Area, showing who is rostered on
2. roster by user, showing when they are rostered on, and to which Area

Roster Editing

A calendar is used to roster a user on or off.
This is displayed as a grid with the columns representing the days.
Shifts are placed to determine when a user is rostered on.
Each shift contains the:

  • roster area
  • practice location
  • start and end time
  • the user. This is optional. If no user is assigned, the shift is not yet filled.

Appointments

When a clinician has a roster, attempting to select them for an appointment when they are not rostered on will display a warning:

<Name> is not rostered on.
 

If a clinician already has an appointment at the same time, it will display a warning:

<Name> already has an appointment at this time for <schedule>.

In all cases, the user can keep the selected clinician, or choose a different one.        

Booking API

The booking API will be extended to:

  • return a list of clinicians who work at a location
  • return the availability of a clinician
    This will be determined from their roster, and any appointments that have already been scheduled for them
    The response will include an optional list of schedules, in case clinicians can be rostered to specific schedules in future
  • allow bookings to be made for a specific clinician
    If the clinician is not available at the time, a note will be added to the booking.

Exclusions

This project will not support synchronisation with 3rd party rosters or calendars.

Scheduled Reporting - Calculated Date Parameters

Development Project Status: Completed

Total cost estimate (ex-Tax): 
$660
Due date for completion of this stage: 
16/07/2018
Release: 
2.1
Project funding: 

You can donate money to this project by entering the amount above and clicking the 'Add to cart' button. In the Checkout process you can either choose to pay now (via Bank Transfer, Cheque or Pay Pal) or you can pledge the amount by choosing the 'Pledge a payment for a Development Project' method. If you make a pledge, then when we have 100% funding commitments, you will be notified by email and you can then action your payment. Note that development will not commence until all funds are received.

Project description: 

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

Laboratory API

Development Project Status: Completed

Total cost estimate (ex-Tax): 
$6600
Due date for completion of this stage: 
05/07/2018
Release: 
2.2
Project funding: 

You can donate money to this project by entering the amount above and clicking the 'Add to cart' button. In the Checkout process you can either choose to pay now (via Bank Transfer, Cheque or Pay Pal) or you can pledge the amount by choosing the 'Pledge a payment for a Development Project' method. If you make a pledge, then when we have 100% funding commitments, you will be notified by email and you can then action your payment. Note that development will not commence until all funds are received.

Project description: 

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

Patient Insurance - Gap Claims

Development Project Status: Completed

Total cost estimate (ex-Tax): 
$10240
Due date for completion of this stage: 
16/03/2018
Release: 
2.1
Project funding: 

You can donate money to this project by entering the amount above and clicking the 'Add to cart' button. In the Checkout process you can either choose to pay now (via Bank Transfer, Cheque or Pay Pal) or you can pledge the amount by choosing the 'Pledge a payment for a Development Project' method. If you make a pledge, then when we have 100% funding commitments, you will be notified by email and you can then action your payment. Note that development will not commence until all funds are received.

Project description: 

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

Display customer communications in patient history

Development Project Status: Completed

Total cost estimate (ex-Tax): 
$1320
Due date for completion of this stage: 
04/02/2018
Release: 
2.2
Project funding: 

You can donate money to this project by entering the amount above and clicking the 'Add to cart' button. In the Checkout process you can either choose to pay now (via Bank Transfer, Cheque or Pay Pal) or you can pledge the amount by choosing the 'Pledge a payment for a Development Project' method. If you make a pledge, then when we have 100% funding commitments, you will be notified by email and you can then action your payment. Note that development will not commence until all funds are received.

Project description: 

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.

Mandatory customer and patient alerts

Development Project Status: Completed

Total cost estimate (ex-Tax): 
$660
Due date for completion of this stage: 
04/02/2018
Release: 
2.1
Project funding: 

You can donate money to this project by entering the amount above and clicking the 'Add to cart' button. In the Checkout process you can either choose to pay now (via Bank Transfer, Cheque or Pay Pal) or you can pledge the amount by choosing the 'Pledge a payment for a Development Project' method. If you make a pledge, then when we have 100% funding commitments, you will be notified by email and you can then action your payment. Note that development will not commence until all funds are received.

Project description: 

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

Syndicate content