Download Infoway-PHSDI-HScomments

From: Patrick E. Loyd [mailto:[email protected]]
Sent: Monday, June 12, 2006 2:49 PM
To: Solomon, Harry (GE Healthcare)
Cc: 'Helen Stevens'; 'Patrick E. Loyd'
Subject: RE: Infoway Public Health Surveillance Diagnostic Imaging Storyboard
Harry,
As your email was quite lengthy, it seemed best to provide comments inline. My comments are
prefaced with PEL>
Thanks.
Patrick
From: Helen Stevens [mailto:[email protected]]
Sent: Wednesday, May 31, 2006 2:55 PM
To: [email protected]
Subject: FW: Infoway Public Health Surveillance Diagnostic Imaging Storyboard
Can you send an appropriate response to Harry on behalf of the project please.
Helen Stevens Love
1959 Hampshire Road, Oak Bay,
Victoria, B.C. V8R 5T9
Land: (250) 598-0312, Mobile: (250) 888-5824
From: Solomon, Harry (GE Healthcare) [mailto:[email protected]]
Sent: Tuesday, May 30, 2006 7:35 AM
To: [email protected]; [email protected]; [email protected]
Cc: Chris Carr; Parisot, Charles (GE Healthcare); Fred Behlen (E-mail); Kevin O'Donnell
Subject: Infoway Public Health Surveillance Diagnostic Imaging Storyboard
Patrick and Helen –
I have concerns regarding the Infoway Public Health Surveillance Diagnostic Imaging
Storyboard and the associated proposed transactions presented at this month’s HL7
meeting, in particular with respect to the radiology workflow. I would like to discuss
some of the storyboard’s assumptions, and recommend revisions.
Storyboard and Section 1.2 - Diagnostic Imaging Candidate Query/Response
 Nurse Nightingale submits a query to the Diagnostic Imaging system to identify any
chest x-rays that are on file for Mrs. Nuclear and taken within the past ten years. The
response includes a list of seven previous chest x-rays that were performed over the
past ten years, the most recent being two years ago [Diagnostic Imaging Candidate
Query/Response].
The storyboard apparently assumes there is a single Diagnostic Imaging system to which
a query can be directed. In those areas with multiple DI providers and their separate
systems (i.e., most urban areas), either the nurse’s system must be configured with the
addresses of all the possible providers and separately query each one, or there needs to be
a central facility for obtaining the cross-enterprise list of available results. Such a crossenterprise results registry must be an explicit actor in the storyboard (unless you are
assuming the “Diagnostic Imaging system” is the cross-enterprise registry).
PEL> Agreed, the cross-enterprise registry is an explicit actor in the storyboard. In the
Canada Health Infoway architecture, there is a central “facility” for this centralized registry.
Storyboard and Section 1.3 - Diagnostic Imaging Detail Query/Response
 “Nurse Nightingale submits a second query for the details, including the images and
radiologist report for the most recently performed chest x-ray [Diagnostic Imaging
Detail Query/Response].”
 “She then queries for diagnostic imaging system for the results. The system responds
