UK Imaging Informatics Group
VNA support of FHIR queries PreviousNext
UK Imaging Informatics Group > Questions & Answers > PACS Integration & Standards >
Message/Author
 Link to this message Neelam Dugar  posted on Saturday, April 22, 2017 - 07:46 am Edit Post Delete Post Print Post
VNAs are being implemented very rapidly in the NHS.
NHS vendors are being encouraged to support FHIR based queries by NHS Digital
Are VNA vendors developing FHIR APIs to support FHIR based queries to the XDS Registry and Repository?

https://fhirblog.com/2013/11/05/fhir-and-xds-an-overview/

https://fhirblog.com/2013/11/19/getting-documents-from-a-fhir-xds-infrastructure /

I am trying to understand how the XDS infrastructure within VNA will support a FHIR query from other applications that are capable of FHIR query.

Any comments will be gratefully recieved.
 Link to this message Neelam Dugar  posted on Saturday, April 22, 2017 - 08:05 am Edit Post Delete Post Print Post
https://www.hl7.org/fhir/documentreference.html

Another useful resource for VNA vendors
 Link to this message Dave Harvey  posted on Saturday, April 22, 2017 - 09:12 pm Edit Post Delete Post Print Post
It's important to realise that FHIR is really still at a very early stage (like HL7 V3 when NPfIT started!) - we still have only a "draft standard for trial use" (DSTU3 was just released), and real-life implementations either for imaging or for other uses are extremely rare. Yes, it MAY become important in the future, and the IHE MHD profile (and MHD-I specifically for imaging) are working on how best to handle integration between new FHIR implementations and existing systems, It is important to see FHIR as a FUTURE possibility, with guaranteed implementation by vendors once stable in a few years, rather than something to worry about and hold up new purchases for at the moment.
 Link to this message Robin Breslin  posted on Wednesday, April 26, 2017 - 01:47 pm Edit Post Delete Post Print Post
So, FHIR and VNAs. Good topic.

Firstly - what are your main purposes for a VNA (Neelam - you have very well captured this in other posts). If I characterize this by saying,
a VNA captures the outputs / results of a diagnostic department (or set of departments) in their native formats. So they can be consulted more widely in the healthcare settings (in hospitals, regions etc) and so that the records are preserved into the future for use with future systems (hence the need for the 'Neutrality' bit).

This in itself pushes the VNA to be a system that manages documents (or sets of documents and of course images).
They are whole and complete in themselves.

Compare and contrast this with an EPR - where there are more granular data items about a patient; Name, ID, DoB, InPatient/Outpatient ...). Yes, all of these elements could find themselves in a document - but then if you base interoperability purely on Documents, you will give the job of extracting the data element you want from a document.

Now - often you will see VNA+XDS as a pure open standards Document based solution. And there are aspects of XDS that can and do cope with very granular information (even fundamental XDS things like PIX / PDQ).
But you can also see how FHIR has its true heritage in HL7 - a messaging system to carry granular data elements.

I am more and more convinced that the two (XDS and FHIR) will continue to inter-twine. We already have the 'mobile health' extensions to XDS that use FHIR.

I think the next arena will be in the DSUB type of exchange (the notification - rather than just using DSUB, you could notify in FHIR ..).

The strengths of XDS are its document focus, but most of all is hub-and spoke nature (with a central register).
FHIR does not have this, and if such a thing is developed in FHIR, it will simply replicate that which exists already in XDS. Note, by the way, this will also necessitate a FHIR ATNA - this is a natural consequence).

So - back to the question. Does a VNA need FHIR? For what - so serve up documents in an alternative messaging format? Why not. Not a problem and if it helps facilitate Interop all good.
If it is, however, to deconstruct the VNA further, and dip into the interior content of documents to provide individual elements from a document, then probably not. This rather breaks the fundamental concept of what a VNA is and sends it off in the direction of becoming an EPR.

Could there be some examples (hybrid) - possibly. You would have to clearly identify what data elements you wanted and have your VNA/XDS layer capable of finding that for you (the right element in the right document) - just a further thought on this; if you implemented this as a kind of "crawler" trawling through your VNA documents, looking for the right patterns (Patient+exam+DocType+resultTyp In Doc), aren't you into a deeper data mining here? And would you consider deep learning and natural language processing as an alternative method.

