Question regarding IHE approach
fred trotter
I wanted to briefly continue the discussion that I started on
the phone call yesterday regarding the compatibility of NHIN Direct
messages and the IHE Direct Messages on NHIN Exchange. I apologize for
discussing things like this on the list, but I will not be able to
make the face-to-face.. I am still in Finland...
I was hoping someone from the IHE could comment on my thinking
and assumptions here, I do not understand either IHE or the specific
implementation plan that the IHE group is discussing.
When a provider is using an EHR inside a hospital and that EHR is
fully implementing IHE profiles and is fully connected into the NHIN
Exchange, he will be able to send Direct messages using XDR/XDM to
other providers also fully connected into the NHIN Exchange. That
experience, like NHIN Direct will be "email like". We can refer to
that as NHIN Exchange direct message sub-network.
The large benefit of the IHE-based NHIN Direct proposal is that the
NHIN Exchange direct message sub-network will automatically talk with
NHIN Direct. In fact, under the IHE implementation proposal it might
be right to think of NHIN Direct and the "NHIN Exchange direct message
sub-network" as really being part of the same thing.
Of course the model allows for HTTP/SMTP/Other edge protocols, when
those protocols are configured to provide the "minimum needed" IHE
related content so that a proper translation to the IHE XDR/XDM
backbone can occur.
We can talk about this idea is "IHE in the core"
So far I am just mirroring what I understood from the presentation and
the answer to my questions, please correct me if I misunderstood.
On the phone it seemed like that we left it at "you have to have a
locally generated patient id to send a message into NHIN Direct if we
use an IHE core"
I did not have time to pursue the discussion to far, but it seemed
like this issue is pretty central to the IHE at the core vs just a
bridge to IHE debate.
Is that true? Am I missing something?
-FT
--
Fred Trotter
http://www.fredtrotter.com
Moehrke, John (GE Healthcare)
I think you are simply asking if the IHE solution requires a PatientID,
right?
In the case of XDR, there is recognition in the IHE profile that the two
partners may not have a common patient ID mechanism (which XDS did force
through the use of PIX).
In the case of XDM, there is even stronger recognition that the sender
(exporter) may not know where the 'media' will end up. Recognize that
XDM supports USB-Memory, CD-ROM, as well as the ZIP in e-Mail. The
use-cases for XDM were clearly cases where the patient may take control
of their data and be in total control of where they go. The XDM profile
enables patients to take physical control of their records and allows
the to go anywhere in the world. The XDM profile can be used direct
between providers, and is in areas of Europe.
So in both cases, IHE provides a place to put what ever Patient ID that
the source wants to put in there (enabling policy, not mandating
policy); but there is clear recognition that the receiver may be unable
to use this value. The reason to have a well-known place to put it
allows for ultimate use in environments where there is a common patient
ID domain, but also to support automation where the receiver receives
n+1 updates and can match the original source patient ID to assist with
the n+1 instances. Without a place for the patient ID neither of these
can be 'enabled'.
John
> --
> You received this message because you are subscribed to the Google
Groups
> "nhindirect-discuss" group.
> To post to this group, send email to
nhindirec...@googlegroups.com.
> To unsubscribe from this group, send email to nhindirect-
> discuss+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/nhindirect-discuss?hl=en.
Adrian Gropper
How does one execute a round trip in a standard XDR environment where there is no common patient ID mechanism?
More specifically, if the sender (say Provider A) uses patient ID PA1 to send the first message with XDR, can the recipient (Hospital B) reply using XDR and the patient ID PA1 as well?
Adrian
To unsubscribe from this group, send email to nhindirect-disc...@googlegroups.com.
--
Adrian Gropper MD
MedCommons
agro...@medcommons.net
Moehrke, John (GE Healthcare)
The Patient ID field is multi-valued… so YES, a ‘nice’ Hospital B would reflect what ever patient ID they received to help Provider A.
John
fred trotter
Thanks this is exactly the kind of data that I was hoping to get.
What would be the implications of a sender who always chose the same number like #1, or a new random number for the patient id each time?
I am trying to determine if there is any way to use IHE without needing a local store of patient ids?
-FT
Moehrke, John (GE Healthcare)
John
-----Original Message-----
From: "fred trotter" <fred.t...@gmail.com>
Subj: Re: Question regarding IHE approach
Date: Thu Jun 10, 2010 1:49 pm
Size: 2K
To: "Moehrke, John (GE Healthcare)" <John.M...@med.ge.com>
cc: "Adrian Gropper" <agro...@medcommons.net>; "nhindirect-discuss" <nhindirec...@googlegroups.com>
John,
Thanks this is exactly the kind of data that I was hoping to get.
What would be the implications of a sender who always chose the same number
like #1, or a new random number for the patient id each time?
I am trying to determine if there is any way to use IHE without needing a
local store of patient ids?
-FT
On Thu, Jun 10, 2010 at 9:39 PM, Moehrke, John (GE Healthcare) <
John.M...@med.ge.com> wrote:
> The Patient ID field is multi-valued� so YES, a �nice� Hospital B would
> reflect what ever patient ID they received to help Provider A.
>
>
>
> John
>
>
> ------------------------------
>
> *From:* agro...@gmail.com [mailto:agro...@gmail.com] *On Behalf Of *Adrian
> Gropper
> *Sent:* Thursday, June 10, 2010 1:29 PM
> *To:* Moehrke, John (GE Healthcare)
> *Cc:* fred trotter; nhindirect-discuss
> *Subject:* Re: Question regarding IHE approach
Matt
Source to supply a patient id (even if Destination wont recognize it),
is the more fundamental requirement that the XDR transaction involves
passing clinical information about only ONE patient. Generating a
surrogate patient identifier in the source is simple, but when the
source is plain old email making sure they are sending info about one
patient per NHIN Message is not. The only solution I see to this
problem is to specify some additional MIME headers that can be used to
assert patient identity of various message parts. A step-up converter
(or bridge in a NHIN exhcnage GW) could then reliably/safely convert
these potentially multi-patient NHIN messages into 1 or more per-
patient XD* transaction payloads. Without that additional patient
identity metadata its impossible to safely dissect a random free-
ranging MIME message that could be about multiple patients or no
patient at all into an XDR message. The other options is to modify
the XDR standard to permit transactions with no patient context, but
then almost all the benefit of the metadata in push style
communications is lost.
If SMTP/MIME is chosen for the backbone, we should specify an optional
MIME header that asserts patient idenity even if its a generated
surrogate value that the Destination cannot cross-reference...
because its more than an identifier. Its an assertion that this
particular message part is talking about a particular patient. Why is
that useful? Because only the sender at the Source can make the
judgement about which message attachments are for which actual
person(s). What IHE does is provides a metadata structure that allows
multiple message parts (documents in IHE-speak) of any content type to
be grouped together in one per-patient package. Even when 2 CDA
documents for the same person have differing patient ids IHE metadata
and packaging provides a way for Source to assert that these apples,
oranges and lemons all these belong to the same person. The one thing
an IHE XDR Document Recipient can count on even if it doesn't
understand any of the codes or identifiers in the XDS metadata is that
everything in the package is about a *particular* patient. That is
valuable and crucial in reducing medical errors caused by misfiling of
the received information. Without it the Source can take a large
jumble PHI, send it securely to a Destination and hope the Destination
is careful and scrupulous enough to inspect each piece, read the whole
message and not just assume the whole message is about the first
patient identity they see and file it all in that one patien't chart.
It won't take long before NHIN Direct Destinations get sick of lazy
sources who just bundle a bunch of stuff (e.g. Here are 3 referrals
for you with these 3 patients 9 attachments) and ask NHIN to define a
policy prohibiting multi-patient messages. When that day comes, we'll
want that MIME header and the IHE metadata will start making sense.
IHE has been further down this rabbit hole than most others.
And allowing smarter NHIN Direct Source systems that just email
clients to stuff patient identity assertions about the content in the
form of additional MIME headers would allow a smart Destination to
handle the patient information not just securely, but safely too and
also allow a NHIN Direct/Exchange GR to safely 'step up' messages
beatring those headers into XD* land. So even with an SMTP backbone
we should support more sophisticated edge processing and higher levels
of patient record management safety.
Finally, without patientId I really don't see how SMTP->XDR 'step up'
can work w/o IHE changes. A converter would need to reject messages
where it cannot reliably partition content into per-patient groups for
transmission. -Matt
On Jun 10, 9:24 am, "Moehrke, John (GE Healthcare)"
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Matt
mine I congratulate you, but also want to clarify my statement about
'IHE changes'. The final point I wanted to leave you with is that
there is a *tension* in the SMTP->XDR step model around patient id
that in my opinion is irreconcilable without some change either to the
IHE metadata constraints *OR* additional metadata in the SMTP
payload. Either of those remedies could work, which is more practical
is for the standards experts to decide on. Lastly, if SMTP is
selected for backbone, and no (even optional) SMTP header is specified
to better enable XDR step-up, (say in a NHIN Exchange bridge) then
SMTP -> XDR step could still be used, but only in the very narrowest
of cases along the lines of what the IHE team demonstrated in Case 3
where we attached a CDA attachment that carries strong patient id and
no other text in mail message body, etc. In that special case its
pretty safe/reliable to step up even without special SMTP headers. So
there's value there, just not a general solution to bridging any free
ranging SMTP message that comes along into XD*-land.
-Matt