by providing the images and radiologist reports related to the chest x-ray order
[Diagnostic Imaging Detail Query/Response].”
It is important to distinguish between the radiology report and the images for three
reasons. First, the report is the formally attested result of the DI study – it is what the
radiologist asserts should be communicated to the referring healthcare provider. Images
are typically not part of the report’s attested content, but may be available as supporting
evidence. It is not up to the nurse to retrieve the images and second guess the
radiologist’s conclusions of what is and is not present in those images. Of course there
are reasons the referring provider will want to see the images, but such access is not
essential to the clinical workflow.
PEL> Agreed, the review of the image has been removed from the public health nurse’s
workflow
Second, retrieval of images is a secondary or contingent operation after retrieval of the
report. Clinically, the referring provider would first review the radiology report before
deciding whether or not to look at supporting evidence; e.g., if the report says “normal”,
there is no reason to retrieve the images. And as DI moves into “high definition” mode, it
is essential that the only the relevant part of an imaging study be retrieved. In fact, the
report may include references to the key images of the study that may be appropriate for
the referring provider, e.g., the one or two images in a 1000-image MR or CT study that
best show the presence or extent of the disease. The storyboard scenario should not
assume that (all) the images of the study are retrieved.
PEL> Agreed, the report retrieval is first.
The third reason to separate retrieval of report and of images is that the existing, agreed,
and universally implemented standard used to access images is DICOM, not HL7 v3, and
not DICOM somehow “embedded” in HL7 v3. HL7 needs to rely on the DI community
and DICOM to provide the most appropriate mechanisms for image access, even for the
HL7 environment. This is not a “turf battle”, but rather utilization of domain expertise
that takes into account the rapid evolution of DI technologies and the requirements of
both the DI department and image users outside the department. One important aspect of
this is having appropriate mechanisms to provide the necessary image quality with
respect to the displaying workstations, the tasks of the receiver, and the nature of the
intermediate network.
The image retrieval mechanism should therefore not be lumped into the same generic
Diagnostic Imaging Detail Query/Response as the radiology reports. The storyboard
should reflect this division of responsibilities.
PEL> Agreed, the retrieve of the report is a different transaction from the report retrieval.
With this separation of report and images, and with selective access to images, there is a
further issue that must be explicitly addressed. There is obviously a prerequisite that the
retriever have a means to identify the specific image(s) to be retrieved. This can be done
in several ways that represent different use cases, but all of which are fundamentally
acceptable. First, the retriever (nurse’s workstation) could directly interact with a PACS
query function to select images for display, either through the DICOM Query/Retrieve
service using the DICOM network protocol or via an interactive web interface.
Alternatively, as described above, the radiology report itself may convey the IDs of key
images and hyperlinks thereto, e.g., using the Web Access to Persistent DICOM Objects
(WADO) service. Finally, the PACS system may publish a document containing a
manifest of the images acquired in the exam, with hyperlinks, as an adjunct to the
radiology report, an approach used in the IHE Cross-Enterprise Document Sharing for
Imaging (XDS-I) profile. Since these imply very different implementation approaches, it
is important that the Public Health Surveillance storyboard should describe one of the
methods as the target use case for implementation in the Infoway context.
PEL> The image is available from the Diagnostic Image Repository (which gets the image
from the PACS system; the PACS system using a DICOM “push” transaction to copy the
image to the DIR). The iEHR project is determining how the shared record service and the
DIR will work together. However, both the iEHR index and the result report should contain
sufficient identifiers to query the shared record service (and subsequently the DIR) to
retrieve the images using WADO (which is being investigated).
Storyboard and Section 1.4 - Diagnostic Imaging Order Request
 “Nurse Nightingale decides that Mrs. Nuclear will require another chest x-ray, to
determine if the TB has now affected her lungs. A request is made to the diagnostic
imaging services. [Diagnostic Imaging Order Request]”
 Does the order need to be directed to a specific radiology department? [Your answer:
Probably not.]
 Does the order get published and “pulled” by the department where the patient
presents? [Your answer: Probably.]
An assumption of most HL7 orders is that the order is directed to a specific
department. An alternate model may be used, e.g., in the case of drug prescription orders
that might not be directed to a specific pharmacy. However, in that case, the interaction
model becomes much more complex, as the functions of a central registry/repository of
orders must be specified, as well as the additional transactions required between the
fulfilling organization and the registry/repository, not just to identify and “pull” the order,
but also to update status of order fulfillment. The central registry/repository must then
become an explicit actor in the storyboard.
PEL> It was agreed by the project to limit the amount of work done on the DI order to
developing the DI order message model itself based on the IHE Radiology Scheduled
Workflow profiles but that the PHS project does not intent to implement the entire orders
architecture needed for an order repository and those interactions/transactions necessary
to support a correct electronic orders flow. I will add minimal verbiage to the storyboard
to address this point.
Does Infoway want to require the development and deployment of a new class of crossenterprise order registry/repository actors, and if so, would such a capability be deployed
in the near term? (The cross-enterprise client registry has very different functions, as
does a cross-enterprise results/reports registry.)
PEL> The iEHR project is working out these similarities and differences.
Since there is an alternative model that does not depend on such an actor, I would
therefore recommend that the use case storyboard clarify the ordering process to include
having the nurse identify (with the patient) an appropriate DI service provider, and
sending the order directly to that provider.
PEL> In the use case I’m familiar with, the nurse does not know which radiology service
the patient will use. I don’t want to update the storyboard with incorrect
information. However, I will double-check on this point to be sure.


