posted on Wednesday, October 15, 2014 - 10:20 pm
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.
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
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
posted on Wednesday, October 22, 2014 - 05:40 pm
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)
Unable to upload word and excel docs onto this website anymore. Sorry. Please send me a message and I will email it to you.
posted on Wednesday, July 26, 2017 - 12:58 pm
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.
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/
posted on Wednesday, July 26, 2017 - 07:11 pm
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.
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!!
posted on Thursday, July 27, 2017 - 02:27 pm
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.
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.
posted on Thursday, July 27, 2017 - 03:55 pm
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 18.104.22.168-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.
Many, many thanks Kinson. Table 22.214.171.124-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.
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?