Love the question - I'd love to do a presentation on the subject somewhere.
 Link to this message Neelam Dugar  posted on Wednesday, April 26, 2017 - 08:00 pm Edit Post Delete Post Print Post
You make some good points Robin.
XDS--document based standard
FHIR--granular data based standard

I think we need both. There is a huge drive by NHS Digital towards FHIR. EPR vendors are being encouraged to support FHIR queries by supporting a FHIR API. XDS Registry does have "granular data" which could be made to support a FHIR query. This would provide information of what is held in the XDS repostiroy of the VNA. One would still need an XDS consumer to display these document but it provides a FHIR interface to the document list.

"The VNA supports a FHIR query"--is a very powerful assertion to make about interoperability.
 Link to this message David Clunie  posted on Thursday, April 27, 2017 - 03:03 pm Edit Post Delete Post Print Post
This sounds like the "huge drive to HL7 V3", or "CORBAMed", or "Grid Services" or any number of hot trends, and we know how well they all worked out.

FHIR-based queries of what, for what purpose?

"The VNA supports a FHIR query" is a demand for an elephant-sized pile of steaming stuff that helps nobody.

Sort of like demanding "ASCII" or "XML".

To be of any use to anyone you need to specify:

- which FHIR resources
- with which profile to make which attributes required (since many are optional)
- for what use case
- using which FHIR version (they change dramatically, frequently; this is fatal haemorrhaging edge stuff)
- as an alternative to what incumbent or alternative solution (if any) with a justification to use FHIR instead

One must resist clueless management "huge drives" to latest fads that only maximize buzzword compliance without out adding real value.

Once it has proven utility, then you can add it (and you can be sure the vendors will if there is sufficient meaningful customer demand).

How about suggesting one FHIR resource that maybe makes sense some of the time as a gratuitous alternative to the XDS-I manifest or QIDO-RS, and explaining why it makes sense?

David
 Link to this message Neelam Dugar  posted on Thursday, April 27, 2017 - 06:10 pm Edit Post Delete Post Print Post
David,
Your cynicism is valid.
https://fhirblog.com/2013/10/18/fhir-searching/

Use case:
RIS/PACS/EPR/Healthcareapp initiates a FHIR query with query attribute -"patient"
VNA response is with a "list" of documents and images stored in VNA.
I am aware that an XDS consumer will be able to do this and also display the documents and images. However applications may choose to integrate an XDS consumer or simply want to just show a document list using a FHIR query.

Big vendors like Cerner are signing up to FHIR.
 Link to this message Neelam Dugar  posted on Monday, May 01, 2017 - 05:15 pm Edit Post Delete Post Print Post
https://healthcaresecprivacy.blogspot.co.uk/2017/05/ihe-iti-on-fhir.html?spref=t w&m=1
 Link to this message Filip Klintenstedt  posted on Monday, May 15, 2017 - 04:03 pm Edit Post Delete Post Print Post
Filip with Sectra here again, declaring commercial interest =)

Robin and David to indeed make some valid points around the utility of FHIR queries for the VNA. However while that is true there are also some advantages that we've seen.


First of all let's assume the current state of affairs that is common, especially in the UK.
Scenario 1:
You have a VNA and a single or multi instance PACS.

Potential advantages of FHIR compliant VNA - EMR/EPRs are typically not very good at DICOM to say the least (for obvious reasons, there is no reason for them to be good at it). This leads to them also being pretty bad at / uninterested in developing WADO consuming end-points. However if FHIR gets big (Certainly looks more promising than e.g. CORBAmed :D ) then it's likely easier for them to use Image Resources with FHIR (very similar to WADO but still..) to consume images from a VNA. Now most of integration are with Universal viewers on VNA/PACS today but there might be use cases where it would be worth getting images/thumbnails into EMR.
I'd classify this scenario 1 as somewhat but not terribly useful.

