UK Imaging Informatics Group
XDS metadata-radiology requests, repo... PreviousNext
UK Imaging Informatics Group > Questions & Answers > PACS Integration & Standards >
Subtopic Last Post Last Poster Posts
Archive through May 06, 201406-05-14  05:26 pmChristopher Lindop20
Archive through May 14, 201414-05-14  03:58 pmChristopher Lindop20
Archive through August 04, 201404-08-14  10:19 pmNeelam Dugar20
 
Message/Author
 Link to this message Neelam Dugar  posted on Wednesday, August 27, 2014 - 07:09 am Edit Post Delete Post Print Post
I think this is our final version of Radiology Metadata with the 4 linked radiology documents.
application/mswordRadiology Metadata
Doncaster_and_Bassetlaw_-_XDS_Metadata_26-8-2014.doc (144.9 k)
 Link to this message Neelam Dugar  posted on Sunday, September 28, 2014 - 12:19 pm Edit Post Delete Post Print Post
Slight update--with folder and ContentTypeCode
application/mswordUpdated metadata
Doncaster_and_Bassetlaw_-_XDS_Metadata_17-9-2014.doc (143.9 k)
 Link to this message Neelam Dugar  posted on Wednesday, October 15, 2014 - 10:20 pm Edit Post Delete Post Print Post
ENT Metadata to include--Audiograms, ENT Referral Letters, ENT Clinic Letters, ENT Discharge Summary, ENT Operation Notes

This is my first attempt at a non image based specialty to incorporate into the XDS world. I was asked by ENT whether the Audiograms could be incorporated into our XDS based VNA. However, the tricky bit is the workflow. It is important that we do not introduce any extra steps for the already busy audiologists.
1. They have the audiogram on their computer screen which has a date-time stamp
2. They wish to pick up the patient demographic information from a bar-code scanner from patient's notes bar code.
3. They wish to have a 1 click "print to XDS" with the metadata wrapped
The workflow is a challenging one, but if we can do this we can look at other clinical images and documents.
application/mswordENT XDS Metadata
ENT XDS_Metadata.doc (122.9 k)
 Link to this message Neelam Dugar  posted on Sunday, October 19, 2014 - 09:26 am Edit Post Delete Post Print Post
Ensuring that the Patient ID within XDS Registry is up-to-date is ABSOLUTELY essential

http://wiki.ihe.net/index.php?title=Cross-Enterprise_Document_Sharing

http://jwenet.net/notebook/1777/1800.html

Please ensure that your PAS is providing the following updates to XDS Registry (PAS acting as the Patient Identity Source on the XDS diagram)
A04--HL7 ADT triggers with a new patient registration in the PAS is sent to XDS Registry
A40 --HL7 ADT triggers the merge patient Internal ID is sent to XDS Registry as well
 Link to this message Neelam Dugar  posted on Monday, October 20, 2014 - 08:15 pm Edit Post Delete Post Print Post
Understanding Document Replacement and Deprecation Workflow:

Those implementing XDS here is something that needs testing

DOCUMENTS REPLACED in XDS SOURCES should result in DOCUMENT DEPRECATION WORKFLOW in XDS Registry:
1. A request form, radiology report or radiology images have been submitted to the XDS Registry and Repository
2. If there are subsequent changes made to the documents on RIS or PACS (XDS sources)—addendum of report (addendum reports will include the original report text within the addendum report document), replace a request with a correct one, images added or deleted in PACS etc , the sources must send updated documents to XDS Registry and repository as “replacements”.
3. In the XDS registry, the original documents will have a “deprecated status” and become invisible to the XDS consumer. The new ones will become visible in the XDS consumer.
4. XDS Workflow required is “Replace an existing DocumentEntry. http://ihewiki.wustl.edu/wiki/index.php/Metadata_Patterns
 Link to this message Neelam Dugar  posted on Wednesday, October 22, 2014 - 05:40 pm Edit Post Delete Post Print Post
Those of you who are setting out to procure XDS consumers may find my advice useful. Please add it to your procurement documentation.

XDS CONSUMERS
1. XDS Consumers Must display the following 12 metadata items for each document in the registry--,Document Class, Document Type, Title of Document, Event Codes,(will contain 1 or more metadata items) Document Creation Date, Service Start and Stop Time, PracticeSettingCode, HealthcareFacilityTypeCode,, Legal Authenicator, and Author (Name, Role, Specialty and Institution). (NB: Service Start and Stop times are particularly relevant to clinical discharge summaries)
2. XDS consumers must make the user "aware" of the other “linked documents “ both at the time of list of documents are displayed ,and also when1 of the documents are opened by the users
3. XDS consumers must provide 1 click display of the documents types—DICOM, PDF/a etc when the user clicks to open a particular document.
4. Filtering by specialty in Event Codes Filter for Associated Specialties is KEY. For e.g. ENT doctor may wish that on first presentation he wishes to see only ENT related documents. He may then want to simply “un-tick “the filter to get visibility of all documents for the patient.. Filtering by other metadata items maybe useful too—Author etc
5. Sorting of documents : Creation date and specialty (event code --associated specialties) are the 2 key items for sorting of documents

