posted on Tuesday, September 13, 2011 - 05:53 pm
Thanks David. This is excellent just what customers need to prevent vendor lock in.
If you are successful tomorrow, customers need to include this in their specification & PQQ. I do believe those vendors who have a good product will not be threatened by this. It will show up those who wish to lock customers in for the wrong reasons.
Once again thank you David. We are grateful.
posted on Thursday, September 15, 2011 - 12:52 pm
posted on Thursday, September 15, 2011 - 02:02 pm
That is a shame indeed. Does that mean there is no hope or is there a chance for the next round?
Thanks David for trying.
posted on Friday, September 23, 2011 - 08:50 pm
I have updated the PACS spec with the following wordings
"29. END OF CONTRACT DATA MIGRATION AGREEMENTS— PACS supplier must support migration of all the stored image data (in DICOM part 10 file format preferably). Read-only access to data must be allowed to a qualified Migration Service Provider. Supplier must provide explicit information about format of images stored & if any proprietary compression is used. Information about how annotations & image flips etcs is recorded must be provide upfront by vendor (? Private tags ? other format). Database dumps must be permitted for migration if required. Supplier must support both DICOM push & bulk data migration of data migration technologies. PACS supplier must support Image Archive/Image Manager Content Migration Profile of IHE when this becomes available. If PACS vendor chooses to store radiology reports & radiology requests, then they must be stored in standard CDA format. This will ensure that reports & requests can also be migrated into the new vendors PACS. (Normally it would be expected for RIS to migrate/store reports which will be populated into the new PACS.)"
Hi Neelam, I wonder is storing only in CDA too narrow? For example if reports are stored as DICOM SR, wouldn't this be acceptable as well? How about 'they must be available in standard CDA format' so the vendor as an obligation to convert to CDA on migration? Also who qualifies the migration service provider? The Trust? The vendor? etc. Suggest 'an appointed Migration Service Provider'.
*Commercial Interest* Also the why would a VNA be an intermediate archive question earlier is valid - I think there's two answers.
First is procurement - getting your data out of the data centre, ie local ownership, is the key point, yet you can't commit to the vna architecture (eg for a 5 or 7 year contract) without going to ojeu. So one needs to accept the vna could be transitory, but at least the migration can start now rather than a last-minute panic.
Second is clinical usability - in order to be able to ‘switch off’ the Data Centre contract as soon as possible and start saving money, historicals must be kept clinically usable, i.e. up to date. This is achieved through standard interfacing of demographic updates, a feature not available is the data in a simple DICOM archive (or off-line).
posted on Monday, September 26, 2011 - 06:19 pm
Historical images can indeed be kept up to date in a simple DICOM archive, as long as it is sent updated images (+/- deprecation of bad images via IHE IOCM). It is very undesirable in my opinion to attempt to simulate the behaviour of the PACS database by listening to demographic updates (a la IHE PIR), since there are many intra-PACS changes made by administrators that are not reflected in such updates.
As for CDA versus other report formats, I think it is probably premature to exclude anything IHE currently permits, which includes SR, CDA, PDF as well plain text (albeit the latter may be encapsulated). Note that keeping reports up to date is much more difficult than images (and not necessarily a PACS migration problem, as opposed to RIS/HIS migration).
posted on Tuesday, September 27, 2011 - 08:31 am
I didnt quite understand your post. Are you trying to make a difference between a "simple DICOM archive" and a "PACS"?
Is my understanding correct: "Simple DICOM Archive"---is a simple image file with what was sent to it. VNA = "Simple DICOM Archive" + "Database" (which holds demographics update/presentation state changes/annotations etc) without a viewer PACS= "Simple DICOM Archive" + "Database" (which holds demographics update/presentation state changes/annotations etc)+Viewer
Thanks for your comments Marco,---I suppose the VNA is cheaper than PACS because it does not have viewer & so also can act as an intermediate store when moving from 1 PACS to another.
Is my simplistic understanding correct?
posted on Tuesday, September 27, 2011 - 08:41 am
Regarding CDA vs DICOM SR this is worth a read. The direction is clear that CDA is the appropriate format for radiology reports. Displayable Report Profile of IHE also requires CDA. We will have discussions at Autumn Meeting from Micheal LaRocca, Dirco Van Norden, & Brian Elwood on CDA.
As we have a consistent approach for medical images--DICOM, we also need to move to a consistent approach to medical documents---let us hear what the experts have to say.
posted on Tuesday, September 27, 2011 - 09:16 am
It was my understanding that a VNA was just a simple DICOM store - the database removes the "N".
posted on Tuesday, September 27, 2011 - 10:24 am
Paul, I am no expert on DICOM or VNA, but it seems that the definition of VNA is very variable depending on whom you speak to. I prefer the broader term "Vendor Neutral Architecture" of which which "archiving" is only a component.
Temporary "DICOM archive" to ease the process of data migration for Trusts is a credible option as described by Marco. However, it is important that if DICOM data is held in a temporay/permanent DICOM store (like LSP CDS) they get regular demographics updates. These demographics updates are held in a PACS or VNA database.
We know that the image files archive is fairly standard (particularly if held in DICOM Part10 file format). It is only people who understand DICOM like David, Dave, Marco, Kevin Wilson, Sven Boule, Martin Peacock etc who can explain how we can standardise PACS/VNA database to ease of migration process
Everyone, please do correct me, if I have got the wrong end of the stick here.
posted on Tuesday, September 27, 2011 - 12:03 pm
Use of DICOM SR as per the presentation Harry Solomon:
"Planning your Electronic Reporting: What kinds of reports do you need? Text only Text + image references Structured text Structured text + coded content Multimedia"
"DICOM SR is used in key subspecialty areas that produce structured data in the course of image acquisition or post-processing, where: Leveraging the DICOM infrastructure is easy and desirable Results should be managed with other study evidence Examples Sonographer measurements Computer-aided detection results QC notes about images Radiation dose reports Image exchange manifests"
"CDA Case Uses Diagnostic and therapeutic procedure reports Encounter / discharge summaries Referrals
Consistent format for all clinical documents"
He describes how CDA & DICOM SR could be used in synergy--however, CDA is preferred format for the narrative nature of radiology opinions as we have them.