Now.. Consider the future. I think all see the trend that as more and more vendors are offering VNAs with diagnostic viewers directly attached.

Scenario 2:
Single instance VNA. No enterprise PACS (possibly local PACSes for odd workflows), diagnostic viewer on VNA for all major service lines / -ologies.

All of a sudden it DOES make sense to integrate VNA to other systems using FHIR. With Sectra VNA we have a few implementations of this where we query information from EPRs using FHIR. This queried information is delivered together with the streamed diagnostic image directly to the reading physician. This makes it possible to show information relevant for image reading in the viewer even though that is information that you'd never store in a VNA. Please contact me via email if you are more insterested to know in detail what we are doing.

So.. I do think it's certainly valid to require your VNA provider to, if nothing else, be involved in FHIR discussions and see what actual clinical workflow problems can be solved using it.
I mean there have been many many projects where we've thought "If only HL7 could query" so I doubt we've seen the last of FHIR.


Thank you for an interesting topic as always.
 Link to this message Neelam Dugar  posted on Monday, May 15, 2017 - 09:59 pm Edit Post Delete Post Print Post
Hi Filip,
Interesting take on the subject.

FHIR =access to data within databases (common coding)

XDS registry with FHIR API would allow document list to be visible to other applications.

Viewing application (PACS or other)
1. XDS consumer compliant viewer-would allow display of images and docs held in the VNA
2. FHIR compliant viewer would allow access to information stored in FHIR complaint EPR.

Both XDS and FHIR are about unlocking data for consumption by viewers
 Link to this message Filip Klintenstedt  posted on Tuesday, May 16, 2017 - 10:26 am Edit Post Delete Post Print Post
(Commercial interest)
Hi.

To be honest I don't see any big benefits of having an XDS registry with a FHIR API on top. I may be wrong here but I would guess that most applications interested in showing documents from XDS would implement XDS consumer functionality as opposed to using FHIR here.
But yes, I just argued that EPRs for instance don't care much about DICOM and as such are not too keen on WADO etc. either. So who knows maybe FHIR to consume XDS will be a thing to for applications who don't know much about XDS. We'll see =)


The rest of what you write I totally agree with.
By integrating XDS document consumer and Image Consumer with FHIR data from EPRs etc. we really can provide a one stop shop for effective reading within radiology and other diciplines.
 Link to this message Neelam Dugar  posted on Tuesday, May 16, 2017 - 10:08 pm Edit Post Delete Post Print Post
Hi Filip,

In the past archive vendors like PACS and EPR vendors have "locked in" the data --so that it is only consumed by their consumers/display/viewer.

This is all changing with standards adoption
1. XDS for documents and images
2. FHIR for discrete data types

The next generation of "consumers" or "viewers" or "portals" will need to display data from XDS registries/repositories and FHIR databases and present to customers in a meaningful and efficient manner.

XDS and FHIR are a very powerful combination!
 Link to this message Graham King  posted on Monday, June 05, 2017 - 06:42 pm Edit Post Delete Post Print Post
Commercial Interest declared **

I noted Filip's comment with interest, but I have to disagree

> To be honest I don't see any big
> benefits of having an XDS registry
> with a FHIR API on top.

I think there is a clear benefit: FHIR queries / submission enables mobile devices to participate in an XDS-like framework without needing a SOAP toolkit.

FHIR still lacks the concept of a central index / registry of data which is available within a particular domain of IT systems, and XDS can provide this.

I'm very surprised that no-one's mentioned IHE's Mobile Access to Health Documents (MHD) integration profile, which uses FHIR APIs to provide access to an XDS Registry / Repository

http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)

The Wiki page itself outlines the benefit but also makes clear that MHS does not equal XDS

"The MHD profile does not replace XDS. It can be used to allow mobile devices, or other resource constrained systems, access to an XDS health information exchange"

Lexmark Acuo VNA already supports MHD and we've been to a Connectathon to test it.

On a vendor-neutral note, if you have has 10 minutes to spare, I do recommend Robin Breslin's recent talk on interoperability, FHIR, sharing and XDS at eHealth week.

https://www.youtube.com/watch?v=3OO_oETNc5s

