Dicom Modality Worklist development.
Recently I received an interesting email from Matt Wright of Animal Insides (a prominent teleradiology service in the US) discussing the use of Dicom Modality worklists. For more info see http://www.animalinsides.com/content/view/283/84/
Basically, it is utilising your practice management software (openvpms) to populate the dicom (dicom compliant imaging device such as CR, DR, CT and modern ultrasounds) device with the patient and study details to minimise mistakes and duplication. This would also refine the recall of the images as a query and retrieve of the images from within the practice management software may be possible.
Is anyone interested in this concept - I would help support developing this part of the program if the community feels it may be of benefit.
Sam
DICOM functionality
Hi Sam,
This is real exciting stuff. Its application is very wide and would particularly suit large scale practices. We are only just now enjoying the merits of digital radiography and soon will integrate our ultrasound into our open source PACS and a way to link in our patient data would be very nice.
I see it being a real feather in the OpenVPMS cap if it could become a reality.
Am I right in saying that the features of such integration are largely already defined by the DICOM opensource standard? If so creating a specification (list of requirements) might be quite straight forward.
Another question I have is whether the simple task of sharing patient information could be acheived and then later built on for large scale practices who might want integration of billing data and other integrations seen in human hospitals and imaging centers?
Great to bring this up Sam!
Matt C
Re: Dicom Modality Worklist development.
_______________________________ Craig Challen Vetwest Animal Hospitals
Re: Dicom Modality Worklist development.
In this way there would be no need to import actual images into the Investigation Request (in essence duplication) as OpenVPMS could recognise Investigation Types with PACS links and query the configured PACS for the image when requested by the user, download the DICOM content and pass to your favourite DICOM viewing application. This would all be seamless as it could use the unique request id (accession number) and other details OpenVPMS already has access to.
Just a note to those who are thinking about Digital X-Ray equipment and integration. There are some great open source projects available to help integrate your Digital X-Ray equipment into your overall I.T. Infrastructure. This is an area that is often forgotten by the X-Ray equipment provider and an important consideration when purchasing this equipment. I have installed and configured these at 5 of my customers sites and they all appear to be working very well.
Cheers Tony
Dicom Modality Worklists
Good to see that this project may have legs. I spoke with my vendor (Fuji) and we already have the Modality Worklist option available in our software however it is an optional extra. Thanks to Tony for the advice to check at purchase time for those considering new systems. It appears that there is already an emerging standard for worklists amongst the major vendors and the main job will be to develop OpenVPMS to meet these standards.
Tony and Matt can you clarify the practical side of the process - here is my understanding using CR as an example:
Thanks to Craig indicating his practice would like this feature. I am happy to support the development of this feature and would like advice how to get it to the development stage.
Thanks for your comments
Sam
Dicom Modality Worklist
Hi Sam,
We would have to work through all the use cases but the basic concept would build on the existing Investigation Management workflow we have already developed which can link Investigations to biling items and provide work lists detailing the status investigations by type, date, status etc.
I think we would need to extend the Investigation Type's to support DICOM integration. Essentially the Investigation type would have extra setup information including whether or not you want DICOM MWL integration and then information about the MWL SCP server you wish to utilise for this investigation type. It would allow you to set a Modality for this Investigation Type.
I was thinking the existing notes area may be sufficient for describing views etc although we could provide a lookup of views in the Investigation dialogue if required.
Another configuration option in the Investigation Type would be if you want Dicom SCP/SCU integration. i.e do you want to be able to retrieve the DICOM image(s) from the PACS server directly as discussed above. This would not preclude using your favourite DICOM viewer application directly with the Pacs but would allow you to directly view images while you are viewing the patients clinical records without the need for a search. The unique investigation acession number would allow this to happen.
Now as OpenVPMS is a web application the images would be downloaded and then the browser could be configured to bring up Osirix, Kpacs, Clear Canvas or whatever. In your case if you are using Osirix then you just need to run OpenVPMS from a browser on your Mac and configure Safari, Firefox whatever to utilise Osirix when you download dicom content. If you are running OpenVPMS on a TS session on your windows server you would need to have a windows compatible viewer. Obviously java based viewers wouldl operate on any platform :-)
Th eother functionality that woudl be good to implement is MPPS support allowing imaging request status to be integrated between OpenVPMS, the Pacs and the Modality. This would allow a user of OpenVPMS to see if a request is in progress, Discontinued or Completed in the Investigation worklist as well as allow them to Cancel a request and have this reflected at the Modality and PACS. Obviously thsi requires a PACS/Modality with MPPS support although some PACs systems provide what they call MPPS emulation. With this when a image is received and after some timeout of not receiving another image they send off a MPPS Completed update. Thsi may be quite handy.
Anyway lots to talk about.
BTW I have invited Matt Wright from the article you mentioned to be involved in the discussions. He obviously has far more experience in these issues and would provide some great feedback.
Cheers
Tony
Re: Dicom Modality Worklist
Hey guys,
A few points that have occurred to me. A lot of abbreviations here. I'll try and keep up!
I have started linking billed XRAY items to a 3rd party task list to automate the regulatory requirement of recording exposure factors and have made the following observations.
a) The relationship of billed item and exposures is a one-many. In other words we might bill a single XRAY STIFLE that includes 2 standard views and maybe an incidental view that may not get billed at all (incorrect positioning or the like).
Therefore the relationship between billed item and Investigation might need to reflect this.
Whilst billing integration is highly desirable, would it be simpler to start to build the investigation creation from the Patient medical records area through a new Investigation medical record with each Investigation being a single exposure?
The rules relating investigation types and billing I could imagine, might need to be quite flexible to facilitate the different methodology of billing from clinic to clinic and might need to encompass a number of use cases.
b) Unless integration allows the Investigation to populate the worklist on the modality console (MPPS support), the matching identifier will be the Investigation act ID (i assume) and be manually entered at the modality console.
This requires your worklist software to allow that identifier to be entered. In our present configuration this doesn't seem to be an option we have.
Note: Vet users watching this discussion should be clear that their are two "worklists" that might exist in your practice setup - the console worklist that you use to talk to your modality (eg. In digital radiography, the computer you enter the patient details and exposures) and the PACS worklist. In our present configuration (not uncommon in CR installs in Australia at least) we don't use our PACS worklist at all, just the modality console.
c) I think viewing studies at a click from the OpenVPMS patient interface through a system default DICOM viewer is a great feature (Dicom SCP/SCU).
d) A query about Investigation types Tony. Can they be configured to include details that are particular to the type?
In other words, a Lab investigation type will have completely different fields to a Radiology request type or even an Ultrasound request type (I am keen to have the capacity include exposure factors in radiology investigations).
And following on, will each modality have their own investigation type?
Matt C
Re: Dicom Modality Worklist
Re: Dicom Modality Worklist
Hey Tony,
OK, so an investigation equates to a Study. The worklist, in the case of digital radiography, would be populated with empty studies but with all the patient data already entered. I got confused when you were mentioning views in comments, as this relates more directly to exposures or members of the study.
To clarify, this means for the Billing integration billing items ideally equate to studies rather then exposures/plates. I wonder if billing multiple items with associated investigations might lead to a situation where multiple unwanted studies are created.
Re Study accession number, maybe it is an option which is not applicable for our console (Fuji) given our study accession numbers are automatically generated and we are only using local console worklists.
All good stuff,
Matt C
Re: Dicom Modality Worklist
Hi Matt,
Sorry for confusion. I was just trying to cater for Sam’s comment to be able to nominate specific views on the request so the person doing the imaging could have access to this at the Modality. My suggestion was we could described the required views in the existing investigation notes area. Happy to discuss other options though ?
With billing not all products need to be associated with investigation types and also when you bill one that is you get prompted with an Investigation dialogue which you are free to cancel so no investigation request is generated.
I believe if we setup MWL on your console it will get the accession number from the MWL Provider rather than create one itself. I think this may be part of the MWL standard ?
Cheers
Tony
Re: Dicom Modality Worklist
Hey Tony,
Bases all covered! This software must have been well designed or something :)
Matt C
Re: Dicom Modality Worklist
I am sure that you are aware but the link for the Radiology Information System to the modalities and back again is via a program called HL7 http://en.wikipedia.org/wiki/Health_Level_7 //en.wikipedia.org/wiki/Health_Level_7>
At CSU we have developed a DICOM modality worklist with Vision acting as the RIS. Happy to show you our material if you are interested.
Regards
Ken
mpcosta wrote: > > Hey Tony, > > OK, so an investigation equates to a Study. The worklist, in the case > of digital radiography, would be populated with empty studies but > with all the patient data already entered. I got confused when you > were mentioning views in comments, as this relates more directly to > exposures or members of the study. > > To clarify, this means for the Billing integration billing items > ideally equate to studies rather then exposures/plates. I wonder if > billing multiple items with associated investigations might lead to a > situation where multiple unwanted studies are created. > > Re Study accession number, maybe it is an option which is not > applicable for our console (Fuji) given our study accession numbers > are automatically generated and we are only using local console > worklists. > > All good stuff, > > Matt C > > > > On Fri, 28 Aug 2009 17:06:27 +1000, wrote: > > Re: [OpenVPMS Users] Dicom Modality Worklist Hi Matt, > > Not sure I agree with your model. > > I think an investigate relates directly to a study in dicom terms > which may include multiple images (views, incidental views etc) . > I think this still meets with out existing model and the proposed > changes. > > When retrieving a study you can retrieve all or only specific images. > > The billing relationship is purely used as a convenience so you > can bill a specific product and it would automatically create the > investigation entry of the specified investigation type. > Currently we can create one investigation type (and display one > investigation dialogue) for each billed item but this could be > modified if required. > > I am sure we can develop a system which prompts for different > things according to the investigation type. This may be > initially driven by specific settings in the investigation type > and have a fixed number of entries but this could evolve to > archetype driven types in time. > > The proposed development suggest using the investigation id (act > id) as the Study accession number. I think most if not all > Modality software has a field for this which would be part of the > DICOM tags that are stored with the images and can be used for > searching ? > > Cheers > Tony > > > > > On 28/08/09 12:37 PM, "Mpcosta@Boroniavet. Au" : > > Hey guys, > A few points that have occurred to me. A lot of abbreviations > here. I'll try and keep up! > I have started linking billed XRAY items to a 3rd party task > list to automate the regulatory requirement of recording > exposure factors and have made the following observations. > > a) The relationship of billed item and exposures is a > one-many. In other words we might bill a single XRAY STIFLE > that includes 2 standard views and maybe an incidental view > that may not get billed at all (incorrect positioning or the > like). > Therefore the relationship between billed item and > Investigation might need to reflect this. > Whilst billing integration is highly desirable, would it be > simpler to start to build the investigation creation from the > Patient medical records area through a new Investigation > medical record with each Investigation being a single exposure? > The rules relating investigation types and billing I could > imagine, might need to be quite flexible to facilitate the > different methodology of billing from clinic to clinic and > might need to encompass a number of use cases. > > b) Unless integration allows the Investigation to populate the > worklist on the modality console (MPPS support), the matching > identifier will be the Investigation act ID (i assume) and be > manually entered at the modality console. > This requires your worklist software to allow that identifier > to be entered. In our present configuration this doesn't seem > to be an option we have. > > /Note: Vet users watching this discussion should be clear that > their are two "worklists" that might exist in your practice > setup - the console worklist that you use to talk to your > modality (eg. In digital radiography, the computer you enter > the patient details and exposures) and the PACS worklist. In > our present configuration (not uncommon in CR installs in > Australia at least) we don't use our PACS worklist at all, > just the modality console. > / > c) I think viewing studies at a click from the OpenVPMS > patient interface through a system default DICOM viewer is a > great feature (Dicom SCP/SCU). > > d) A query about Investigation types Tony. Can they be > configured to include details that are particular to the type? > In other words, a Lab investigation type will have completely > different fields to a Radiology request type or even an > Ultrasound request type (I am keen to have the capacity > include exposure factors in radiology investigations). > And following on, will each modality have their own > investigation type? > > Matt C > > > On Fri, 28 Aug 2009 01:56:33 +0000 (UTC), tony@openvpms.org > //mce_host/priv/mail/tony@openvpms.org> wrote: > > Hi Sam, > > We would have to work through all the use cases but the basic > concept would > > build on the existing Investigation Management workflow we > have already > > developed which can link Investigations to biling items and > provide work > > lists detailing the status investigations by type, date, > status etc. > > > I think we would need to extend the Investigation Type's to > support DICOM > > integration. Essentially the Investigation type would have > extra setup > > information including whether or not you want DICOM MWL > integration and > > then information about the MWL SCP server you wish to utilise > for this > > investigation type. It would allow you to set a Modality for > this > > Investigation Type. > > I was thinking the existing notes area may be sufficient for > describing > > views etc although we could provide a lookup of views in the > Investigation > > dialogue if required. > > > > Another configuration option in the Investigation Type would > be if you want > > Dicom SCP/SCU integration. i.e do you want to be able to > retrieve the > > DICOM image(s) from the PACS server directly as discussed > above. This > > would not preclude using your favourite DICOM viewer > application directly > > with the Pacs but would allow you to directly view images > while you are > > viewing the patients clinical records without the need for a > search. The > > unique investigation acession number would allow this to happen. > > Now as OpenVPMS is a web application the images would be > downloaded and > > then the browser could be configured to bring up Osirix, > Kpacs, Clear > > Canvas or whatever. In your case if you are using Osirix then > you just > > need to run OpenVPMS from a browser on your Mac and configure > Safari, > > Firefox whatever to utilise Osirix when you download dicom > content. If > > you are running OpenVPMS on a TS session on your windows > server you would > > need to have a windows compatible viewer. Obviously java > based viewers > > wouldl operate on any platform :-) > > > Th eother functionality that woudl be good to implement is > MPPS support > > allowing imaging request status to be integrated between > OpenVPMS, the > > Pacs and the Modality. This would allow a user of OpenVPMS > to see if a > > request is in progress, Discontinued or Completed in the > Investigation > > worklist as well as allow them to Cancel a request and have > this reflected > > at the Modality and PACS. Obviously thsi requires a > PACS/Modality with > > MPPS support although some PACs systems provide what they > call MPPS > > emulation. With this when a image is received and after some > timeout of > > not receiving another image they send off a MPPS Completed > update. Thsi > > may be quite handy. > > Anyway lots to talk about. > > BTW I have invited Matt Wright from the article you mentioned > to be > > involved in the discussions. He obviously has far more > experience in > > these issues and would provide some great feedback. > > Cheers > > Tony > > _______________________________________________ > > OpenVPMS User Mailing List > > users@lists.openvpms.org > //mce_host/priv/mail/users@lists.openvpms.org> > > To unsubscribe or change your subscription visit: > > http://lists.openvpms.org/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 > //mce_host/priv/mail/users@lists.openvpms.org> > To unsubscribe or change your subscription visit: > http://lists.openvpms.org/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/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/listinfo/users Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- http://tinyurl.com/openvfu
Dicom Modality Worklist
Hi Ken,
Using HL7 is defeinitely an option between OpenVPMS and a suitable PACs or Modality that has HL7 features. This would actually fit in well with more than just imaging requests and status updates as the ORM (Order Message) and Results as ORU (Observational Report Message) messages through this protocol are applicable to other investigation types such as Pathology and Pharmacy requests.
As I understand it HL7 is typically not provided standard with many modality workstations and often not even in some PACS systems. I think it can also be a very costly addiiton. The open source PACS systems I have setup do have HL7 services included. On this basis maybe we need to be able to support both MWL/MPPS as well as HL7 ?
Cheers
Tony
Re: Dicom Modality Worklist
_______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: http://lists.openvpms.org/listinfo/users Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- http://tinyurl.com/openvfu
Dicom Modality
Hi Tony, Matt et al
I have just started looking into CR and thus far all the acronyms and abbreviations have not become clear. I will leave the OVPMS integration to the experts but am happy to contibute.
Can you please give me a list of questions (that I and maybe others like me) can undersatnd that I need to ask potential CR suppliers in regards to incorporating / linking the CR investigation to the patient history.
On Investigations, if I try to add one now there are no investigation types listed - is this a matter of me populating Investigation Type with a New sub type call CR or Ultrasound? In doing this there is an option to add a template - is this just a document or can it be a products/pricing template?
Cheers,
Nick
Re: Dicom Modality
As Matt has just gone through selection and integration of a CR system I think he may be best qualified to provide your list of questions. :-)
In regards Investigation Types, yes you need to add new ones in Administration->Types. You should add investigation types that equate to specific modalities and study types to be aligned with the discussions we have had in previous posts.
The template selection tab in the Investigation types is there to facilitate automatic request form printing which has been developed and will be released in the 1.4 version. You will also be able to link Investigation types to products so they are created automatically on billing that product and you can print the merged request form template.
Cheers Tony
_______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: http://lists.openvpms.org/listinfo/users Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- http://tinyurl.com/openvfu
Re: Dicom Modality
I'll give you a short list of questions that were relevant to us but you just can't go past the animal insides website for useful information regarding selecting your CR vendor. It is an essential website and well worth an hour or two to go through the archived information before you start talking to vendors. You can't be too well informed :) I'll just include key questions that relate to our experience of PACS integration (there are many more depending on just how far you want to integrate). If you go back to the article Sam linked that started this forum topic http://www.animalinsides.com/content/view/283/84/ (also from animal insides), you will find some good info in there as well.
Before I start, here is a very poor understanding of what is being discussed in this forum at the moment with respect to CR. I'm sure others will correct my innacuracies but here is my simplification. Your worklist is just a list of studies that are going to be performed. It might look like a list of patient names. Inside each study is a list of exposures with what body part/view they might correspond to. eg. "Lateral Stifle". When you take an xray you need to have chosen which study/patient you are imaging. You do this from the worklist. After your reader reads the plate it sends that image to your "console". A console is just a computer which allows the image to be quality checked, annotated etc. Once we are happy with the image, we send it to the PACS server where it lives happily ever after.
In our case the worklist is populated by our staff manually entering the patient details prior to the studies on the console.
There are 2 scenarios being described in the forums: 1. We create a worklist that lives in our PACS server that is populated when we create investigations in OpenVPMS. In this scenario we tell our modality a unique ID that corresponds to the study in the PACS - the study accession number. This way when we send our image from the console to the PACS it knows to associate the image with the patient/study it belongs to.
2. We not only create a worklist that lives in the PACS but that same worklist appears on the console of our modality cos our modality requests the worklist from our worklist server. This means there is no bother with entering study accession IDs. We just choose from the worklist that appears in our console. This is the superior solution but requires our proprietary console to know how to request a worklist from our worklist server. It is this type of solution that you would like to know if your vendor will support.
Key Questions to Self: 1. What PACS will I set up (the vendors proprietary solution or an open source option). Whisper: Go the open source option and get a good IT person to install it.
2. How will I report or read the studies (use their console or create a separate workstation to report from).
3. How will my worklist server work - what protocols will it adhere to? See below
Key Questions for Modality Vendor: 1. Will my modality (CR in this case) talk to my PACS solution -> give them the name of your PACS solution. Answer: In our case they had not but they were confident and gave us an assurance they would get them to talk.
2. Have you successfully networked this modality to this PACS before? Answer: In our case the answer was no. There were some issues with this on the day of the install. The engineer took some time to nut out afew requirements of our PACS such as mandatory fields, but the problems were overcome.
3. Can I have a browser open on my console to allow access to OpenVPMS? Answer: Should be yes, but make sure they do it on install day. It can come in very handy if you want to find a patient ID.
4. What information do you need to know before the day (question to vendor). Answer: They should say something. Ideally they should have a whole lot of info required before they turn up like IP addresses, ports, AE_Titles etc. Much better to know they have a plan before they arrive.
5. How much does it cost to have worklist functionality (MWL) and what does that actually do. They will probably ask what protocol does your worklist server solution apply (I think this is where you want to say MWL). That will vary according to the worklist solution you have. So in our case I beleive Tony will seek to use our PACS solution (DCM_4_CHEE) to provide this. I don't know what protocols it uses and for this I will defer the specifics of this question back to Tony. :)
The type that was offered to us from our vendor (Fuji) was called "DICOM ORDER MWM Worklist Manager". We did not investigate this in very much detail as we had not intended to integrate with OpenVPMS in a hurry. We were looking in the $700 range for this option. Whether this offers the same functionality as MWL described by Matt Wright in animal insides article or whether it would have allowed integration with the worklist capacity of the PACS that Tony is describing I can't say.
I hope this helps any one struggling with the techno concepts... and hasn't made too many people more confused!
Matt C
On Wed, 2 Sep 2009 02:49:49 +0000 (UTC), paradisevets@internode.on.net
wrote: > Hi Tony, Matt et al > I have just started looking into CR and thus far all the acronyms and > abbreviations have not become clear. I will leave the OVPMS integration to > the experts but am happy to contibute. > > Can you please give me a list of questions (that I and maybe others like > me) can undersatnd that I need to ask potential CR suppliers in regards to > incorporating / linking the CR investigation to the patient history. > > On Investigations, if I try to add one now there are no investigation types > listed - is this a matter of me populating Investigation Type with a New > sub type call CR or Ultrasound? In doing this there is an option to add > a template - is this just a document or can it be a products/pricing > template? > > Cheers, > > Nick > _______________________________________________ > OpenVPMS User Mailing List > users@lists.openvpms.org > To unsubscribe or change your subscription visit: > http://lists.openvpms.org/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/listinfo/users Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- http://tinyurl.com/openvfu
Re: Dicom Modality
A DICOM modality worklist is a list of patients generated in human radiology systems from their RIS or Radiology Information System that populates the patient information on machinery used for imaging including CR and US but may include other imaging modalities. The link between the RIS and the DICOM modality worklist is via a link or standard called and HL7 link (or Health Level 7) which is an industry standard. The images are then access via the patient list or the RIS or from the PACS server
The patient information system (PIS) can act as a RIS. The DICOM modality worklist is generated from the PIS and the images stored on the PACS server can be accessed via the PIS over the intranet or via the internet as deidentified images
For more information contact Mark Murray CSU's system manager. mmurray@csu.edu.au
Ken
mpcosta wrote: > Hey Nick! > > I'll give you a short list of questions that were relevant to us but you > just can't go past the animal insides website for useful information > regarding selecting your CR vendor. It is an essential website and well > worth an hour or two to go through the archived information before you > start talking to vendors. You can't be too well informed :) > I'll just include key questions that relate to our experience of PACS > integration (there are many more depending on just how far you want to > integrate). If you go back to the article Sam linked that started this > forum topic http://www.animalinsides.com/content/view/283/84/ (also from > animal insides), you will find some good info in there as well. > > > Before I start, here is a very poor understanding of what is being > discussed in this forum at the moment with respect to CR. I'm sure others > will correct my innacuracies but here is my simplification. > Your worklist is just a list of studies that are going to be performed. It > might look like a list of patient names. Inside each study is a list of > exposures with what body part/view they might correspond to. eg. "Lateral > Stifle". When you take an xray you need to have chosen which study/patient > you are imaging. You do this from the worklist. After your reader reads the > plate it sends that image to your "console". A console is just a computer > which allows the image to be quality checked, annotated etc. Once we are > happy with the image, we send it to the PACS server where it lives happily > ever after. > > In our case the worklist is populated by our staff manually entering the > patient details prior to the studies on the console. > > There are 2 scenarios being described in the forums: > 1. We create a worklist that lives in our PACS server that is populated > when we create investigations in OpenVPMS. > In this scenario we tell our modality a unique ID that corresponds to the > study in the PACS - the study accession number. This way when we send our > image from the console to the PACS it knows to associate the image with the > patient/study it belongs to. > > 2. We not only create a worklist that lives in the PACS but that same > worklist appears on the console of our modality cos our modality requests > the worklist from our worklist server. This means there is no bother with > entering study accession IDs. We just choose from the worklist that appears > in our console. > This is the superior solution but requires our proprietary console to know > how to request a worklist from our worklist server. It is this type of > solution that you would like to know if your vendor will support. > > Key Questions to Self: > 1. What PACS will I set up (the vendors proprietary solution or an open > source option). > Whisper: Go the open source option and get a good IT person to install it. > > 2. How will I report or read the studies (use their console or create a > separate workstation to report from). > > 3. How will my worklist server work - what protocols will it adhere to? > See below > > Key Questions for Modality Vendor: > 1. Will my modality (CR in this case) talk to my PACS solution -> give them > the name of your PACS solution. > Answer: In our case they had not but they were confident and gave us an > assurance they would get them to talk. > > 2. Have you successfully networked this modality to this PACS before? > Answer: In our case the answer was no. There were some issues with this on > the day of the install. The engineer took some time to nut out afew > requirements of our PACS such as mandatory fields, but the problems were > overcome. > > 3. Can I have a browser open on my console to allow access to OpenVPMS? > Answer: Should be yes, but make sure they do it on install day. It can come > in very handy if you want to find a patient ID. > > 4. What information do you need to know before the day (question to > vendor). > Answer: They should say something. Ideally they should have a whole lot of > info required before they turn up like IP addresses, ports, AE_Titles etc. > Much better to know they have a plan before they arrive. > > 5. How much does it cost to have worklist functionality (MWL) and what does > that actually do. > They will probably ask what protocol does your worklist server solution > apply (I think this is where you want to say MWL). That will vary according > to the worklist solution you have. So in our case I beleive Tony will seek > to use our PACS solution (DCM_4_CHEE) to provide this. I don't know what > protocols it uses and for this I will defer the specifics of this question > back to Tony. :) > > The type that was offered to us from our vendor (Fuji) was called "DICOM > ORDER MWM Worklist Manager". We did not investigate this in very much > detail as we had not intended to integrate with OpenVPMS in a hurry. We > were looking in the $700 range for this option. > Whether this offers the same functionality as MWL described by Matt Wright > in animal insides article or whether it would have allowed integration with > the worklist capacity of the PACS that Tony is describing I can't say. > > I hope this helps any one struggling with the techno concepts... and hasn't > made too many people more confused! > > Matt C > > > > > > > On Wed, 2 Sep 2009 02:49:49 +0000 (UTC), paradisevets@internode.on.net > wrote: > >> Hi Tony, Matt et al >> I have just started looking into CR and thus far all the acronyms and >> abbreviations have not become clear. I will leave the OVPMS integration >> > to > >> the experts but am happy to contibute. >> >> Can you please give me a list of questions (that I and maybe others like >> me) can undersatnd that I need to ask potential CR suppliers in regards >> > to > >> incorporating / linking the CR investigation to the patient history. >> >> On Investigations, if I try to add one now there are no investigation >> > types > >> listed - is this a matter of me populating Investigation Type with a New >> sub type call CR or Ultrasound? In doing this there is an option to add >> a template - is this just a document or can it be a products/pricing >> template? >> >> Cheers, >> >> Nick >> _______________________________________________ >> OpenVPMS User Mailing List >> users@lists.openvpms.org >> To unsubscribe or change your subscription visit: >> http://lists.openvpms.org/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/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/listinfo/users Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- http://tinyurl.com/openvfu
Re: Dicom Modality
Matt C
On Thu, 03 Sep 2009 08:22:32 +1000, Ken Jacobs
wrote: > I have been involved in doing this for Charles Sturt University and we > have a system operational using VISION software > > A DICOM modality worklist is a list of patients generated in human > radiology systems from their RIS or Radiology Information System that > populates the patient information on machinery used for imaging > including CR and US but may include other imaging modalities. The link > between the RIS and the DICOM modality worklist is via a link or > standard called and HL7 link (or Health Level 7) which is an industry > standard. The images are then access via the patient list or the RIS or > from the PACS server > > The patient information system (PIS) can act as a RIS. The DICOM > modality worklist is generated from the PIS and the images stored on the > PACS server can be accessed via the PIS over the intranet or via the > internet as deidentified images > > For more information contact Mark Murray CSU's system manager. > mmurray@csu.edu.au > > Ken > > mpcosta wrote: >> Hey Nick! >> >> I'll give you a short list of questions that were relevant to us but you >> just can't go past the animal insides website for useful information >> regarding selecting your CR vendor. It is an essential website and well >> worth an hour or two to go through the archived information before you >> start talking to vendors. You can't be too well informed :) >> I'll just include key questions that relate to our experience of PACS >> integration (there are many more depending on just how far you want to >> integrate). If you go back to the article Sam linked that started this >> forum topic http://www.animalinsides.com/content/view/283/84/ (also >> from >> animal insides), you will find some good info in there as well. >> >> >> Before I start, here is a very poor understanding of what is being >> discussed in this forum at the moment with respect to CR. I'm sure others >> will correct my innacuracies but here is my simplification. >> Your worklist is just a list of studies that are going to be performed. >> It >> might look like a list of patient names. Inside each study is a list of >> exposures with what body part/view they might correspond to. eg. "Lateral >> Stifle". When you take an xray you need to have chosen which >> study/patient >> you are imaging. You do this from the worklist. After your reader reads >> the >> plate it sends that image to your "console". A console is just a computer >> which allows the image to be quality checked, annotated etc. Once we are >> happy with the image, we send it to the PACS server where it lives >> happily >> ever after. >> >> In our case the worklist is populated by our staff manually entering the >> patient details prior to the studies on the console. >> >> There are 2 scenarios being described in the forums: >> 1. We create a worklist that lives in our PACS server that is populated >> when we create investigations in OpenVPMS. >> In this scenario we tell our modality a unique ID that corresponds to the >> study in the PACS - the study accession number. This way when we send our >> image from the console to the PACS it knows to associate the image with >> the >> patient/study it belongs to. >> >> 2. We not only create a worklist that lives in the PACS but that same >> worklist appears on the console of our modality cos our modality requests >> the worklist from our worklist server. This means there is no bother with >> entering study accession IDs. We just choose from the worklist that >> appears >> in our console. >> This is the superior solution but requires our proprietary console to >> know >> how to request a worklist from our worklist server. It is this type of >> solution that you would like to know if your vendor will support. >> >> Key Questions to Self: >> 1. What PACS will I set up (the vendors proprietary solution or an open >> source option). >> Whisper: Go the open source option and get a good IT person to install >> it. >> >> 2. How will I report or read the studies (use their console or create a >> separate workstation to report from). >> >> 3. How will my worklist server work - what protocols will it adhere to? >> See below >> >> Key Questions for Modality Vendor: >> 1. Will my modality (CR in this case) talk to my PACS solution -> give >> them >> the name of your PACS solution. >> Answer: In our case they had not but they were confident and gave us an >> assurance they would get them to talk. >> >> 2. Have you successfully networked this modality to this PACS before? >> Answer: In our case the answer was no. There were some issues with this >> on >> the day of the install. The engineer took some time to nut out afew >> requirements of our PACS such as mandatory fields, but the problems were >> overcome. >> >> 3. Can I have a browser open on my console to allow access to OpenVPMS? >> Answer: Should be yes, but make sure they do it on install day. It can >> come >> in very handy if you want to find a patient ID. >> >> 4. What information do you need to know before the day (question to >> vendor). >> Answer: They should say something. Ideally they should have a whole lot >> of >> info required before they turn up like IP addresses, ports, AE_Titles >> etc. >> Much better to know they have a plan before they arrive. >> >> 5. How much does it cost to have worklist functionality (MWL) and what >> does >> that actually do. >> They will probably ask what protocol does your worklist server solution >> apply (I think this is where you want to say MWL). That will vary >> according >> to the worklist solution you have. So in our case I beleive Tony will >> seek >> to use our PACS solution (DCM_4_CHEE) to provide this. I don't know what >> protocols it uses and for this I will defer the specifics of this >> question >> back to Tony. :) >> >> The type that was offered to us from our vendor (Fuji) was called "DICOM >> ORDER MWM Worklist Manager". We did not investigate this in very much >> detail as we had not intended to integrate with OpenVPMS in a hurry. We >> were looking in the $700 range for this option. >> Whether this offers the same functionality as MWL described by Matt >> Wright >> in animal insides article or whether it would have allowed integration >> with >> the worklist capacity of the PACS that Tony is describing I can't say. >> >> I hope this helps any one struggling with the techno concepts... and >> hasn't >> made too many people more confused! >> >> Matt C >> >> >> >> >> >> >> On Wed, 2 Sep 2009 02:49:49 +0000 (UTC), paradisevets@internode.on.net >> wrote: >> >>> Hi Tony, Matt et al >>> I have just started looking into CR and thus far all the acronyms and >>> abbreviations have not become clear. I will leave the OVPMS integration >>> >> to >> >>> the experts but am happy to contibute. >>> >>> Can you please give me a list of questions (that I and maybe others like >>> me) can undersatnd that I need to ask potential CR suppliers in regards >>> >> to >> >>> incorporating / linking the CR investigation to the patient history. >>> >>> On Investigations, if I try to add one now there are no investigation >>> >> types >> >>> listed - is this a matter of me populating Investigation Type with a New >>> sub type call CR or Ultrasound? In doing this there is an option to add >>> a template - is this just a document or can it be a products/pricing >>> template? >>> >>> Cheers, >>> >>> Nick >>> _______________________________________________ >>> OpenVPMS User Mailing List >>> users@lists.openvpms.org >>> To unsubscribe or change your subscription visit: >>> http://lists.openvpms.org/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/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/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/listinfo/users Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- http://tinyurl.com/openvfu
Re: Dicom Modality
I think we are probably getting into implementation territory rather than first looking at the issue from a OpenVPMS user perspective which is what we call the Use Cases.
I think not many users will understand the intricacies of the DICOM and HL7 standards but will have clear views on what will increase productivity in their practices. If the technical solution meets the use cases and does it efficiently and using standards then the project will succeed. The use case by definition cannot refer to any specific technical information ..
Maybe you can push this discussion further Matt so we are sure the end result is what users want to see in OpenVPMS :-)
Ok. Here's my technical response to the post but you may not want to read from here on as the acronyms will be flying :-)
I believe in a traditional veterinary practice environment the PIS(Actually prefer PIMS - Patient Information Management system .. A bit nicer acronym), in this case OpenVPMS, would act as the RIS (Radiology Information System) and deliver the Modality Worklist server functionality to the Modalities. This makes sense especially in OpenVPMS where we already have the core investigation workflow module in place and would just need to enhance it to provide DICOM MWL services to the network.i.e Modalities would be setup to query OpenVPMS for their worklist and would provide MPPS updates to OpenVPMS to update the status of these worklists.
In this architecture the PACS would be used purely for Storage and retrieval of images and not as a MWL provider (if the PACS had this capability anyway and many don't).
In this case no HL7 messaging is required which can be a good thing as I mentioned (can be a very expensive add-on if available at all).
In a larger organisation this would most likely not be the case (Universities, Veterinary Teaching Hospitals) as they would implement distinct (maybe multiple) PACS and RIS servers and the PIS would typically communicate with the RIS or PACS or Modalities via HL7 ADT and ORM messages to register requests including patient details.
Even then if no HL7 services are available we should still be able to talk to another MWL service (RIS or PACS) to register Modality requests.
What does this mean to OpenVPMS ?
1. We need the option to configure specific investigation types to dispatch requests by either DICOM (MWL User), HL7 (ORM) or None (we are the MWL provider) and to stipulate the host name and port of the server that we dispatch requests to. (and other dicom specific information). 2. We need to be able provide optional MWL Provider services in OpenVPMS which will answer MWL user requests from Modalities and/or PACS. 2. We need to be able to participate in MPPS updates so the Investigation Workflow can have the status of the request updated to reflect the status of the request on the Modality, PACS or RIS.
Lastly I think it is important that Investigation Type entries in a clinical record can initiate DICOM retrieve from the PACS so clinicians can access images directly from within the patient Medical record.
Cheers Tony
_______________________________________________ OpenVPMS User Mailing List users@lists.openvpms.org To unsubscribe or change your subscription visit: http://lists.openvpms.org/listinfo/users Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- http://tinyurl.com/openvfu
Re: Dicom Modality
So the question for the OpenVPMS user community, What do we want to happen with this development? I'll list some use cases in our practice and people can add to them according to what they would like to see happen in their practices.
1. When taking a digital xray, I would like to create an Investigation in OpenVPMS either through; i) Patient records (Add new Investigation to Visit), ii) The Investigation workspace (Add new Investigation) iii) Through billing specific items (Key items create an Investigation).
2. When I come to our console worklist a study with the patient data already entered will be waiting for me. All I will have to do is add the views I am going to take.
3. When I look at a patient with ultrasounds or digital xrays, I would like to be able to be able to click on a link and have the study open in my DICOM viewer of choice.
I think that's all I can think of in our situation!
Cheers, Matt C
On Thu, 03 Sep 2009 12:04:11 +1000, Tony De Keizer
wrote: > Hi Guys, > > I think we are probably getting into implementation territory rather than > first looking at the issue from a OpenVPMS user perspective which is what > we > call the Use Cases. > > I think not many users will understand the intricacies of the DICOM and HL7 > standards but will have clear views on what will increase productivity in > their practices. If the technical solution meets the use cases and does it > efficiently and using standards then the project will succeed. The use case > by definition cannot refer to any specific technical information .. > > Maybe you can push this discussion further Matt so we are sure the end > result is what users want to see in OpenVPMS :-) > > Ok. Here's my technical response to the post but you may not want to read > from here on as the acronyms will be flying :-) > > I believe in a traditional veterinary practice environment the PIS(Actually > prefer PIMS - Patient Information Management system .. A bit nicer > acronym), > in this case OpenVPMS, would act as the RIS (Radiology Information System) > and deliver the Modality Worklist server functionality to the Modalities. > This makes sense especially in OpenVPMS where we already have the core > investigation workflow module in place and would just need to enhance it to > provide DICOM MWL services to the network.i.e Modalities would be setup to > query OpenVPMS for their worklist and would provide MPPS updates to > OpenVPMS > to update the status of these worklists. > > In this architecture the PACS would be used purely for Storage and > retrieval > of images and not as a MWL provider (if the PACS had this capability anyway > and many don't). > > In this case no HL7 messaging is required which can be a good thing as I > mentioned (can be a very expensive add-on if available at all). > > In a larger organisation this would most likely not be the case > (Universities, Veterinary Teaching Hospitals) as they would implement > distinct (maybe multiple) PACS and RIS servers and the PIS would typically > communicate with the RIS or PACS or Modalities via HL7 ADT and ORM > messages > to register requests including patient details. > > Even then if no HL7 services are available we should still be able to talk > to another MWL service (RIS or PACS) to register Modality requests. > > What does this mean to OpenVPMS ? > > 1. We need the option to configure specific investigation types to > dispatch > requests by either DICOM (MWL User), HL7 (ORM) or None (we are the MWL > provider) and to stipulate the host name and port of the server that we > dispatch requests to. (and other dicom specific information). > 2. We need to be able provide optional MWL Provider services in OpenVPMS > which will answer MWL user requests from Modalities and/or PACS. > 2. We need to be able to participate in MPPS updates so the Investigation > Workflow can have the status of the request updated to reflect the status > of > the request on the Modality, PACS or RIS. > > Lastly I think it is important that Investigation Type entries in a > clinical > record can initiate DICOM retrieve from the PACS so clinicians can access > images directly from within the patient Medical record. > > Cheers > Tony > > > > > > _______________________________________________ > OpenVPMS User Mailing List > users@lists.openvpms.org > To unsubscribe or change your subscription visit: > http://lists.openvpms.org/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/listinfo/users Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- http://tinyurl.com/openvfu
Re: Dicom Modality
Great start.
Maybe some extra Use Cases :
4. Cancel Study. From Investigation workspace/Patient Records in OpenVPMS or from Modality. 5. Complete Study. Mark study completed at Modality .. Propagates status to OpenVPMS Investigation. Other way round as well maybe ?
Can anyone think of others ?
Also just a quick clarification. I incorrectly included MWL SCU in options for communication from OpenVPMS but this only allows a Modality or other application to query a Modality Worklist from a provider (MWL SCP).
This means if OpenVPMS is not the RIS then it will need to support sending HL7 ORM messages to your PACS/RIS and the PACS/RIS will need to support receiving HL7 messages.
One other note. Do people want to see OpenVPMS provide some form of General Worklist support. The General Worklist is often used as a list of studies to report on. I can imagine we could add additional functionality to our Investigation Worklist for Interim and Final report status ...
Cheers Tony
On 3/09/09 1:50 PM, "Mpcosta@Boroniavet. Au" :
> > I'm happy to push the use cases Tony. Its where I feel more comfortable as > an end user anyway! > > So the question for the OpenVPMS user community, > What do we want to happen with this development? > I'll list some use cases in our practice and people can add to them > according to what they would like to see happen in their practices. > > 1. When taking a digital xray, I would like to create an Investigation in > OpenVPMS either through; > i) Patient records (Add new Investigation to Visit), > ii) The Investigation workspace (Add new Investigation) > iii) Through billing specific items (Key items create an Investigation). > > 2. When I come to our console worklist a study with the patient data > already entered will be waiting for me. All I will have to do is add the > views I am going to take. > > 3. When I look at a patient with ultrasounds or digital xrays, I would like > to be able to be able to click on a link and have the study open in my > DICOM viewer of choice. > > I think that's all I can think of in our situation! > > Cheers, > Matt C > > > On Thu, 03 Sep 2009 12:04:11 +1000, Tony De Keizer > wrote: >> Hi Guys, >> >> I think we are probably getting into implementation territory rather than >> first looking at the issue from a OpenVPMS user perspective which is what >> we >> call the Use Cases. >> >> I think not many users will understand the intricacies of the DICOM and > HL7 >> standards but will have clear views on what will increase productivity in >> their practices. If the technical solution meets the use cases and does > it >> efficiently and using standards then the project will succeed. The use > case >> by definition cannot refer to any specific technical information .. >> >> Maybe you can push this discussion further Matt so we are sure the end >> result is what users want to see in OpenVPMS :-) >> >> Ok. Here's my technical response to the post but you may not want to > read >> from here on as the acronyms will be flying :-) >> >> I believe in a traditional veterinary practice environment the > PIS(Actually >> prefer PIMS - Patient Information Management system .. A bit nicer >> acronym), >> in this case OpenVPMS, would act as the RIS (Radiology Information > System) >> and deliver the Modality Worklist server functionality to the Modalities. >> This makes sense especially in OpenVPMS where we already have the core >> investigation workflow module in place and would just need to enhance it > to >> provide DICOM MWL services to the network.i.e Modalities would be setup > to >> query OpenVPMS for their worklist and would provide MPPS updates to >> OpenVPMS >> to update the status of these worklists. >> >> In this architecture the PACS would be used purely for Storage and >> retrieval >> of images and not as a MWL provider (if the PACS had this capability > anyway >> and many don't). >> >> In this case no HL7 messaging is required which can be a good thing as I >> mentioned (can be a very expensive add-on if available at all). >> >> In a larger organisation this would most likely not be the case >> (Universities, Veterinary Teaching Hospitals) as they would implement >> distinct (maybe multiple) PACS and RIS servers and the PIS would > typically >> communicate with the RIS or PACS or Modalities via HL7 ADT and ORM >> messages >> to register requests including patient details. >> >> Even then if no HL7 services are available we should still be able to > talk >> to another MWL service (RIS or PACS) to register Modality requests. >> >> What does this mean to OpenVPMS ? >> >> 1. We need the option to configure specific investigation types to >> dispatch >> requests by either DICOM (MWL User), HL7 (ORM) or None (we are the MWL >> provider) and to stipulate the host name and port of the server that we >> dispatch requests to. (and other dicom specific information). >> 2. We need to be able provide optional MWL Provider services in OpenVPMS >> which will answer MWL user requests from Modalities and/or PACS. >> 2. We need to be able to participate in MPPS updates so the > Investigation >> Workflow can have the status of the request updated to reflect the status >> of >> the request on the Modality, PACS or RIS. >> >> Lastly I think it is important that Investigation Type entries in a >> clinical >> record can initiate DICOM retrieve from the PACS so clinicians can access >> images directly from within the patient Medical record. >> >> Cheers >> Tony >> >> >> >> >> >> _______________________________________________ >> OpenVPMS User Mailing List >> users@lists.openvpms.org >> To unsubscribe or change your subscription visit: >> http://lists.openvpms.org/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/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/listinfo/users Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- http://tinyurl.com/openvfu
Re: New or updated comment for General User's Discussion Forum t
Thanks to Matt, Tony, Craig and all the contributers in this discussion and I appreciate that the discussion has swung back into the users court in the planning phase.
In my practice this is what would would like to achieve from the project:
I realise this is a very simplistic use of what looks to be a very functional application and I hope to see it fully developed in the future.
Sam
Re: New or updated comment for General User's Discussion Forum t
I f you want to implement this functionality I recommend taking a look at a couple of open source projects:
Also the IHE is an excellent resource for technical information on RIS/PACS integration - http://www.ihe.net/Technical_Framework/index.cfm#radiology.
David D.
Dicom Modality Worklist
This functionality would very definitely be a huge step forward for the US market, where digital imaging is getting much more prevalent. I intend to be at a large conference in January and will have access to a number of instrument vendors where we could pitch the concept of developing an interface to OpenVPMS. If anyone would like to brief me on where this stands in terms of a design I could try to make some contacts to see if we could get a testable implementation in partnership with a vendor (who may also be willing to sponsor some of the development... hmmm)
--- Pete
Dicom Modality Worklist
Hi Pete,
Sorry for late reply. Missed this one ..
Have had quite a bit of discussion so possibly ready for it to be specified and costed.
To summarise the requirements:
1. DICOM Modality Worklist services to the network. This will allow Modalities to query OpenVPMS investigation worklist for orders.
2. MPPS (Modality Performed Procedure Step) service to allow direct update of the Investigation status from the Modality or PACS.
3. OpenVPMS to offer HL7 ORM message support. This will allow specified Investigations to initiate a HL7 ORM message to a RIS or PACS or HL7 enabled Modality (or to be honest any investigation interface).
4. OpenVPMS to support DICOM Query/Retrieve so investigations can retrieve a study(result) directly from a PACS.
5. OpenVPMS to support HL7 ORU messages so results (Imaging, Pathology etc) can be imported directly into a investigation.
Tim and I have done some preliminary investigations already and there are a number of existing tools (libararies) and open source projects that could be used to implement these requirements. One of the projects we are evaluating is Mirth which is an open source integration service which can handle most of the DICOM and HL7 messaging managment. It has a plugin architecture which would allow us to build in the OpenVPMS interface components. Think this would save heaps of time as we woudln't have to worry about any of the specific messaging management inside OpenVPMS.
Hope this gives you enough information to get some interest at the conference. :-)
Cheers
Tony