This is my frst contribution to the Investigations group.
In discussions with Tony and Noam (from ASAP) I learnt that the via the use of a unique ID, incoming lab files can be dropped into a nominated folder and via a utility automatically uploaded into Open VPMS.
This ID relates to a unique id that is created when a document is created. The idea would be to create this document placeholder in the patients history, view the ID, then use that ID as the request number for the lab. When the lab comes back, the ID is used to match the lab file with the document and hey presto! the lab is is now in the patients history.
This is great but does not match what we do currently using some stand alone scripting.
In my experience the automatic attachment of lab results is only one required step in this process. The requirements for lab handling are far mor pressing in the context of a veterinary clinic. What I'm talking about here can be explained using our current system of lab handling.
In our clinic the process happens as follows;
1. The lab is billed.
2. This automatically creates a lab request form (using patient id at the moment).
3. There is a task automtically created at a defined period in the future (3 working days at present).
This task has relationships to the clinician, patient and customer.
The worklist it uses is called "Pending lab results"
4. Every day a script checks the tasks in this list and sends a reminder in the form of a OpenVPMS msg to the clinician who billed the lab to call the lab and get the result or to
"Complete" the task (they often forget).
5. After 6 days, msgs start getting sent to a lab administrator saying someone is not handling their labs.
6. The lab is returned via email.
7. A script matches the lab to the patient, attaches it to a new visit and creates another task in a "Returned Lab results" tasklist.
8. A msg is sent to the clinician.
9. The clinician Completes the "Pending lab results" task.
10. The clinician speaks to owner.
11. The clincian Completes the "Returned Lab results" task.
This seems heiniously complicated but it actually works quite well.
It could be vastly improved if we didn't use stand alone scripts.
Essentially what i could summarise it down to would be;
1. Billed items can be linked to the creation of task types in the Investigations module.
2. Investigation acts are linked to patients/customers/clinicians.
3. Investigation acts have the statuses: Pending / Overdue / Returned / Completed
4. Integrated msging for those tasks that are overdue.
This week Tony and I have had discussions with Liz Walker, General Manager of one of our founding sponsors, Gribbles Veterinary Pathology as well as Gavan Lim Joon, leading developer of Eclinic who provide information exchange services to Gribbles.
Gribbles are very keen to help us develop our investigations module at two levels.
Firstly, at a generic(not specifically Gribbles or just pathology labs) level to help us create a means of channelling any investigations data in and out of OpenVPMS in the form of service requests and incoming results. In this phase we will need to discuss precisely the sorts of issues that Matt mentioned in his previous post so that we can develop a set of requirements that suit us all. we will then be able to get Tony to estimate the cost of Tim doing this work. Liz has indicated that Gribbles would be happy to fund this development on our side of the process. Issues that have been raised include:
defining how the system would recognise the difference between interim and final results when linked to the unique ID number system so that we only have the relevant results attached to histories.
defining how these results would appear on histories and the sort of data that would be attached to the records (to possibly be available to tabulate in different forms, generate graphs etc)
how requests would be generated from a consultation event. Currently at BVC we achieve this by having invoicing codes that correspond to specific tests and which attach a generic request form with the owner details and patient id (but which might eventually be used to populate an electronic request with this detail and some case history). Another possibility is that by triggering a pop-up pathology request from at the history-taking stage we would be able to select the required tests and have this generate the appropriate invoicing items at the billing stage.
Secondly, Eclinic, on behalf of Gribbles would develop the means of Gribbles processing requests generated by OpenVPMS and sending results back. Their aim will be to integrate their HL7 data and utilities into OpenVPMS to allow clinicians to not only receive results but to have feedback information on processing status etc.
We are really privileged to have people like Liz and Gavan involved in getting this process moving and it is really important that every user takes this opportunity to have some input as to how it will work. We would like to have some firm ideas in place by the 15th March to allow Tony to cost it out for Gribbles.
This is your big opportunity to have a say in making things work in the best possible way so please don't waste it!
Submitted by Matt Young on Thu, 05/03/2009 - 22:13.
Hi to members of the investigation module group for OpenVPMS.
Unfortunately, prior to now there were some issues with email notifications of new posts to this group not being sent out. This has now been corrected. There are a couple of comments in this thread which you may wish to read. Things are progressing on work on this module so please take the time to visit the group area and have your say.
Those on the user's mailing list may have seen a post from Peter Gooey today about this.
If you want to manage your subscriptions to the group login and visit your account on the site.
Posts to the group can only be made by members of the group either by commenting on posts already on the group home page (http://www.openvpms.org/investigation-module) or by creating an "investigation module page".
Please let me know if you are having any issue with the site itself,
Matt Young.
OpenVPMS site administrator.
It concerns the linkage between billing items and the creation of lab request forms and also the "act" that will follow the whole process of sending, receiving and reporting lab results.
So this is the link between billing and investigation act creation.
If I can break down the steps:
1. User bills product linked to Investigation type.
2. Form created, printed and sent with unique document_act or ibvestigation_act id as lab request number.
3. Lab result returned via electronic means
4. Scheduled import into Investigations and updating of the investigation status.
This JIRA concerns step 1. Is that correct Tony?
Questions:
a) So will the Investigations workspace list the Investigations filtered by status and clinician?
b) Will it be possible to have statuses configurable?
eg. We might want "Message Left", "Interim result" or "Left for Dr" but others probably wont want the same statuses as us.
c) Could an Investigations list be a Worklist -> and therefore incorporated into a Worklist_View?
d) Could the clinician be messaged that one of their labs has returned?
Classically this returns an intial fluid analysis then a cytology result. These will likely be quite different pathologists. Furthermore, culture may then be performed. 3 communications in total.
We could imagine that in this scenario that the number of expected results might be entered in the lab request defintiionbut in the next 2 examples this is not possible.
2. Uncertain number of results
Culture and sensitivity could return multiple results. It is not possible to know how many results will be returned.
3. Additional testing
A pathologist may send an initial result and unexpectedly further testing may be required.
Should all results that come back with the same request number just get appended to the existing lab document? Should the returned lab result be able to be determined as Interim rather then Final?
Curious to see how this issue is resolved in e-clinic transactions.
My understanding is that in regard to the number of results expected
for any particular submission the laboratory (as they do now) would tag
results sent as either interim or final. I would be interested if Liz
or Gavan (eClinic) could comment on this but it seems to me that status
would be best generated by the labs and mediated through something like
theHL7 protocol that eClinic uses.
As far as extra tests are concerned, these would be billed out and we
would have the opportunity to generate additional requests (and request
numbers) at that time. It would seem to me that handling the next group
of tests in this way rather than creating exceptions to the rule
(here's a new submission but keep the old submission number) might be
simpler with respect to programming.
Submitted by Liz Walker on Sat, 05/09/2009 - 10:28.
Hi Tony,
Thanks for your time on the phone just now. Gribbles is delighted to contribute the $1980.00 required to complete the work on OpenVPMS which will allow the Act No to automatically populate the path request form (as well as running the billing automatically as well).
Once this is complete, as discussed, we would like to arrange a time for our two Client Service Managers and me to see a demonstration of the system working!
Comments
The use of document acts and how it relates to our workflows
Hi everyone,
This is my frst contribution to the Investigations group.
In discussions with Tony and Noam (from ASAP) I learnt that the via the use of a unique ID, incoming lab files can be dropped into a nominated folder and via a utility automatically uploaded into Open VPMS.
This ID relates to a unique id that is created when a document is created. The idea would be to create this document placeholder in the patients history, view the ID, then use that ID as the request number for the lab. When the lab comes back, the ID is used to match the lab file with the document and hey presto! the lab is is now in the patients history.
This is great but does not match what we do currently using some stand alone scripting.
In my experience the automatic attachment of lab results is only one required step in this process. The requirements for lab handling are far mor pressing in the context of a veterinary clinic. What I'm talking about here can be explained using our current system of lab handling.
In our clinic the process happens as follows;
1. The lab is billed.
2. This automatically creates a lab request form (using patient id at the moment).
3. There is a task automtically created at a defined period in the future (3 working days at present).
This task has relationships to the clinician, patient and customer.
The worklist it uses is called "Pending lab results"
4. Every day a script checks the tasks in this list and sends a reminder in the form of a OpenVPMS msg to the clinician who billed the lab to call the lab and get the result or to
"Complete" the task (they often forget).
5. After 6 days, msgs start getting sent to a lab administrator saying someone is not handling their labs.
6. The lab is returned via email.
7. A script matches the lab to the patient, attaches it to a new visit and creates another task in a "Returned Lab results" tasklist.
8. A msg is sent to the clinician.
9. The clinician Completes the "Pending lab results" task.
10. The clinician speaks to owner.
11. The clincian Completes the "Returned Lab results" task.
This seems heiniously complicated but it actually works quite well.
It could be vastly improved if we didn't use stand alone scripts.
Essentially what i could summarise it down to would be;
1. Billed items can be linked to the creation of task types in the Investigations module.
2. Investigation acts are linked to patients/customers/clinicians.
3. Investigation acts have the statuses: Pending / Overdue / Returned / Completed
4. Integrated msging for those tasks that are overdue.
Cheers,
Matt C
Gribbles support for Investigations Module
Hi All,
This week Tony and I have had discussions with Liz Walker, General Manager of one of our founding sponsors, Gribbles Veterinary Pathology as well as Gavan Lim Joon, leading developer of Eclinic who provide information exchange services to Gribbles.
Gribbles are very keen to help us develop our investigations module at two levels.
We are really privileged to have people like Liz and Gavan involved in getting this process moving and it is really important that every user takes this opportunity to have some input as to how it will work. We would like to have some firm ideas in place by the 15th March to allow Tony to cost it out for Gribbles.
This is your big opportunity to have a say in making things work in the best possible way so please don't waste it!
Peter Gooey
Problems with email notifications in the investigation group.
Hi to members of the investigation module group for OpenVPMS.
Unfortunately, prior to now there were some issues with email notifications of new posts to this group not being sent out. This has now been corrected. There are a couple of comments in this thread which you may wish to read. Things are progressing on work on this module so please take the time to visit the group area and have your say.
Those on the user's mailing list may have seen a post from Peter Gooey today about this.
If you want to manage your subscriptions to the group login and visit your account on the site.
Posts to the group can only be made by members of the group either by commenting on posts already on the group home page (http://www.openvpms.org/investigation-module) or by creating an "investigation module page".
Please let me know if you are having any issue with the site itself,
Matt Young.
OpenVPMS site administrator.
New JIRA for investigations project
Hi everyone,
A new JIRA has been created related to the Investigations project.
JIRA 884
It concerns the linkage between billing items and the creation of lab request forms and also the "act" that will follow the whole process of sending, receiving and reporting lab results.
So this is the link between billing and investigation act creation.
If I can break down the steps:
1. User bills product linked to Investigation type.
2. Form created, printed and sent with unique document_act or ibvestigation_act id as lab request number.
3. Lab result returned via electronic means
4. Scheduled import into Investigations and updating of the investigation status.
This JIRA concerns step 1. Is that correct Tony?
Questions:
a) So will the Investigations workspace list the Investigations filtered by status and clinician?
b) Will it be possible to have statuses configurable?
eg. We might want "Message Left", "Interim result" or "Left for Dr" but others probably wont want the same statuses as us.
c) Could an Investigations list be a Worklist -> and therefore incorporated into a Worklist_View?
d) Could the clinician be messaged that one of their labs has returned?
e) How will Step 3 above work?
Cheers,
Matt C
Investigation module: Interim results
Hi everyone,
Just an issue that is worth considering.
Some lab results will be sent in multiple parts.
Here are some case scenarios:
1. Combined testing
CSF Tap
Classically this returns an intial fluid analysis then a cytology result. These will likely be quite different pathologists. Furthermore, culture may then be performed. 3 communications in total.
We could imagine that in this scenario that the number of expected results might be entered in the lab request defintiionbut in the next 2 examples this is not possible.
2. Uncertain number of results
Culture and sensitivity could return multiple results. It is not possible to know how many results will be returned.
3. Additional testing
A pathologist may send an initial result and unexpectedly further testing may be required.
Should all results that come back with the same request number just get appended to the existing lab document? Should the returned lab result be able to be determined as Interim rather then Final?
Curious to see how this issue is resolved in e-clinic transactions.
Matt C
Re: New or updated comment for Page: Requirements
My understanding is that in regard to the number of results expected
for any particular submission the laboratory (as they do now) would tag
results sent as either interim or final. I would be interested if Liz
or Gavan (eClinic) could comment on this but it seems to me that status
would be best generated by the labs and mediated through something like
theHL7 protocol that eClinic uses.
As far as extra tests are concerned, these would be billed out and we
would have the opportunity to generate additional requests (and request
numbers) at that time. It would seem to me that handling the next group
of tests in this way rather than creating exceptions to the rule
(here's a new submission but keep the old submission number) might be
simpler with respect to programming.
Peter
vetmpcosta wrote:
type="cite">
Requirements
Hi Matt,
The JIRA actually covers steps 1 and 2. Steps 3 & 4 are already working in version 1.3.
Cheers
Tony
Re: New or updated comment for Page: Requirements
P Please consider the environment before printing this message
>>> tony <admin@openvpms.org> 23/07/2009 8:30 am >>>