And if you don't have 10 mins, the question about FHIR at 6m38s can be jumped to right here
https://youtu.be/3OO_oETNc5s?t=6m38s

Best wishes
Graham King
Solution Architect EMEA
Lexmark Healthcare from Kofax
 Link to this message Rene Spronk  posted on Monday, June 05, 2017 - 08:00 pm Edit Post Delete Post Print Post
> FHIR still lacks the concept of a central index / registry of data which is available within a particular domain of IT systems

FHIR is an interoperability specification, and as such it does support the data structures (resources) needed to support such a registry (those resources have been harminised with the efforts of IHE, see http://build.fhir.org/documentreference.html and http://build.fhir.org/imagingmanifest.html - the latter being the equivalent of a KOS Manifest), without actually going as far as specifying what kind of functionality such a registry should have. That is the role of orgnisations such as IHE.

See http://www.ringholm.com/column/IHE_XDSc_FHIR.htm - the MHD et.al. profiles already enable one to support XDS in a non-webservices, FHIR/REST based fashion.

TTYL,

-Rene
 Link to this message Niklas Svenzén  posted on Wednesday, June 07, 2017 - 08:12 am Edit Post Delete Post Print Post
Commercial interest declared***

I noted Grahams comment on the benefit of FHIR on top of an XDS interface. I agree that the RESTful interface of FHIR is much more appealing than the bit heavy weight SOAP interface of XDS.

However, in how many case do you foresee the web page of the client to talk directly with the registry? Most modern apps or zero footprint viewers will come with an application server that does all the heavy lifting. Putting a FHIR interface out there just to make life a little easier for the web server developers seems a bit excessive to me. I am all for RESTifying XDS, but would rather see that being done instead of patching it with FHIR.

To me FHIR is an awesome protocol to be used as an augmentation of existing interfaces, i.e. a granular query interface when you don't necessarily want to extend you internal data model just to be able to store a few extra HL7 v2 fields. FHIR allows you to keep your existing integration investment and infrastucture while also giving the option to add metadata from other systems without having to wait for the next release from two vendors.

Thanks,
Niklas Svenzén
Chief Solution Design
Sectra
 Link to this message Rene Spronk  posted on Wednesday, June 07, 2017 - 08:38 am Edit Post Delete Post Print Post
A more radical thought: once could build a FHIR Server that acts as a frontend for a (preferrably DICOMWeb enabled) DICOM image archive, and serves all of the imaging content as well as EHR content as FHIR resources via one single REST interface.

FHIR-based-XDS would in that case just be a virtualized version of the above.

I do realise this may not be a popular concept given the focus of this forum; technically and in terms of architecture and the mapping of content it certainly can be done.

TTYL,

-Rene
 Link to this message Neelam Dugar  posted on Friday, June 09, 2017 - 10:53 am Edit Post Delete Post Print Post
My key interest is in "Consumers" or "Clinical Portal" to be able to "consume" and display data from FHIR databases, and also XDS registries and repositories and bring information "together". This is what I think is important from a clinical/patient perspective.

Robins white paper explaining difference between interoperabilty and intergration is excellent! Thanks Robin.
 Link to this message Neelam Dugar  posted on Sunday, June 11, 2017 - 08:34 am Edit Post Delete Post Print Post
https://www.emc.com/collateral/TechnicalDocument/docu60313.pdf

EMC
"The Cross-enterprise Document Sharing (XDS) REST services are a set of RESTful web services
that provide an interface to interact with the healthcare documents in XDS Repository and their
metadata in XDS Registry. The XDS REST services model healthcare documents (Document) and
their metadata (Document Dossier) in the XDS Repository as resources, and identify resources by
Uniform Resource Identifiers (URIs)."
 Link to this message Graham King  posted on Wednesday, June 14, 2017 - 11:52 am Edit Post Delete Post Print Post
Thanks Neelam

** Commercial Interest Declared **

Just for info, that product is no longer vested with EMC and is part of OpenText.

http://documentum.opentext.com/documentum/

Best wishes
Graham
Lexmark Healthcare from Kofax
 
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: