This project will provide a shortcut for creating a new prescription by adding a New Prescription button to the Medication editor/viewer.

The New Prescription button will be displayed under the existing Print Label button.

Clicking it will create a new Prescription, and display it in an editor with:

• the same medication, quantity and label
• current clinician
• default prescription expiry date

The New Prescription button will be available wherever a Medication can be viewed or edited i.e. in:

• invoice editors and viewers
• Patients - Medical Medical Records - Summary

JIRA: OVPMS-1919

Overview

This project will add support to lock medical records 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 will support locking:

• Note
• Addendum (see below)
• Weight
• Medication
• Attachment
• Form
• Image
• Letter
• Investigation

Locking

Medical record locking will be enabled by a new practice level configuration option Medical Record Lock Interval. This will specify a period and units, e.g 24 hours or 1 week. If blank, locking will be disabled.

Medical records will be locked by setting their status to Finalised. This will be 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 - interval

where:

• Start Time = the date/time when the record was created
• now = the current date/time
• interval = the Medical Record Lock Interval

Exceptions

There are a number of exceptions to the locking rule:

• Medication, investigation and document records linked to an invoice may be edited or removed via the invoice, until the invoice is finalised
• Investigation and Attachment records can be updated via the Document Loader
• Medication, investigation, and document records can be unlinked from the patient history if the invoice is reversed.  See OVPMS-1309
• Investigation records can have:
  • results attached
  • select attributes changed (see Investigation Changes below)

Addendum Record

To support changes to Notes and Medication records that have been locked, a new Addendum record will be provided. This is a type of note that:

• is added to an existing Note or Medication
• 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.

Auditing

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.

Investigation Changes

Status

The patient Investigation record has a status field which is incompatible with the proposed locking mechanism i.e. its status may currently be one of:

• In Progress
• Received
• Completed
• Cancelled
• Preliminary
• Final

This will be changed so that the status field may be one of:

• In Progress
• Cancelled
• Finalised

A new field, Result Status, will be added which may be one of:

• Pending - the order is yet to be submitted
• Sent - the order has been submitted
• Preliminary - preliminary results have been received. This will be the status the Document Loader uses whenever it attaches a document
• Final - final results have been received. This must be set by users

The Completed and Received statuses will be dropped.

This will require a change to Workflow - Investigations workspace, to support querying by Result Status instead of Status.

Post Locking updates

Investigations need to support some updates after they have been locked:

• Reports need to be able to be added. Adding a report should create a new version, if a report has already been attached.
• The Reviewed flag needs to be editable
• The Result Status needs to be editable

All other fields should be read-only. It should not be possible to replace an existing Report, nor edit past versions.

Editing Records

Prior to editing an In Progress medical record, a check will be 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.

Archetype Changes 

• The Weight, Note and Medication archetypes, need a read-only, hidden status node with possible values:
  • In Progress
  • Finalised
• A new Addendum archetype is required
• Each of the record types currently allow their date to be changed. These dates will need to be made read-only, as they will be used to determine when the record is locked.

Reporting Changes

The following reports need to be updated to support the Addendum record:

• Medical Records
• Problems
• Patient History Search

Migration

Existing investigations need to be migrated, in order to support the new Result  Status. Any investigation with:

• Completed status will be set to Finalised, and the Order Status set to Final
• Received status will be set to In Progress, and the Order Status set to Sent

Overview

OpenVPMS keeps track of the last selected clinician, and uses this to automatically populate clinician fields during workflows. This simplifies data entry for:

• reception and nursing staff
• sites that use the same login sessions for multiple users (e.g. shared terminals in consulting rooms)

This is insufficient for sites where terminals aren't shared. Here the logged in clinician should always be used, if one is available.

This project will provide a practice setting that always uses the logged in clinician, if one is available.

Current Behaviour

For the Check-In workflow, the clinician is obtained from the appointment.

For the Consult workflow, the clinician is obtained from the appointment or task. If there is none, the last selected clinician is used.

For the Check-Out, and Payment workflows, the last selected clinician is used.

In each workflow, if the clinician is changed, then the new clinician will be used to automatically populate other Clinician fields.

New Behaviour

A new Practice option Use Logged In Clinician will be provided. When ticked, and the logged in user is a clinician, it will be used to populate Clinician fields. Clinician fields can be changed to a different clinician, but the selected clinician won't become the new default for other Clinician fields.

If the logged in user is not a clinician, then the existing behaviour will be seen.

JIRA: OVPMS-1997

If a patient needs to be admitted to hospital after a consultation, a new work list task needs to be created, and any relevant documents created and printed manually.  

This project will add a new Transfer button to Workflow - Scheduling that is enabled when an appointment is selected that is one of Checked In, In Progress, Admitted, Billed or Completed. This will:

