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.1138188.8.131.52,1.2.840.1138184.108.40.206 &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.
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.