This project will add a new column to the patient medical records to display the clinician associated with a record.

This project arose from the situation where documents linked to products are all processed on commit of an invoice. 

This prevents letter documents being generated, as parameters cannot be prompted for.

When a document is selected that has a letter template with parameters, support will be added to pop up a dialog to prompt for the parameters.

If there is more than one letter with parameters, multiple dialogs will be displayed, one after the other.

JIRA: OVPMS-1074

This project will enable patient reminders to be included in customer invoices.

Forum: http://www.openvpms.org/forum/reminders-invoices

JIRA: http://jira.openvpms.org/jira/browse/OVPMS-1071 

Forum: http://www.openvpms.org/forum/medical-records-and-upgrade

Jira: https://openvpms.atlassian.net/browse/OVPMS-1069

The 1.5 upgrade introduced a change to the order of medical records in the summary display in that entries in a visit are now ordered in ascending rather than descending order.

Given there are different views on what order specific practices prefer it is suggested that a new option is added to the practice information to allow a default sort order of entries in visits to be specified (ascendin/descending).  

Also it is suggested that a button is added to the medical records summary workspace to allow this to be changed at will by the user.

It is suggested that thsi change, if funded, should go into the current 1.5 release.

Currently which products to order in order to maintain ideal stock levels is generated using the stock reorder report .  This report uses the stock onhand, critical and onhand levels for each product and stock location as well as the current onorder amounts to calculate how much of the product should be ordered. It uses the preferred supplier to ascertain from which supplier to purchase from.

Once this report is generated the user has to select the appropriate products they wish to order and use the Suppliers -> Orders workspace to enter the order manually. 

This project seeks to add a new feature where the orders are generated directly rather than via a report and by manual entry.  The proposed specification is as follows:

1. Add a New button in the Suppliers->Orders workspace called "Generate Orders"
2. When selected a new "Generate Orders" dialogue will appear.  You will have a choice to select a specific Stock Location or All as well as a specific Supplier or All.  You will also have an option to only generate orders for products below critical levels.  The dialogue will include a Generate and a Cancel button.
3. When the generate button is selected "In Progress" orders will be created for the selected suppliers and stock locations which have products that require ordering.  This will use the same order generation logic as the current Stock reorder report.

The user will be able to review and edit the generated orders in the Supplier -> Orders workspace and when ready finalise.  Finalisation will automatically dispatch orders electronically for those suppliers setup with ESCI services. Others can be printed by the user as required.

We look forward to user comments on this project and the proposed specification.

The JIRA is available here.

JIRA: https://openvpms.atlassian.net/browse/OVPMS-1000

When charging a product template during the check in and consulting workflows we need to support being able to automatically create visit and invoice notes assocaited with the product template. 

A JIRA has already been created for this project and an initial estimated of development costs included. Obviously should the specifications change the development hours may also change. 

This feature is dependent on the new Integrated Visit Editor project.

Currently the medical records and charging components of a typical visit are separated out into two different screens and essentially two different areas of the application.  The check-in and consulting workflow moves you sequentially between these functions but this does not suit the typical workflow habits of most veterinarians who like to be able to view clinical records, enter charges, enter clinical notes etc in no specific order.  So the medical records and charging components need to be merged into a single dialogue and used during the check in and consulting workflows.

Presently in the medical records view you do not see charges associated with a visit you only see dispensing(medication) information associated with charged medications.  There is a charges tab in Medical Records but these charges can not be separated by visit or even invoice. They just represent all the charges for a patient and can be sorted by date, clinician, type etc.  We need to be able to enter charges at the same time as medical records and also only see charges and totals for the current visit.

Charges should be visible on the medical records summary tab and associated with specific visits.  Previous visits which do not have any links between the actual visit and the charge can not show the charges in the summary of course.  The medical records filter should provide a means to filter charges in or out

Also during a typical consult it is important to be able to see and modify reminders, alerts and documents. The new interactive reminders in 1.5 help being able to modify reminders on the fly but during a consult it is nice to be able to display and modify /add the reminders and the products which are associated with them.  We need to display the reminder/alert tab in the integrated visit editor. We should also display the document tab.

