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

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

Patient check-in simplification

Development Project Status: Completed

Total cost estimate (ex-Tax): 
$1650
Due date for completion of this stage: 
11/12/2017
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, 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

Syndicate content