Long Version.
One of the good things about Meaningful Use is that it has drawn attention to the View use case for images, all limitations with respect to Download and Transmit that I have bemoaned before aside. A similar use case is important to the UK Imaging Informatics community, and no doubt everywhere else too.
The ink is drying on the new Invoke Image Display (IID) Profile from the IHE Radiology Technical Committee, which is intended to help with this use case.
Since I have to give a Webinar on the subject next week, I thought I would discuss the general principles (you can find the slides here).
IID works with a simple HTTP GET request and some parameters encoded in the URL. One system, like an EHR or EMR or PHR (or RIS or HIS or whatever the "non-image-aware" system is), can request that one or more studies, identified generically by id and date range or recency, or specifically by UID or accession number, etc., be displayed by another system (like a PACS, VNA, Workstation, Viewer, Image Portal (Staff or Patient), Proxy or Gateway or whatever).
No questions asked. Just display it. No concerns about format. No SOAP. No XML. No REST. No arguments about capabilities. Just do what you are told. This approach appeals to the closet (?) autocrat in me.
Examples of different requests:
http://The "viewer" (Image Display), however it is invoked, whether it be on/from a phone, tablet or desktop, within the user's web browser, zero footprint or not, thin or thick client, or even a separate workstation sitting beside the browser computer (e.g. a mammography workstation), has certain minimum responsibilities. They are summarized as interactive viewing. They include navigating within the requested studies (including change studies, series, and scroll between images and frames), manipulating the appearance of the displayed image (window, zoom and pan), control over diagnostic quality or not, and key images only or not. The full Basic Image Review Profile is not required, but is a named type of viewer that may be requested and optionally supported.www.myhospital.org/IHEInvokeImageDisplay ?requestType=PATIENT &patientID=99998410^^^AcmeHospital &mostRecentResults=1 http:// http://www.myhospital.org/ www.myhospital.org/IHEInvokeImageDisplay ?requestType=STUDY &accessionNumber=93649236 IHEInvokeImageDisplay ?requestType=STUDY &studyUID=1.2.840.113883.19.110.4,1.2.840.113883.19.110.5 &viewerType=IHE_BIR &diagnosticQuality=true
This approach begs the question of how the requester knows which server to call. The answer in brief is by configuration (and perhaps matching of report locations to pre-configured lists of servers, etc.). But this is an alternative to having n:m proprietary customizations and configurations of EHR to PACS, and it is an alternative to hardwired URLs (e.g., to proprietary or WADO references to images) that may go stale, and require a separate viewer. And if the approach is adopted then an additional standard endpoint discovery mechanism could be figured out.
It also avoids questions of security (authentication, authorization and access control) by de-referencing these to whatever standard mechanisms can be deployed at a lower level that are appropriate for HTTP requests. So whether SAML, OAuth or something else prevails, or if in the worst case the invoked display requires one to log in yet again (ugh), or is just pre-configured to trust the requester, this again is a matter for site configuration.
There are other deployment questions that are important to consider, not the least of which is browser capability and permissions to install/execute JavaScript, Java, ActiveX, plug-ins, or whatever, assuming that the requester is even browser-based, and not a thick client or native app performing HTTP requests.
Regardless, it is expected that the deployment burden is lower with this approach than with proprietary customizations of a combinatorial explosion of pairs of EHR and PACS.
Thus, IID is one more standard "component" to use as a tool bring to bear on the non-trivial problem of image distribution and sharing, particularly with loosely coupled non-integrated systems.
Note also that IID is not confined to staff viewing use cases; there is no reason why the same mechanism can't be used for a patient portal that is not image enabled to request an imaging system to display images for a patient (non-trivial authentication, access control and provisioning issues having been addressed).
It is also potentially useful for commanding behavior in a workflow managed environment, i.e., to use a workflow application to command a workstation to display something (that it has or knows where to get), rather than having a workstation pull a work list and have a user select from it.
Historically, to give credit where it is due, the idea came from the IHE Cardiology group. They introduced it as a transaction in their Image Enabled Office Profile, and we have extended it and brought it out as a separate profile so that it may be more generally applicable (and Harry tells me he will update IEO retrospectively to account for our tweaks).
So, get coding ... it would be great to have a few IID implementations register for the IHE NA Connectathon in snowy Chicago in January 2014 to work out the kinks. Maybe I will see you there, if I haven't quit IHE by then because of the Certification nonsense, which continues to spread like a cancer throughout the IHE organization.
David
2 comments:
David.. The profile quite pragmatically suggests 'In the absence of a service to look up the endpoints, a hardwired or configurable (set of) URL
roots may be required.', which in many cases would end up being the only realistic approach, but would that 'service' not sit naturally on the shoulders of XDS Registry, particularly when it comes to incorporating other document types?
Hi Martin
That is certainly one possibility, and one which was discussed in the Rad TC. It would assume that the invoker was poking around in the XDS registry in the first place to find studies and documents. Since the invoker doesn't need XDS-I to get the images or the manifest when using IID, it also may not need to talk to the registry.
One of the ways in which IID can be used is without the need to involve XDS; i.e., the invoker asks for studies to be displayed and it is the display's problem to find them (whether in an XDS Registry or Imaging Document Source or through some other mechanism).
For example, an EHR may be configured to talk to one URL root for all patients, and the display can be a "proxy" that federates multiple sources of images "under the covers", whether they be from one PACS or VNA or XDS-I Imaging Document Source, or many.
Or, for each patient identity domain, the invoker might have a different pre-configured URL root.
But there is certainly nothing wrong with using XDS, especially if the EHR is already using it for accessing something else, like reports.
For that matter, if the report contains embedded location information (regardless of whether the report was obtained via XDS or some other means), that could be followed. Which reminds me, DICOM WG 8 is working on updating the CDA IG for Diagnostic Imaging reports, and explicit references to studies and perhaps key images in studies (not just single images) should be included as observation types, and perhaps an IID reference should be used as an example, similar to the WADO reference in the current C-CDA IG for the Level 3 content image reference.
That said, where the images reside (as known to an XDS registry), and where the display actor lives, may be two completely different locations.
Or to put it another way, IID does not assume any particular architecture.
Regardless, the general goal is to unburden the invoker (like an EHR) from details, like where stuff is and in what form it is, and leave that to the display.
In these respects, as well as many others, it is just like the ITI Retrieve Information for Display (RID) profile, on which the request mechanism is based. ITI Vol 1 Appendix E may be helpful (as long as you are careful not to confuse the different roles of the Display in RID as opposed to the Image Display in IID), and one day a similar Appendix for IID might be forthcoming.
David
Post a Comment