Gribbles support for developing the 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.
Firstly, at a generic(not specifically Gribbles or just pathology labs) level to help us create a means of channelling any investigaions 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:
a) 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.
b) defining how these results would appear on histories and the sort of data that would be attached to the records (to possibly be availabe to tabulate in different forms, generate graphs etc)
c) 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!
Peter Gooey
Re: Gribbles support for developing the investigations module
Gee it's crook when you have to reply to your own posts!
Please let us know if you have any strong preferences regarding
the investigations module.
I have one question of Tony:
Currently we generate requests by billing specific tests through a
specific supplier - e.g. Gribbles FBE and I suspect it would be
relatively easy to incorporate this into the investigations module
however the ability to ask for multiple tests on one form and for the
relevant invoice items to be generated at the same time really appeals
to me. Do you see the amount of programming time being significantly
greater either one of these options?
Regards
Peter
Forum participation
Gee it's crook when you have to reply to your own posts!
But Pete, we don't see you much in the other posts!
Matt C
Re: Forum participation
On March 10th, 2009 PeterG says: Gee it's crook when you have to reply to your own posts! But Pete, we don't see you much in the other posts! Matt C _______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: //lists.openvpms.org/mailman/listinfo/users">http://lists.openvpms.org/mailman/listinfo/users Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- //tinyurl.com/openvfu">http://tinyurl.com/openvfu
No virus found in this incoming message. Checked by AVG - //www.avg.com">www.avg.com Version: 8.0.237 / Virus Database: 270.11.10/1995 - Release Date: 03/11/09 08:28:00Investigations module ideas
Hi Peter,
I think before being able to answer those sorts of questions we would need to have some understanding of the way requests are handled from both the users perspecitive and when they are received at the service provider (i.e Gribbles etc).
One idea is the entry of a investigation request in the patients clinical record would trigger the request workflow process including the billing. The issue is how do we define a request.
From the users perspective it may involve multiple tests from a predefined group of tests against multiple samples that eventually result in one or more reports.
From the service providers perspective they may break thsi down into a request per sample, test battery group etcto facilitae their workflow and internal reporting systems. I would assume that much of the internal management of performing and reporting the tests would be hidden from the user and in reality the results would be cummulated and delivered as a single report. Still I think there would defined groups of tests that are able to be included on a single request and these groups may be specific to the servcie provider.
From the application perspective it is probably thinking each request has a single form to print and results in a single report being returned. The report may start off being preliminary i.e partial results or preliminary results but would eventually be final and include all the results for the requested tests. If the process is being triggered from a individual billing item then it would assume that this item would be associated with one request and one form. If the process is triggered through adding an investigation entry in medical records then I could see we could define supplier specific investigation types each of which could generate a specific form and which could create multiple billing items.
I like the second approach becuas eit is more flexible and makes logical sense to me as an analyst but this may not be the way users like to think which is the most important thing in the design.
Anway in order to get the design ball rolling I will put forward a preliminary design and wait for critical comment :-)
1. Each practice can define as many investigation types as they like. An Investigation type is defined as a group of tests requested against a specific supplier (service provider). I think sometimes these may be called test profiles ??
2. The Investigation type will link to a template which represents the form to be printed when the request for this investigation type is made. The template in this case represents the standard physical form with all the fields filled in and the relevant tests ticked/marked.
3. The Investigation Type will also include a description and include sample information to be displayed when the investigation type is selected or listed for selection.
4. The Investigation type will link to one of more products and include qty information (a lot like Templates or could even link to a template). When a request is made these products wil be billed against the patient in an existing or new In Progress invoice.
5. To request an Investigation the user would add a new Investigation to the visit, select the investigation type, Print the associated form which will incldue a unique request identifier (prompted with option to reprint), displays the sampling information and generates any charges. The request will be marked as in progress. NOTE: The idea here is in Clinical Records there will be just one Investigation selection and the type of investigation (Pathology, Radiology etc) would be selected in the entry. The ramification is when filtering clinical records for display you can only filter Investigations not the individual types as present. Not sure if this is a big issue but speak up if it is ...
6. The request form with the associated sample are dispatched manually to the provider.
7. The new Investigation workspace (In workflow area) will allow you to display all in progress requests including investigation type, patient, date, provider, status etc.
The next stage is the receipt of investigation results. Obviosuly results received manually by fax or email attachmnet can be scanned or attached directly to the investigation entry. Version 1.3 now includes an utility application that can scan a specific folder for files with a numeric file name and use the filename number to attach the files to the corresponding unique customer atatchment, patient attachment or investigation entry. At the same time it will change the status on the entry to Completed (Arrived). In this way we can accomodate a wide variety of existing electronic download mechanisms including internal test equipment , Eclinic used by Gribbles and ASAP and other download applications.
As investigations are received you can then use the Investigations workspace to monitor them , view the results etc. The results will also be available in the clinical records attached to the investigation request you added to the visit.
There are some other features that would be worth considering either now or options for later enhancements:
1. Electronic requests. Rather than or most likely in conjunction with the printing of a request form, the request coudl be sent electronically to the provider. Gribbles already provide thsi functionality for Medical Practices through ERequest. Woudl require some thought on hwo to provide differeent interfaes for different providers but definitely possible.
2. Investigation Workflow. Options in the investigations worklfow module to allow clinicians to mark investigations as seen, actioned, client contacted etc. Also clinican communication options as described by Matt but driven by the Investigation workspace rather than through work lists.
3. Supplier Investigation downloads. Ability to import available Investigation Types from the Suppliers including request templates.
These are only one persons ideas and I welcome critical comment and other ideas that may work better from the users perspective ..
Cheers
Tony
Re: Investigations module ideas
Hi Peter, I think before being able to answer those sorts of questions we would need to have some understanding of the way requests are handled from both the users perspecitive and when they are received at the service provider (i.e Gribbles etc). One idea is the entry of a investigation request in the patients clinical record would trigger the request workflow process including the billing. The issue is how do we define a request.
PG: in fact in our experience there is a little of both. Mostly we order profile groups which might include multiple biochemistry, lectrolytes and haematology examinations on samples of blood in different container types. These may be combined with other more specific tests but more often if we want a specific test done e.g. Free T4, Phenobarb levels they will be single requests for single services. I'm guessing htat the labs are well set up for receiving and processing multiple bottles for profile groups - this would be in favour of generating requests at the time of invoicing. The second approach has the advantages you mention as well as the workflow efficiency of generating and printing the form in one step rather than going back into a history after invoicing to print the form. however it may force compromises of a different kind. My understanding is that labs would normally expect a separate request form for each sample submitted within this system. Thus if we wanted a multiple biochemical analysis plus haematology we may have to create two investigation requests. Is that correct Tony? Perhaps they can still treat grouped tests as a single investigation? Overall I think I could get to like the visit-based request generation if we could work around some of these issues.
cite="mid:listhandler=1&site=www.openvpms.org&nid=734&pid=0&cid=1155&uid=500&tid=64&90fea3415bc379e48e3d76bcdb797655@www.openvpms.org" type="cite">I like the second approach becuas eit is more flexible and makes logical sense to me as an analyst but this may not be the way users like to think which is the most important thing in the design. Anway in order to get the design ball rolling I will put forward a preliminary design and wait for critical comment :-) 1. Each practice can define as many investigation types as they like. An Investigation type is defined as a group of tests requested against a specific supplier (service provider). I think sometimes these may be called test profiles ?? 2. The Investigation type will link to a template which represents the form to be printed when the request for this investigation type is made. The template in this case represents the standard physical form with all the fields filled in and the relevant tests ticked/marked.
PG. What I would really like would be to have relevant history inserted into the form at this point. It could be as simple as having a space to cut and paste text or possibly a much more elegant solution.
cite="mid:listhandler=1&site=www.openvpms.org&nid=734&pid=0&cid=1155&uid=500&tid=64&90fea3415bc379e48e3d76bcdb797655@www.openvpms.org" type="cite">3. The Investigation Type will also include a description and include sample information to be displayed when the investigation type is selected or listed for selection. 4. The Investigation type will link to one of more products and include qty information (a lot like Templates or could even link to a template). When a request is made these products wil be billed against the patient in an existing or new In Progress invoice. 5. To request an Investigation the user would add a new Investigation to the visit, select the investigation type, Print the associated form which will incldue a unique request identifier (prompted with option to reprint), displays the sampling information and generates any charges. The request will be marked as in progress. NOTE: The idea here is in Clinical Records there will be just one Investigation selection and the type of investigation (Pathology, Radiology etc) would be selected in the entry. The ramification is when filtering clinical records for display you can only filter Investigations not the individual types as present. Not sure if this is a big issue but speak up if it is ...
PG. I don't think this would worry me
cite="mid:listhandler=1&site=www.openvpms.org&nid=734&pid=0&cid=1155&uid=500&tid=64&90fea3415bc379e48e3d76bcdb797655@www.openvpms.org" type="cite">6. The request form with the associated sample are dispatched manually to the provider. 7. The new Investigation workspace (In workflow area) will allow you to display all in progress requests including investigation type, patient, date, provider, status etc.
PG. A means of tracking sample progress and resut communication is essential to this module
cite="mid:listhandler=1&site=www.openvpms.org&nid=734&pid=0&cid=1155&uid=500&tid=64&90fea3415bc379e48e3d76bcdb797655@www.openvpms.org" type="cite">The next stage is the receipt of investigation results. Obviosuly results received manually by fax or email attachmnet can be scanned or attached directly to the investigation entry. Version 1.3 now includes an utility application that can scan a specific folder for files with a numeric file name and use the filename number to attach the files to the corresponding unique customer atatchment, patient attachment or investigation entry. At the same time it will change the status on the entry to Completed (Arrived). In this way we can accomodate a wide variety of existing electronic download mechanisms including internal test equipment , Eclinic used by Gribbles and ASAP and other download applications. As investigations are received you can then use the Investigations workspace to monitor them , view the results etc. The results will also be available in the clinical records attached to the investigation request you added to the visit. There are some other features that would be worth considering either now or options for later enhancements: 1. Electronic requests. Rather than or most likely in conjunction with the printing of a request form, the request coudl be sent electronically to the provider. Gribbles already provide thsi functionality for Medical Practices through ERequest. Woudl require some thought on hwo to provide differeent interfaes for different providers but definitely possible.
PG. This might be where we will differ from the medicos. Mostly doctors generate requests for services through a particular laboratory to whom the patient will often go to have the sample taken. It's hard to believe there isn't some form of hard copy printed (even a bar code sticker) to allow accurate tracking of samples. At the moment I think a form that can accompany the sample seems pretty essential.
cite="mid:listhandler=1&site=www.openvpms.org&nid=734&pid=0&cid=1155&uid=500&tid=64&90fea3415bc379e48e3d76bcdb797655@www.openvpms.org" type="cite">2. Investigation Workflow. Options in the investigations worklfow module to allow clinicians to mark investigations as seen, actioned, client contacted etc. Also clinican communication options as described by Matt but driven by the Investigation workspace rather than through work lists.
PG. The worklist solution works very well but an investigation workspace with these features would be very good too. My only thought is that clinic personnel will typically work within a particular workspace depending on their role and that the more information that they need that fits onto their workspace the better, assuming it doesn't get too cluttered.
cite="mid:listhandler=1&site=www.openvpms.org&nid=734&pid=0&cid=1155&uid=500&tid=64&90fea3415bc379e48e3d76bcdb797655@www.openvpms.org" type="cite">3. Supplier Investigation downloads. Ability to import available Investigation Types from the Suppliers including request templates.
PG. That would be great!
cite="mid:listhandler=1&site=www.openvpms.org&nid=734&pid=0&cid=1155&uid=500&tid=64&90fea3415bc379e48e3d76bcdb797655@www.openvpms.org" type="cite">These are only one persons ideas and I welcome critical comment and other ideas that may work better from the users perspective .. Cheers Tony _______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: //lists.openvpms.org/mailman/listinfo/users">http://lists.openvpms.org/mailman/listinfo/users Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- //tinyurl.com/openvfu">http://tinyurl.com/openvfu
No virus found in this incoming message. Checked by AVG - //www.avg.com">www.avg.com Version: 8.0.237 / Virus Database: 270.11.9/1992 - Release Date: 03/09/09 19:20:00Investigation types
Hi,
These comments refer to details within Tonys last comment.
For those of you reading these posts only through your email reader, read it here www.openvpms.org/forum/gribbles-support-developing-investigations-module#comment-1155
Investigation types:
Most of the "profiles" that we use that are comprised of multiple tests (eg. Old dog profile) still relate to a single item in a catalogue of services that the labs provide us with. The services usually have unique numbers. Within this single entities there are multiple test requests that I assume are expanded when they are recieved at the labs end.
For familiairty and simplicity as an end user, I would seek to keep a one-one relationship with these services at our end when instigating an Investigation request. By that I mean that "Investigation Types" = Item in Catalogue of Services from Lab.
So when I come to add an Investigation to my medical record, I choose from a list of Investigation Types that correspond to individual services from the lab provider. eg. "Manky Old Dog Profile". Furthermore this would directly relate to a single OpenVPMS Product (Type:Service) used for billing.
Another benefit of keeping a direct relationship with a labs catalogue of services, is that we could include them in the automatic price updating in the future (See Tonys comments about "Supplier Investigation downloads").
Where I see some complexity coming in, is when I want to do 2 seperate services on the same lab request form? For example I want a "Manky Old Dog Profile" and a "Total T4". Currently we generate one form and tick 2 boxes. Would we need to generate two seperate forms? Or could the process;
a) Allow a user to choose one or more items for a single investigation.
b) Create a template request document that contains a list of the services requested with unique identifiers for the lab.
Another idea would be how do we include other types of information classically provided on the request forms. A non exhaustive list;
a) Marking biopsy sites on a diagram of an animal.
b) Specifying specific sample states. eg Fasted/NonFasted
c) Marking the type and number of sample tubes provided
d) Time of collection (not always the time of requesting)
e) Notes
I think for the a) & b) they are examples of where the mighty pen which probably be retained. (How does eRequest handle them?). Different labs might request different details in this respect, so building such details into the "Request an Investigation" process in medical records might be tricky. This is alluded to in Tonys comments about electronic requesting.
But as Notes are ubiquitious, I think that the ability to add that during the request process would be terrific. Either through a pop-up dialog or other.
Lastly (for now),
I would think that the Investigations section would definitely need status based listing.
ie. Requested -> Received (Interim) -> Received (Completed) -> Client Contacted -> Completed
Furthermore that the list in Investigations would be sorted by Date or even better, automatic date based status. What I mean here is this;
a) Lab provides or clinic enters for each Investigation Type an expected turn around time.
b) If the interval has expired, the status of the Investigation changes from Pending/Requested to Overdue. Using our colour schemes in OpenVPMS could alert clinicians to investigate why theis has occurred.
Thats all for now.
Thanks Gribbles by the way for facilitating this process
Investigation Types
Hi Matt,
Thanks for the comments.
In regards a one to one relationship between investigation type and billing item I think may not be flexible enough for all Investigation types. Remember this module shoudl be designed for both external and internal investigation suppliers. Say for example the same process was being used in a hospital to request and monitor internal radiology requests. The ability to specify one or more billing items may give you flexibility to add both the radiology service and a number of plates ?
Either way having one or more billing items associated with a Investigation Type is probably inmaterial from a development perspective.
The issue regarding requesting two different services on the same request is very dependent on how the lab wants to receive these requests and how it sends the subsequent report. I believe we still need to maintain the one to one relationship between Investigation Request and Report for the process to work. Also If each combination of tests is represented by it's own Investigation Type and hence template then this fits with the current design.
If you want popup options based on Investigation type and these then used to populate the template (and subsequent electronic request) then we need to include some greater configuration options in the Investigation Definition. At the same time I would assume this would require some link between the selected tests and the billing item(s). This appraoch would minimise the combinations of tests you would need to define Investigation Types and hence templates for. It would also allow you to define mappings to the supplier test identifier for subsequent electronic requests.
In regards other form information I think most (except the drawing ones) can be accomodated using our standard template user fields which will popup to request user input and merge results into form.
So do you think we need to change the design to accomodate the following
Cheers
Tony
Investigation Types
Hi Tony,
I see your point. As you say, whether a request relates to a number of billed items or not is only really a user issue when setting it up and then it allows much greater flexibility. In terms of the ease of user for the vet when adding the request, there is no difference.
I agree with all of these;
I wonder about the quantities bit tho. Its definitely needed, (whether it is set to 1 unit or not) but will templates be able to designed in advance with quantities in mind? Will users in future want the ability to set quantities for the associated billed items at creation of the investigation request?
Re: Investigation Types
I was thinking about billing quantities for invoices not quantities of tests ...
Cheers Tony
On 12/03/09 12:17 PM, "Mpcosta@Boroniavet. Au" :
> Hi Tony, > I see your point. As you say, whether a request relates to a number of billed > items or not is only really a user issue when setting it up and then it allows > much greater flexibility. In terms of the ease of user for the vet when adding > the request, there is no difference. > I agree with all of these; > > Supplier can have multiple investigation types > Each Investigation Type can have mutliple selectable tests. > Each Investigation Type has a Template form that merges request, patient > and selected test information as well as prompted user fields. > Each Test has one or more associated billing items (and quantities). > > I wonder about the quantities bit tho. Its definitely needed, (whether it is > set to 1 unit or not) but will templates be able to designed in advance with > quantities in mind? Will users in future want the ability to set quantities > for the associated billed items at creation of the investigation request? > _______________________________________________ > OpenVPMS User Mailing List > users@lists.openvpms.org > To unsubscribe or change your subscription visit: > http://lists.openvpms.org/mailman/listinfo/users > Posts from this mailing list can be viewed online and replied to in the > OpenVPMS User's forum- http://tinyurl.com/openvfu_______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: http://lists.openvpms.org/mailman/listinfo/users Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- http://tinyurl.com/openvfu
Good on you Gribbles
We would undoubtedly do more path thru Gribbles when this is completed