VPMS Web Application

Tim suggested in forums:
"...For simple edits, would being able to edit directly in the table be simpler?

This would include things like changing strings, dates, checkboxes and single participations (e.g, patient, customer, etc)

You could still have the option of popping up an edit dialog for editing more complex nodes..."

I think this would be a great option. How much more information do you guys need to start thinking about a costing?

For the case where you just want to edit from a query list, much of the code is already in place.
I would estimate 2 hours + 1 hour for each workspace.

For the table editing approach, there is currently no support for this, and some archetypes lend themselves better to table editing than others.
(e.g archetypes with few or no relationships). To add support for table editing starts at 12 hours + 2 hours for each new workspace.

From a L&F perspective, do you want:

• a new workspace for for , e.g Customers -> Batch Edit, Patient -> Batch Edit
  Contains a query and browser which functions the same as the selection dialog but pops up an edit dialog when you select a row
• a new editable selection dialog, launched via a new button in the existing workspaces

Hi Tim,
I think a new editable selection dialog, launched via a new button in the existing workspaces would work best given the use cases raised from the users forum.

I think to start with the
Customer, Patient, Product, Template selection dialogs would be all that is required (any more Tony?).

Also can we have the selection dialog behaviour such that the previous search results are retained when brought back up. This allows sequential editing if desired.
The cursor focus ideally would be in the search string box (name) with previous text highlighted so a new search can be fired quickly and easily.

Cheers,
matt C

Hi Guys.
I would say the most important workspaces for this style of editing would be

Products
Organisation
Types
Lookups
Templates
Users

Not sure the use for Customers, Patients ?

The edit from a query list with appropriate filters is sufficient I believe.

Hi Tony,
I had forgotten some of the setup workspaces.

I think the advantage for customers (less so for patients) is when needing to jump into a series of customers. An example would be the search for a partial microchip or other identity. Currently the search needs to be re executed after entering each customer or patient.

The patient select dialog would get less use especially now that customer searching includes patient results. The circumstance it might be used is when searching using the All Patients option. The subsequent list may need to have different selections made multiple times.

Matt

Hi Guys,

Patients and Clients would definately be useful. Sometimes when recalling a case you can only recall certain details such as a surname or patient name. There may be multiple patients with the same surname and you need to enter into the record to check if it's the right one. Then if not go back to the list and check the next, etc, etc. So it definitely has it's purpose.

Another proposed workspace for this: archetypes.

Can I suggest we work on changing the workspaces mentioned above (including archetypes) and then raise a new JIRA for new workspaces to deal with batch editing of customers and patients ?

So to be clear, current list for new selection dialogs are;
Products
Organisation
Types
Lookups
Templates
Users
Customers
Patients
Archetypes

And a new Jira for batch editing of Customers and Patients?

Hi Matt,

This JIRA will be modified to relate purely to the workspaces mentioned above using the simple query list approach (option1) mentioned by Tim. We need to supply relevant query filter options for each workspace. i.e.

Product: Archetype, Product Type, Name
Organisation: Archetype, Name
Type: Archetype , Name
Lookups: Archetype, Name
Templates: template type, name
Users: name
Archetypes: name

A new JIRA will be added for batch customer editing as well as batch patient editing (separate).

Hi guys,
I have a user ready to fund this fully and get it underway but they have a request for a modification and given it is an addition rather then changing any of the existing spec, I thought I would ask here and get you to provide a revised time estimate Tim.

The request is to add a "Next" and "Previous" button to the editor that can move directly to the next or previous item in the query list. Is this possible?

Matt C

OK, there's a few requirements in here now.
1. a new editable selection dialog, launched via a new button in the existing workspaces

Button will be added to the following workspaces:

• Products
• Organisation
• Types
• Lookups
• Templates
• Users
• Customers
• Patients
• Archetypes
  Estimated time = 2 hours + 1 per workspace = 11 hours

2. "Next" and "Previous" button to the editor that can move directly to the next or previous item in the query list
Do you want it to go to the next page if there is one when you get to the end of a page, or cycle back to the top?
Esimtated time = 2 hours

3. Also can we have the selection dialog behaviour such that the previous search results are retained when brought back up. This allows sequential editing if desired.
The cursor focus ideally would be in the search string box (name) with previous text highlighted so a new search can be fired quickly and easily.

• Text highlighting is not supported by the echo web framework. Could add it, but requires creating a new text field. Need more investigation to determine timeframe
• Save query state : Estimated time = 1 hour per workspace = 9 hours

Thanks for this summary Tim.
I will update the development costing on the OpenVPMS website after tonights meeting.

Wrt point 3. The "Save Query State", I think what was meant by that was that the query list was still there after the user finished editing a selection and returned to the list. Is that what you mean by save query state?

Matt C

Misunderstanding on my part. I took it to mean that the previous query would be re-run if you open the editable selection dialog from the workspace.
If you are just talking about being presented with the same list of results in the selection dialog after you have edited an item, then that will be the default behaviour.

Great. That's what I thought!
Thanks.

Hi Tim,
This project can go ahead for points 1 & 2 as per follows:
1. a new editable selection dialog, launched via a new button in the existing workspaces

Button will be added to the following workspaces:

• Products
• Organisation
• Types
• Lookups
• Templates
• Users
• Customers
• Patients
• Archetypes
  Estimated time = 2 hours + 1 per workspace = 11 hours

2. "Next" and "Previous" button to the editor that can move directly to the next or previous item in the query list
Do you want it to go to the next page if there is one when you get to the end of a page, or cycle back to the top?
Estimated time = 2 hours

We have funding.

Thanks

Changes applied, but with different a implementation to that originally described.
The requirement:

1. a new editable selection dialog, launched via a new button in the existing workspaces

didn't work too well from a useability perspective.

It has been replaced with a query and browser within the workspace itself.
This allows:

• queries to be performed within the workspace without popping up a selection dialog
• the results of the query to be browsed, viewed and edited

Editing an row is done by clicking on it and selecting Edit.
This pops up a standard edit dialog, which also includes Previous and Next buttons to edit the previous and next row respectively.

The following workspaces have been updated to use this layout:

• Products -> Information
• Administration -> Organisation
• Administration -> Types
• Administration -> Templates
• Administration -> Users
• Administration -> Roles
• Administration -> Lookups
• Administration -> Authorities
• Administration -> Archetypes

The following workspaces have NOT been updated:

• Customers -> Information
• Patients -> Information
• Suppliers -> Information (not mentioned in the inital JIRA)

They are not amenable to the query/browser style of workspace.

Changes applied to vpms, revisions: 3790, 3794, 3798, 3803

Default double click behaviour should be edit not view mode.

Changes applied to vpms, revision 3949

Tested VPMS. OK.