1. prompt for a work list

Work lists will be limited to ones associated with current practice location

2. display a Print window if the target work list has templates or Use All Templates is ticked, listing the available templates to print.
3. add a work list task for the selected work list, for the appointment patient

The task will be given the same status as appointment if they have a status in common. If not, it will be set to In Progress.

4. update the appointment status to Admitted, provided it is not Billed or Completed

JIRA: OVPMS-1726

This project will provide support to log customer communications, both automatically and manually, and allow this log to be queried.

It will replace the existing Notes tab, under Customer -> Notes & Alerts. Existing notes will be migrated.

The following information will be logged:

• the date/time that the communication occurred
• the type of the communication. One of:
  • phone
  • SMS
  • email
  • mail
  • note
• the customer
• optional patient
• the reason for the communication e.g. reminder, surgery followup
• the communication address i.e. the phone number, mailing address, or email address
• optional description
• optional notes
• the practice location
• the author (i.e. the logged in user)

For emails and SMS, the content will be logged.

A log will be created automatically under the following circumstances:

• when a reminder is emailed, SMSed or printed during reminder generation
• when a customer is sent an ad-hoc SMS
• when a customer is sent an email
• when someone other than the customer is sent an email, regarding the customer's patient e.g. for a referral

User Interface

Communications Log

The existing Notes & Alerts workspace will be renamed to Communications, and the Notes tab renamed to Communications. The Alerts tab will be retained.

The Communications tab will list log entries from newest to oldest in a table including:

• Date
• Patient
• Type
• Reason
• Location
• Address
• Description

Selecting an entry will display the full log details in an area beneath the log table.

New, Edit and Delete buttons will be provided. These will be subject to the usual archetype security permissions.

Display Criteria

By default, all log entries will be displayed.

Log entries may be filtered on:

• Date range
• Patient
• Type

Customer Summary Hyperlink

A Communications hyperlink will be added to the customer summary to display the Communications tab.

Automatic Logging

Reminder Generation

A log will be created for each reminder that is emailed, SMSed or printed by Reporting -> Reminders -> Send All.

No log will be created if the reminder is listed to be phoned, or exported.

The log will include:

• Date: the date/time the reminder was generated
• Type: one of Email, SMS, Mail (for printed)
• Customer: the owner of the patient
• Patient: the patient linked to the reminder
• Reason: Patient Reminder
• Address: the customer email address, phone number, or mailing address
• Description: the reminder type and count
• Location: the practice location where the reminder was generated
• Author: the logged in user

Customer Emails

If an email is sent to a customer, initiated from the customer summary or contacts, a log will be created with:

• Type: Email
• Reason: Ad-hoc email
• Patient: the current patient, or none if no patient is selected or doesn't belong to the customer
• Address: the customer email address
• Description: the email subject
• Notes: a list of the names of any attachments
• Location: the practice location where the email was sent from
• Author: the logged in user
• Content: the body of the email, excluding attachments

Emailed Customer Documents

If an email is sent to containing one or more customer document as attachments, a log will be created with: 

• Type: Email
• Reason: Forwarded documents
• Customer: the customer the documents belong to
• Patient: None
• Address: the email address. This may not belong to the customer
• Description: the email subject
• Notes: a list of the names of any attachments
• Location: the practice location where the email was sent from
• Author: the logged in user
• Content: the body of the email, excluding attachments

Emailed Patient Documents

If an email is sent to containing one or more patient document as attachments, a log will be created with: 

• Type: Email
• Reason: Forwarded documents
• Customer: the owner of the patient
• Patient: the patient the documents belong to
• Address: the email address. This may not belong to the customer
• Description: the email subject
• Notes: a list of the names of any attachments
• Location: the practice location where the email was sent from
• Author: the logged in user
• Content: the body of the email, excluding attachments

SMS

When an SMS is sent to the customer, initiated from the customer summary or contacts, a log will be created with:

• Type: SMS
• Reason: Ad-hoc SMS
• Patient: the current patient, or none if no patient is selected or doesn't belong to the customer
• Address: the customer phone number
• Location: the practice location where the SMS was sent from
• Author: the logged in user
• Content: the SMS text

Configuration

Automatic logging will be enabled by a new Practice configuration option, Enable Communications Logging.

Archetypes

The following archetypes will be provided:

• act.customerContactLog - contains the log details.

Where the email content is too large to fit in the 5000 character string limit, a document will be stored instead.

• lookup.customerContactLogReason - the log reasons. The following will be provided:
  • AD_HOC_SMS
  • AD_HOC_EMAIL
  • PATIENT_REMINDER
  • FORWARDED_DOCUMENT

Migration

The existing:

• act.customerNote instances need to be migrated to act.customerContactLog
• lookup.customerNoteCategory need to be migrated to lookup.customerContactLogReason

