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?
posted on Saturday, April 22, 2017 - 09:12 pm
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.
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.
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.
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?
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.
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.
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
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.
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.
> 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.
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.
posted on Wednesday, June 07, 2017 - 08:38 am
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.
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.
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)."
posted on Wednesday, June 14, 2017 - 11:52 am
** Commercial Interest Declared **
Just for info, that product is no longer vested with EMC and is part of OpenText.