Many vendors are putting in a lot of effort display functionality (XDS consumers)
 Link to this message Neelam Dugar  posted on Monday, November 03, 2014 - 10:30 pm Edit Post Delete Post Print Post
Updated Doc
application/mswordUpdated XDS Metadata set
Doncaster_and_Bassetlaw_-_XDS_Metadata_24-10-2014.doc (153.1 k)
 Link to this message Neelam Dugar  posted on Thursday, July 20, 2017 - 02:46 pm Edit Post Delete Post Print Post
I have added the XDS metadata to a spreadsheet in excel for Radiology, ENT, Cardiology and Ophthalmology.
application/vnd.openxmlformats-officedocument.spreadsheetml.sheetXDS metadata-various specialties
XDS Metadata.xlsx (32.5 k)
 Link to this message Colin Evans  posted on Friday, July 21, 2017 - 02:22 pm Edit Post Delete Post Print Post
Hi Neelam.

You recent posting shows as a ".unk" file, although it opens correctly if renamed. Error in posting, or just a feature of the way the board software works?
 Link to this message Neelam Dugar  posted on Friday, July 21, 2017 - 02:28 pm Edit Post Delete Post Print Post
Will try again. Maybe my end.
 Link to this message Neelam Dugar  posted on Wednesday, July 26, 2017 - 12:28 pm Edit Post Delete Post Print Post
Unable to upload word and excel docs onto this website anymore. Sorry. Please send me a message and I will email it to you.
 Link to this message Colin Evans  posted on Wednesday, July 26, 2017 - 12:58 pm Edit Post Delete Post Print Post
Hi Neelam,

No need to repost the file, thanks. As I said it's readable if you download and just change the file suffix to .xlsx

Unfortunate (and rather ineffective) restriction to add to the board software IMHO. It might be worth establishing a convention for attachments. If zip files still work then zipping everything would be an option.
 Link to this message Neelam Dugar  posted on Wednesday, July 26, 2017 - 06:48 pm Edit Post Delete Post Print Post
Thanks Colin. Glad you were able to open it. Anyone who is interested in the XDS metadata for Radiology, ENT, Cardiology, and Ophthalmology and is unable to open the file--please send me a private message --and I will send it to you.

Colin,
I would be interested in your views. I am trying to map across XDS metadata to FHIR resources--I have tried to do this for the radiology sheet initially. I am aware that FHIR consumer queries of DICOM images and PDF/CDA documents held in the VNA is essential for making VNA content more accessible. VNA industry is already heading in the direction of enabling FHIR query on the VNA content.
https://www.dcmsys.com/2016/01/14/firebridge-from-dicom-systems-makes-fhir-integ ration-easy/
 Link to this message Kinson Ho  posted on Wednesday, July 26, 2017 - 07:11 pm Edit Post Delete Post Print Post
Hi Neelam,

IHE ITI just published a revised version of the MHD profile. In this profile, you will find a mapping from XDS Document metadata to various FHIR sources such as DocumentReference, DocumentManifest, etc.

You can find MHD here

http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD.pdf

Kinson
 Link to this message Neelam Dugar  posted on Wednesday, July 26, 2017 - 07:24 pm Edit Post Delete Post Print Post
Hi Kinson,
Many thanks for this. It seems IHE and FHIR are working very closely together--really good news for us as customers. This will make a vision of Paperless NHS a reality for us--whilst retaining patient safety at the heart of it. I do believe the PACS and VNA vendors will be industry drivers and will help NHS to move from filmless to paperless and unlocking the data from the digital silos that exist!!!

Can I please ask a simple question (non-techie)--what is the difference between a "document resource" and "document manifest". I mapped across the FHIR document manifest to XDS metadata and then found the FHIR document resource which has a few extra items!!
 Link to this message Kinson Ho  posted on Thursday, July 27, 2017 - 02:27 pm Edit Post Delete Post Print Post
Hi Neelam,

I assume you mean 'DocumentReference' and 'DocumentManifest' resources that are available in FHIR and are used in MHD. In MHD, DocumentReference is used to map metadata from XDS DocumentEntry, i.e. the metadata of the document. DocumentManifest is used to map metadata from XDS SubmissionSet, i.e. the metadata of a session.

So Find Document Manifests [ITI-66] is equivalent to FindSubmissionSet in XDS Registry Stored Query. Find Document References [ITI-67] is equivalent to FindDocuments or FindDocumentByReferenceId.

Kinson
 Link to this message Neelam Dugar  posted on Thursday, July 27, 2017 - 02:59 pm Edit Post Delete Post Print Post