Exclusions

• No logging will be performed during statement generation
• No reports will be provided as part of this project.
• No support will be provided to print individual log entries

This project will add a new flag to products, "Use Only in Templates".

This is designed to stop direct entry of products that should only be included in charges and estimates via a Product Template.

Any product with this flag set:

• will be excluded from queries during charging and estimating
• may not be entered into an invoice/estimate even if its full name is used
• may still be selected in supplier orders and deliveries

JIRA: OVPMS-1665

OpenVPMS uses a technique called optimistic locking to ensure that multiple users editing the same object don't overwrite each other's changes. If two users edit the same object, the first user to save wins, and the second user's changes are rolled back.

This project will:

• automatically save invoices, to limit data loss if two users edit the same invoice
• support reloading the invoice, if another user has edited it

This functionality will be available:

• in the Check-In, Consult, and Check-Out workflows
• when editing an invoice in Customer - Charges
• when invoicing an estimate
• when invoicing customer orders and returns

Invoices will be automatically saved when adding a new invoice item via the Add button.

Automatic save will be disabled if the invoice:

• is unsaved. This is to allow users to cancel editing a new invoice without having to subsequently delete the invoice from Customer - Charges
• status has been set to Finalised
• is invalid

Invoicing Estimates and Customer Orders/Returns

When invoicing estimates and customer orders and returns, the automatic save will only be enabled after all of the items have been invoiced. This is to allow the user to cancel invoicing without making any changes.

JIRA: OVPMS-1691

This project will provide enable Completed and Cancelled appointments to be displayed with strikethrough text. E.g.:

This will be configured on the Schedule View with a new flag named Use strikethrough for Completed/Cancelled. It will off by default.

JIRA: OVPMS-1639

This project will enable patient information to be sent to Smart Flow Sheet to reduce data entry.

Patient information will be sent:

• automatically when a checked-in patient is added or transferred to a worklist configured for Smart Flow Sheet
• by clicking on a Smart Flow Sheet button located on the Scheduling and Work Lists screens.

Check In Workflow

If a work list is selected during Check-In and it is linked to Smart Flow Sheet, the subsequent weight entry will trigger the patient information to be sent to Smart Flow Sheet. If Skip is pressed on the New Weight dialog, a warning will be displayed:

• If there is no patient weight - "This patient cannot be sent to Smart Flow Sheet as no weight is recorded. Are you sure you want to skip weight entry?"
• If there is a weight record (of any age) - "Smart Flow Sheet requires an accurate patient weight. Are you sure you want to skip weight entry?"

Smart Flow Sheet button

A Smart Show Sheet button will be added to the Scheduling and Work Lists screens if:

• Smart Flow Sheet is enabled
• an appointment/task must be selected, and the corresponding patient must have an In Progress visit

If the patient has no weight recorded against the visit, a patient weight dialog will be displayed. This will default to the patient's prior weight, if any.

If the patient has already been submitted to Smart Flow Sheet for the current visit, a warning will be displayed: "This patient has already been submitted to Smart Flow Sheet. Do you want to resubmit?"

Worklist Transfer

If a patient:

• is transferred to a worklist linked to Smart Flow Sheet; and
• has an In Progress visit; and
• there is a weight record linked to the visit; and
• the patient hasn't already been submitted

then their details will be automatically sent to Smart Flow Sheet.

If there is no current patient weight for the patient, this will be prompted for.

Configuration

The EMR and clinic API keys for Smart Flow Sheet will be configured on the Practice.

The Work List archetype will be extended to include a "Use Smart Flow Sheet" flag to indicate if patient information should be sent for the work list. It defaults to off.

Exclusions

This project will not support:

• receiving medical or charging records from Smart Flow Sheet
• submitting products or clinicians

These will be covered by a separate project.

JIRA: OVPMS-1653

By default, OpenVPMS supports starts-with matching when performing queries, i.e. it will return all results that start with the entered text.

To match everything containing the entered text, the user must remember to prefix it with a wildcard (* or %).

In general, starts-with queries are faster than contains queries as they can make better use of database indexes.

This project will make contains matching the default for queries that won't adversely affect performance.

This will apply to the following archetypes:

• products
• suppliers
• organisational archetypes  (i.e. everything found in Administration - Organisation)
• document templates
• lookups
• types (i.e. everything found in Administration - Types)
• HL7 services and connectors (i.e. everything in Administration - HL7)
• archetype descriptors (i.e. everything in Administration - Archetypes)
• user groups
• users
• roles

Configuration

The contains search will be enabled by configuring a flag within the QueryFactory.properties file for each of the relevant archetypes e.g.:

product.*       org.openvpms.web.component.im.product.ProductQuery,contains=true

This will default to false if not specified.