Laboratory providers provide clinics with regular price updates for requested laboratory services. 

Provide a mechanism to update associated product cost prices (and subsequent selling prices using the markup) based on the updated test prices.

Initially this will allow cost price updates via imported spreadsheets in a defined format for Laboratories that dont support the LAB API.    

code - test code (mandatory)
name - test name (mandatory)
description - extended test description (optional)
specimen - sample instructions (optional)
turnaround time - days (optional)
price - ex GST cost price (mandatory)

JIRA: OVPMS-2694

Often, standard emails need to be sent out with documents attached, such as handouts or forms.
These are typically static documents that don't require any merging.
To do this in OpenVPMS currently requires attachments to be selected manually in the mail editor:

• after turning the document into a Patient Form and adding it to the patient's history
• by uploading an attachment

To automate the generation of emails with static document attachments, provide a facility to attach documents to Email Templates. Each document will be attached when the Email Template is used:

• in the mail editor; or
• to generate email reminders or statements

Configuration

An Attachments tab will be add to the Email Template editor that supports the addition of Document Templates of type:

• Customer Attachment
• Patient Attachment

These are new document types for static customer and patient handouts respectively.

Exclusions

• Only static content will be supported
  There will be no provision for merging content.
• Attached documents will not appear in patient history

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

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
 

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

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

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.