One last but important feature relates to charging and visit status. Invoices can be In Progress, Hold, or Completed and this also changes appointment and task status displasy for workflow.  The Visit status on the other hand relates purely to whether the medical records entry has been completed and does not effect any of above status displays although the Visit Completed dat eis set when the status is updated.  I think we should still maintain the two but if the visit charges are marked as completed the visit status should also be changed to Completed.  This may stop some confusion.  Obviously when an invoice containing the visit charges is finalised the visit editor will not allow any changes or addiitons to these charges but will still display them. 

We have actually JIRA'd these initial specifications and provided an estimated cost to develop.  Obviously as the specifications are discussed and potentially modified the costs may change. 

We are looking forward to your input on this important project.

Tony

Forum: http://www.openvpms.org/forum/vaccination-due-date-merge-field

Jira: jira.openvpms.org/jira/browse/OVPMS-768

This project has been costed (19/11/10)

This will make the changes neccesary to allow users to add the next reminder due date for a patient to their patient forms.

Revision & change in costing to $850 (22/11/11)

The logic to be used in this feature will be the form will get the next due date as follows:

1. If there the form was generated when billing an item, it will use that item to get the reminder due date. If there are multiple reminders linked to the item, it will use the one with the nearest due date.

2. If the form was created directly (ie. Not automatically during billing), it will use the reminder with the nearest due date for the product in the Product field.

3. If the form doesn't fit either description above, no due date will be returned.

Fully funded (21/02/12)

Matt C
 

Revision 03/11/11

o        There was support for this feature.

o        However after discussion it was suggested this be moved back to Developer Review.

o        I have failed to record the issues raised that meant that it need Developer review but might have related to grouped reminders.

o        This project has been moved to Developer Review.

Editing documents in OpenVPMS is currently a laborious process as it involves downloading documents to the user's PC in order to edit them, followed by re-uploading to OpenVPMS.

This project will enable documents to be edited within OpenOffice, by providing a limited WebDAV service that allows OpenOffice to open an OpenVPMS document, edit it, and save it.

WebDAV resources are accessed by URL, so one can edit a WebDAV document in OpenOffice by using File -> Open, and specifying the URL. To simplify this, and remove the need to expose the URL to users, an External Edit button will be provided to launch OpenOffice when an appropriate document is selected.

The External Edit button will be available for editable documents in the following workspaces:

• Patient -> Summary
• Patient -> Medical Records -> Documents
• Customer -> Documents
• Supplier -> Documents
• Administration -> Templates

Editable documents

Letters, Attachments, Investigations and Images that have an attachment document in a Word/OpenOffice format are editable.
This includes the following archetypes:

• Patient Letter
• Patient Attachment
• Patient Investigation
• Patient Image (providing the content is a supported document type)
• Customer Letter
• Supplier Letter
• Customer Attachment
• Supplier Attachment

Non-editable documents

Documents that are generated on demand aren't saved and therefore cannot be edited. This applies to:

• Patient Form
• Customer Form
• Supplier Form

OpenOffice Launcher

When the External Edit button is clicked, this will trigger OpenOffice to be launched for the selected document using Java Web Start.

Note: if Web Start applications aren't signed, Java will prevent the application starting, and display a dialog "Java Application Blocked", with the message "Application Blocked by Java Security". To avoid this either:

• the application needs to be signed. This will require OpenVPMS purchasing a code signing certificate (and renew it yearly)
• users go into Java Control Panel and edit the Exception Site List to allow WebStart applications to be launched from their OpenVPMS server. This needs to be done per client machine.

Exclusions

The following won't be supported:

• Document versioning

Only the latest version may be edited

• Locking

The WebDAV protocol supports locking, to prevent two users editing the same document at the same time. This project will use optimistic locking instead, i.e. two users may edit the same document, but the first to save wins, and the second save is rejected.

• Editing using Microsoft Office

Microsoft Office supports WebDAV, but requires locking support. Without it, documents are opened read-only and cannot be saved back to the WebDAV server. This can be addressed in a subsequent project if required.

• Viewing documents via Windows Explorer and other WebDAV clients

This project will not expose collections of documents, so it will not be possible to browse available documents via Windows Explorer et al.

JIRA: OVPMS-976