Does the order need to be scheduled? [Your answer: Yes in many cases…and this is
typically done via phone right now since we do not have community wide electronic
scheduling for DI]
The workflow for DI orders needs to be better understood specifically around the
scheduling.
In current DI workflows, as noted, scheduling is done interactively (by phone) between
the DI provider and the patient, or between the provider and the orderer acting as a proxy
for the patient. In the storyboard, this should be described as the admin at the DI
provider, after receiving the order, calling the patient and arranging a convenient time for
the x-ray. There is no need for the Public Health Surveillance use case to drive a crossenterprise DI scheduling functionality.
PEL> Agreed.
Storyboard – No Transaction
 “A few days after her chest x-ray, Nightingale receives a telephone notification that
the Order Request is complete. She then queries for diagnostic imaging system for the
results.”
 Intent is to develop the order message with basic accept/reject responses but not the
full result reporting capabilities at this time. Ordering system will submit a query for
the results when they are available.
A telephone notification is less reliable, and introduces more delay, than a system to
system electronic notification. Forwarding of results is a typical current function of
radiology workflow and implementations that should be used in the Public Health
Surveillance use case. If the ordering system can submit an electronic order, why would
it not be able to accept the radiology report, or at least a notification of the availability of
results?
There may be an issue with intermittent connection of the ordering system to the network;
if that is the concern, there are several mechanisms available within HL7 to provide
asynchronous messaging. Alternatively, it may be useful to look at the approach taken by
the IHE Notification of Document Availability Profile to asynchronous notification. That
uses an email notification with a manifest of the available document(s), and the URI to
access those documents.
Presuming an electronic result is used, whether the communication is the DI report itself,
or a reference to it, is somewhat a matter of style (or architectural preference). If the use
case wants to use a pull mechanism for getting the report, so that it is identical to the
other report retrieval mechanisms, that is fine. However, a push model for the report may
be simpler. In summary, I suggest that the use case storyboard describe an electronic
notification of the availability of the report, or electronic forwarding of the results to the
orderer’s system.
PEL> Will double-check on electronic notification vs. telephone. I agree with your
comments but this may be a scope issue.
Infoway and IHE
I would like to close with a final set of comments. The Infoway Radiology project has
made substantial progress by engaging industry through the IHE effort, developing a
consensus architecture and messaging profiles, as well as providing a forum and tools for
implementation interoperability testing. True, it has not been a “pure HL7 v3” design,
because the necessary pieces of v3 were not available for the desired implementation
timeline, so a pragmatic use of HL7 v2, DICOM, ebXML, etc. was adopted.
It is essential that the Infoway Public Health Surveillance project look at the IHE work
for the cross-enterprise radiology use cases, not just because the Diagnostic Imaging
storyboard needs to interact with the Infoway Radiology implementation. By
participating in IHE, Infoway PHS can facilitate the rapid deployment of a pragmatic
cross-enterprise implementation, leveraging the IHE testing methodology. And to the
extent that Infoway PHS insists on using HL7 v3 for profiled transactions, your
participation in IHE will help drive that to a broader industry implementation
PEL> Peter Bak has been Infoway’s champion for DI within the IHE domain. The PHS
project has scope limitations on what we can assist with. However, we are expecting to be
able to provide a starting model for the DI order and the DI CDA result to the IHE working
group considering these transactions in the future. Peter is walking that fine line between
the IHE transactions implemented by Infoway within the DI project while working with the
iEHR project which is mandating HL7 v3.0 canonical data which follows to HL7 v3.0
messaging where possible. The PHS project team will continue to work with Peter
regarding our project needs to keep them in line with the DI project requirements and
goals. Our expectation is that Peter will bring those materials forth to IHE which will assist
with the process of implementation profile development and deployment.
Thanks for your comments.
- Harry Solomon
GE Healthcare Integrated IT Solutions