Thanks Kinson,
That makes some sense to my non-techie brain :-). I have been working on interpreting XDS metadata from a clinical context and HL7 v2 message items/DICOM tags for some time. So now all I need to do is map FHIR DocumentReference to XDS metadata. This is what I was doing last night.

So here is what I think I have found in FHIR DocumentReference items --which do not exist as XDS metadata items
1. DocumentReference.custodian-Identifies the organization or group who is responsible for ongoing maintenance of and access to the document.
2. DocumentReference.status--current | superseded | entered-in-error(Required)
3. DocumentReference.docStatus- preliminary | final | appended | amended | entered-in-error (required)
4. DocumentReference.context.encounter-Describes the clinical encounter or type of care that the document content is associated with-inpatient | outpatient | ambulatory | emergency

There are many items from DocumentReference that I think would just map to Reference ID in XDS metadata.

I think the direction of travel will be for "XDS registries" within a VNA to become a "FHIR DocumentReference Resource"--with some additional data items. I dont think this will be difficult for them. Am I correct my in thought processes. I would value your and other experts comments.
 Link to this message Kinson Ho  posted on Thursday, July 27, 2017 - 03:55 pm Edit Post Delete Post Print Post
Hi Neelam,

Here are the mapping defined in MHD:

DocRef.custodian - Not used for XDS mappping
DocRef.status - XDS document status Approved maps to 'current' and Deprecated maps to 'superseded'
DocRef.docStatus - Not used for XDS mapping
DocRef.context.encounter - Maps from the encounter ID in the ReferencedIdList if available and a FHIR Encounter resource is also available.

You can find more details in Table 5.4.1.1-1 in MHD.

So one possibility is that XDS Document Registry also becomes a FHIR server that can handle the Find Document References and Find Document Manifests query. Or there can be a FHIR Server proxy box that will delegate queries to an XDS Document Registry.

Kinson
 Link to this message Neelam Dugar  posted on Thursday, July 27, 2017 - 10:29 pm Edit Post Delete Post Print Post
Many, many thanks Kinson. Table 4.5.1.1-1: FHIR DocumentReference mapping to DocumentEntry is really useful.

What I have tried to do in my excel spreadsheet (radiology worksheet) is to map the following:
1. NHS clinical terms (from NHS data dictionary codes)--column A
2. XDS Metadata--column B
3. FHIR Document References-column C
I have then applied them to the radiology document and images--in columns D, E, F and G (which in turn are mapped to HL7 v2 fields and DICOM tags).

The purpose is to encourage industry (RIS and PACS vendors) to submit to XDS repositories with ease--documents and images--lowering the barriers to XDS adoption in the NHS. VNA and XDS will lead to a safe and cost effective path to a paperless NHS.

I have done the FHIR to XDS mapping to NHS terminology in order to encourage XDS registry vendors to consider FHIR adoption by becoming FHIR server (or including a FHIR server proxy box). Most vendors struggle with mapping to NHS clinical terminology--and that is the bit I have tried to help with.

I would be grateful if you could look at the excel spreadsheet and let me know what you think.

application/vnd.openxmlformats-officedocument.spreadsheetml.sheetXDS metadata-various specialties-Updated
XDS Metadata-27072017.xlsx (36.5 k)
 Link to this message Nick Hollings  posted on Friday, May 10, 2019 - 03:10 pm Edit Post Delete Post Print Post
Hi All
Has anyone got an up to date solution/best way of storing .pdf files in PACS. I'm aware of DICOM supplements 104 and 127 to 'wrap' pdfs and then there's the XDS route described in the thread above.
The issue is how to store reports received back from Heartflow for cardiac CT computational flow dynamics. Currently the report is received as a .pdf but we would like to to use PACS to store a copy of the file (as well as it being stored in the patient's EPR). That way the CT and flow diagram can be viewed simultaneously on the same platform (i.e. PACS).

Also, the file arrives back in the 'Connect' box in the server rack. Is there a way to configure the box to automatically send a copy to PACS rather than it have to be done manually?

Make sense? (probably not!).

Many thanks in anticipation of any suggestions.
 Link to this message Neelam Dugar  posted on Friday, May 10, 2019 - 04:36 pm Edit Post Delete Post Print Post
https://www.medicalconnections.co.uk/kb/How-To-Import-PDF-To-DICOMPDF/

https://support.dcmtk.org/docs/pdf2dcm.html

Here are some links. You would need to talk to the companies for process automation.
 Link to this message David Clunie  posted on Friday, May 10, 2019 - 04:45 pm Edit Post Delete Post Print Post
http://www.dclunie.com/pixelmed/software/javadoc/com/pixelmed/convert/Encapsulat eData.html
 
Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users may post messages here.
Password:
Options: Automatically activate URLs in message
Action: