Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » OHF » Bridge PIX feed conflict with PIX Manager and Registry
Bridge PIX feed conflict with PIX Manager and Registry [message #42332] Fri, 28 March 2008 23:05 Go to next message
Jesse Pangburn is currently offline Jesse PangburnFriend
Messages: 166
Registered: July 2009
Senior Member
Hi,
I know we discussed this a bit at Connectathon, but the resolution at the
time was a short term workaround/hack to just do the patient feed to two
different rhios.

To reiterate, here is the example of the problem. Suppose I use the IBM
registry and the Initiate PIX Manager. In the PIX manager settings
section of the rhioConfig.xml I have something like this:
<pixProperties>
<id>PAT_IDENTITY_X_REF_MGR_INITIATE_PROPERTIES</id>
<application>PAT_IDENTITY_X_REF_MGR_INITIATE</application>
<facility>INITIATE</facility>
<assigningAuthorityNamespaceId>INP2</assigningAuthorityNamespaceId >
<assigningAuthorityUniversalId>1.3.6.1.4.1.21367.2005.1.1</assigningAuthorityUniversalId >
<assigningAuthorityUniversalIdType>ISO</assigningAuthorityUniversalIdType >
</pixProperties>

So the bridge then uses this application/facility combo in the HL7v2 PIX
feed message to the PIX manager and it works fine. Then it uses the same
application/facility combo and sends to to the registry's PIX feed port
(I'm using IBM's to test with), however the registry returns an error
because it doesn't like the application/facility values. It wants
settings like this:
<facility>XDSDEMO</facility>
<application>XDSDEMO_ADT</application>

In order to make this work, you need two RHIOs. One RHIO is has the IBM
registry setup as a phony PIX manager so the PIX feed intended for the PIX
Manager goes to the registry instead, but has the right
application/facility values. The second RHIO has the real PIX manager you
want to use setup and the registry listed with no PIX feed urls. So when
you want to create a patient, you first send the create to RHIO #1 and
populate the registry, then you send to RHIO #2 and populate the PIX
manager. Then you can continue using RHIO #2 to do PIX/PDQ queries and
XDS actions.

This is obviously not a good long term solution. What we need (I think)
is a PIXServerPropertiesID element in the registry's pixFeedUrl element
(or whatever configuration mechanism), so that we can send different
application/facility values to the registry and PIX manager in the same
PIX feed action.

Now, it may be that this only matters for testing and demos because in a
production environment where you control the registry and the pix manager,
you can probably configure them to accept the same values. But for
testing and demos, which we all know are important to drive sales, you may
be pointing to public servers like IBM's registry and Initiate's PIX
manager- specifically for the point of saying "look, IHE is so cool
because it allows our software to work seamlessly with servers from
different vendors!!11!".

Please let me know if I'm being clueless here (no tact required :-) or if
others feel this is a problem too?

thanks,
Jesse
Re: Bridge PIX feed conflict with PIX Manager and Registry [message #42360 is a reply to message #42332] Sun, 30 March 2008 06:26 Go to previous messageGo to next message
Matthew DavisFriend
Messages: 269
Registered: July 2009
Senior Member
Hi Jesse,

You're spot on here. I was actually thinking about this other day while
reviewing some things (don't recall the discussion @ Connectathon, it
might've been with Sondra or Sarah). But you definitely need to have
available and use properties specific to a registry when doing a PIX feed.

However, there's some question about whether the operation should even
function like it does (pix feeding to both). Generally speaking, the ID
you're feeding to a PIX manager may not be the same ID you're feeding to
a registry.... in fact, it shouldn't be. A PIX Feed from the Bridge
will almost always be a local application registering with a PIX manager
(with a namespace and a domain OID that is unique to your
application/facility) whereas feeds to a registry should be the
patient's CAD ID (with no namespace and the CAD's/registry's domain
OID). Controlling the facility/application/namespace/domain information
is easy within the scope of the the RHIO configuration, but controlling
the actual ID number (in front of the ^^^) kind of makes it difficult to
send both at the same time...... unless you workflow it further:
1. PIX Feed to the PIX Manager with local IDs
2. PIX Query against the PIX Manager, restricting on the CAD's
domain to get the CAD ID for the patient
3. PIX Feed to the XDS Registry with CAD ID

And, at the same time, there's an argument that the Bridge should NEVER
feed a registry's patient ID... it should come solely from the PIX
manager. I'm not going to get into RHIO / Affinity Domain creation
policies ( i'll leave that to the experts ;) ) but it's something to
consider as well.

This is definitely something to discuss further... Sarah, Sondra...
thoughts?



Jesse Pangburn wrote:
> Hi,
> I know we discussed this a bit at Connectathon, but the resolution at
> the time was a short term workaround/hack to just do the patient feed to
> two different rhios.
>
> To reiterate, here is the example of the problem. Suppose I use the IBM
> registry and the Initiate PIX Manager. In the PIX manager settings
> section of the rhioConfig.xml I have something like this:
> <pixProperties>
> <id>PAT_IDENTITY_X_REF_MGR_INITIATE_PROPERTIES</id>
> <application>PAT_IDENTITY_X_REF_MGR_INITIATE</application>
> <facility>INITIATE</facility>
> <assigningAuthorityNamespaceId>INP2</assigningAuthorityNamespaceId >
>
> <assigningAuthorityUniversalId>1.3.6.1.4.1.21367.2005.1.1</assigningAuthorityUniversalId >
>
>
> <assigningAuthorityUniversalIdType>ISO</assigningAuthorityUniversalIdType >
> </pixProperties>
>
> So the bridge then uses this application/facility combo in the HL7v2 PIX
> feed message to the PIX manager and it works fine. Then it uses the
> same application/facility combo and sends to to the registry's PIX feed
> port (I'm using IBM's to test with), however the registry returns an
> error because it doesn't like the application/facility values. It wants
> settings like this:
> <facility>XDSDEMO</facility>
> <application>XDSDEMO_ADT</application>
>
> In order to make this work, you need two RHIOs. One RHIO is has the IBM
> registry setup as a phony PIX manager so the PIX feed intended for the
> PIX Manager goes to the registry instead, but has the right
> application/facility values. The second RHIO has the real PIX manager
> you want to use setup and the registry listed with no PIX feed urls. So
> when you want to create a patient, you first send the create to RHIO #1
> and populate the registry, then you send to RHIO #2 and populate the PIX
> manager. Then you can continue using RHIO #2 to do PIX/PDQ queries and
> XDS actions.
>
> This is obviously not a good long term solution. What we need (I think)
> is a PIXServerPropertiesID element in the registry's pixFeedUrl element
> (or whatever configuration mechanism), so that we can send different
> application/facility values to the registry and PIX manager in the same
> PIX feed action.
>
> Now, it may be that this only matters for testing and demos because in a
> production environment where you control the registry and the pix
> manager, you can probably configure them to accept the same values. But
> for testing and demos, which we all know are important to drive sales,
> you may be pointing to public servers like IBM's registry and Initiate's
> PIX manager- specifically for the point of saying "look, IHE is so cool
> because it allows our software to work seamlessly with servers from
> different vendors!!11!".
>
> Please let me know if I'm being clueless here (no tact required :-) or
> if others feel this is a problem too?
>
> thanks,
> Jesse
>
Re: Bridge PIX feed conflict with PIX Manager and Registry [message #42402 is a reply to message #42360] Mon, 31 March 2008 22:56 Go to previous messageGo to next message
Sondra Renly is currently offline Sondra RenlyFriend
Messages: 39
Registered: July 2009
Member
Hi All,

As Matt described there are two pix feeds - one to the pix manager and
one to the XDS registry. The pix feed to the pix manager contains your
local ID while the pix feed to the XDS registry contains the affinity
domain ID.

We did not take this into account in the original Bridge design. This is
a bug.

Sondra


Matthew Davis wrote:
> Hi Jesse,
>
> You're spot on here. I was actually thinking about this other day while
> reviewing some things (don't recall the discussion @ Connectathon, it
> might've been with Sondra or Sarah). But you definitely need to have
> available and use properties specific to a registry when doing a PIX feed.
>
> However, there's some question about whether the operation should even
> function like it does (pix feeding to both). Generally speaking, the ID
> you're feeding to a PIX manager may not be the same ID you're feeding to
> a registry.... in fact, it shouldn't be. A PIX Feed from the Bridge
> will almost always be a local application registering with a PIX manager
> (with a namespace and a domain OID that is unique to your
> application/facility) whereas feeds to a registry should be the
> patient's CAD ID (with no namespace and the CAD's/registry's domain
> OID). Controlling the facility/application/namespace/domain information
> is easy within the scope of the the RHIO configuration, but controlling
> the actual ID number (in front of the ^^^) kind of makes it difficult to
> send both at the same time...... unless you workflow it further:
> 1. PIX Feed to the PIX Manager with local IDs
> 2. PIX Query against the PIX Manager, restricting on the CAD's
> domain to get the CAD ID for the patient
> 3. PIX Feed to the XDS Registry with CAD ID
>
> And, at the same time, there's an argument that the Bridge should NEVER
> feed a registry's patient ID... it should come solely from the PIX
> manager. I'm not going to get into RHIO / Affinity Domain creation
> policies ( i'll leave that to the experts ;) ) but it's something to
> consider as well.
>
> This is definitely something to discuss further... Sarah, Sondra...
> thoughts?
>
>
>
> Jesse Pangburn wrote:
>> Hi,
>> I know we discussed this a bit at Connectathon, but the resolution at
>> the time was a short term workaround/hack to just do the patient feed
>> to two different rhios.
>>
>> To reiterate, here is the example of the problem. Suppose I use the
>> IBM registry and the Initiate PIX Manager. In the PIX manager
>> settings section of the rhioConfig.xml I have something like this:
>> <pixProperties>
>> <id>PAT_IDENTITY_X_REF_MGR_INITIATE_PROPERTIES</id>
>> <application>PAT_IDENTITY_X_REF_MGR_INITIATE</application>
>> <facility>INITIATE</facility>
>>
>> <assigningAuthorityNamespaceId>INP2</assigningAuthorityNamespaceId >
>>
>> <assigningAuthorityUniversalId>1.3.6.1.4.1.21367.2005.1.1</assigningAuthorityUniversalId >
>>
>>
>> <assigningAuthorityUniversalIdType>ISO</assigningAuthorityUniversalIdType >
>>
>> </pixProperties>
>>
>> So the bridge then uses this application/facility combo in the HL7v2
>> PIX feed message to the PIX manager and it works fine. Then it uses
>> the same application/facility combo and sends to to the registry's PIX
>> feed port (I'm using IBM's to test with), however the registry returns
>> an error because it doesn't like the application/facility values. It
>> wants settings like this:
>> <facility>XDSDEMO</facility>
>> <application>XDSDEMO_ADT</application>
>>
>> In order to make this work, you need two RHIOs. One RHIO is has the
>> IBM registry setup as a phony PIX manager so the PIX feed intended for
>> the PIX Manager goes to the registry instead, but has the right
>> application/facility values. The second RHIO has the real PIX manager
>> you want to use setup and the registry listed with no PIX feed urls.
>> So when you want to create a patient, you first send the create to
>> RHIO #1 and populate the registry, then you send to RHIO #2 and
>> populate the PIX manager. Then you can continue using RHIO #2 to do
>> PIX/PDQ queries and XDS actions.
>>
>> This is obviously not a good long term solution. What we need (I
>> think) is a PIXServerPropertiesID element in the registry's pixFeedUrl
>> element (or whatever configuration mechanism), so that we can send
>> different application/facility values to the registry and PIX manager
>> in the same PIX feed action.
>>
>> Now, it may be that this only matters for testing and demos because in
>> a production environment where you control the registry and the pix
>> manager, you can probably configure them to accept the same values.
>> But for testing and demos, which we all know are important to drive
>> sales, you may be pointing to public servers like IBM's registry and
>> Initiate's PIX manager- specifically for the point of saying "look,
>> IHE is so cool because it allows our software to work seamlessly with
>> servers from different vendors!!11!".
>>
>> Please let me know if I'm being clueless here (no tact required :-) or
>> if others feel this is a problem too?
>>
>> thanks,
>> Jesse
>>
>
Re: Bridge PIX feed conflict with PIX Manager and Registry [message #42427 is a reply to message #42402] Tue, 01 April 2008 09:18 Go to previous messageGo to next message
Matthew DavisFriend
Messages: 269
Registered: July 2009
Senior Member
Hi Sondra,

This is a bug, I agree... but the design needs to be considered further.
And Jesse's observation about adding a PIX property setting for the
registry MLLP receiver is valid as well. I'm just unsure if the Bridge
should *EVER* feed the registry - we can't necessarily stop it, but we
can avoid encouraging it as its designed currently.

There's also a consideration of workflowing it, although the number of
moving parts involved in a process like that makes me uneasy.

-Matt



Sondra Renly wrote:
> Hi All,
>
> As Matt described there are two pix feeds - one to the pix manager and
> one to the XDS registry. The pix feed to the pix manager contains your
> local ID while the pix feed to the XDS registry contains the affinity
> domain ID.
>
> We did not take this into account in the original Bridge design. This is
> a bug.
>
> Sondra
>
>
> Matthew Davis wrote:
>> Hi Jesse,
>>
>> You're spot on here. I was actually thinking about this other day while
>> reviewing some things (don't recall the discussion @ Connectathon, it
>> might've been with Sondra or Sarah). But you definitely need to have
>> available and use properties specific to a registry when doing a PIX
>> feed.
>>
>> However, there's some question about whether the operation should even
>> function like it does (pix feeding to both). Generally speaking, the ID
>> you're feeding to a PIX manager may not be the same ID you're feeding to
>> a registry.... in fact, it shouldn't be. A PIX Feed from the Bridge
>> will almost always be a local application registering with a PIX manager
>> (with a namespace and a domain OID that is unique to your
>> application/facility) whereas feeds to a registry should be the
>> patient's CAD ID (with no namespace and the CAD's/registry's domain
>> OID). Controlling the facility/application/namespace/domain information
>> is easy within the scope of the the RHIO configuration, but controlling
>> the actual ID number (in front of the ^^^) kind of makes it difficult to
>> send both at the same time...... unless you workflow it further:
>> 1. PIX Feed to the PIX Manager with local IDs
>> 2. PIX Query against the PIX Manager, restricting on the CAD's
>> domain to get the CAD ID for the patient
>> 3. PIX Feed to the XDS Registry with CAD ID
>>
>> And, at the same time, there's an argument that the Bridge should NEVER
>> feed a registry's patient ID... it should come solely from the PIX
>> manager. I'm not going to get into RHIO / Affinity Domain creation
>> policies ( i'll leave that to the experts ;) ) but it's something to
>> consider as well.
>>
>> This is definitely something to discuss further... Sarah, Sondra...
>> thoughts?
>>
>>
>>
>> Jesse Pangburn wrote:
>>> Hi,
>>> I know we discussed this a bit at Connectathon, but the resolution at
>>> the time was a short term workaround/hack to just do the patient feed
>>> to two different rhios.
>>>
>>> To reiterate, here is the example of the problem. Suppose I use the
>>> IBM registry and the Initiate PIX Manager. In the PIX manager
>>> settings section of the rhioConfig.xml I have something like this:
>>> <pixProperties>
>>> <id>PAT_IDENTITY_X_REF_MGR_INITIATE_PROPERTIES</id>
>>> <application>PAT_IDENTITY_X_REF_MGR_INITIATE</application>
>>> <facility>INITIATE</facility>
>>>
>>> <assigningAuthorityNamespaceId>INP2</assigningAuthorityNamespaceId >
>>>
>>> <assigningAuthorityUniversalId>1.3.6.1.4.1.21367.2005.1.1</assigningAuthorityUniversalId >
>>>
>>>
>>> <assigningAuthorityUniversalIdType>ISO</assigningAuthorityUniversalIdType >
>>>
>>> </pixProperties>
>>>
>>> So the bridge then uses this application/facility combo in the HL7v2
>>> PIX feed message to the PIX manager and it works fine. Then it uses
>>> the same application/facility combo and sends to to the registry's
>>> PIX feed port (I'm using IBM's to test with), however the registry
>>> returns an error because it doesn't like the application/facility
>>> values. It wants settings like this:
>>> <facility>XDSDEMO</facility>
>>> <application>XDSDEMO_ADT</application>
>>>
>>> In order to make this work, you need two RHIOs. One RHIO is has the
>>> IBM registry setup as a phony PIX manager so the PIX feed intended
>>> for the PIX Manager goes to the registry instead, but has the right
>>> application/facility values. The second RHIO has the real PIX
>>> manager you want to use setup and the registry listed with no PIX
>>> feed urls. So when you want to create a patient, you first send the
>>> create to RHIO #1 and populate the registry, then you send to RHIO #2
>>> and populate the PIX manager. Then you can continue using RHIO #2 to
>>> do PIX/PDQ queries and XDS actions.
>>>
>>> This is obviously not a good long term solution. What we need (I
>>> think) is a PIXServerPropertiesID element in the registry's
>>> pixFeedUrl element (or whatever configuration mechanism), so that we
>>> can send different application/facility values to the registry and
>>> PIX manager in the same PIX feed action.
>>>
>>> Now, it may be that this only matters for testing and demos because
>>> in a production environment where you control the registry and the
>>> pix manager, you can probably configure them to accept the same
>>> values. But for testing and demos, which we all know are important
>>> to drive sales, you may be pointing to public servers like IBM's
>>> registry and Initiate's PIX manager- specifically for the point of
>>> saying "look, IHE is so cool because it allows our software to work
>>> seamlessly with servers from different vendors!!11!".
>>>
>>> Please let me know if I'm being clueless here (no tact required :-)
>>> or if others feel this is a problem too?
>>>
>>> thanks,
>>> Jesse
>>>
>>
>
Re: Bridge PIX feed conflict with PIX Manager and Registry [message #42459 is a reply to message #42427] Tue, 01 April 2008 21:01 Go to previous messageGo to next message
Jesse Pangburn is currently offline Jesse PangburnFriend
Messages: 166
Registered: July 2009
Senior Member
Hi,
In the real scenarios that I'm considering, the PIX manager will be doing
the feeding of IDs to the Registry- it seems to be the best way so that's
what I'm recommending to people. It is a good question of whether the
bridge should be doing the PIX feed to the Registry or not in some cases,
but ultimately what's going to happen if IHE doesn't specify it one way or
the other is that customers are going to want to have it done different
ways. Some may say "well my PIX manager is on a different network than
the Registry so the PIX manager can't be expected to feed it, I want your
client system to do it." This is at least the case with demos for anyone
using a PIX manager from one company and a Registry from another.

As IHE allows both scenarios, any reason the bridge shouldn't support
both? I agree it's good to encourage people to go for the best path, but
sometimes you have to work within constraints not of your choosing. In
that case, developers using the bridge will be forced to create their own
hacks- like sending the PIX feed to a middle man server that will forward
it to the PIX Manager and forward a modified copy (with different
destination app/facility) to the Registry.

thanks,
Jesse

Matthew Davis wrote:

> Hi Sondra,

> This is a bug, I agree... but the design needs to be considered further.
> And Jesse's observation about adding a PIX property setting for the
> registry MLLP receiver is valid as well. I'm just unsure if the Bridge
> should *EVER* feed the registry - we can't necessarily stop it, but we
> can avoid encouraging it as its designed currently.

> There's also a consideration of workflowing it, although the number of
> moving parts involved in a process like that makes me uneasy.

> -Matt



> Sondra Renly wrote:
>> Hi All,
>>
>> As Matt described there are two pix feeds - one to the pix manager and
>> one to the XDS registry. The pix feed to the pix manager contains your
>> local ID while the pix feed to the XDS registry contains the affinity
>> domain ID.
>>
>> We did not take this into account in the original Bridge design. This is
>> a bug.
>>
>> Sondra
>>
>>
>> Matthew Davis wrote:
>>> Hi Jesse,
>>>
>>> You're spot on here. I was actually thinking about this other day while
>>> reviewing some things (don't recall the discussion @ Connectathon, it
>>> might've been with Sondra or Sarah). But you definitely need to have
>>> available and use properties specific to a registry when doing a PIX
>>> feed.
>>>
>>> However, there's some question about whether the operation should even
>>> function like it does (pix feeding to both). Generally speaking, the ID
>>> you're feeding to a PIX manager may not be the same ID you're feeding to
>>> a registry.... in fact, it shouldn't be. A PIX Feed from the Bridge
>>> will almost always be a local application registering with a PIX manager
>>> (with a namespace and a domain OID that is unique to your
>>> application/facility) whereas feeds to a registry should be the
>>> patient's CAD ID (with no namespace and the CAD's/registry's domain
>>> OID). Controlling the facility/application/namespace/domain information
>>> is easy within the scope of the the RHIO configuration, but controlling
>>> the actual ID number (in front of the ^^^) kind of makes it difficult to
>>> send both at the same time...... unless you workflow it further:
>>> 1. PIX Feed to the PIX Manager with local IDs
>>> 2. PIX Query against the PIX Manager, restricting on the CAD's
>>> domain to get the CAD ID for the patient
>>> 3. PIX Feed to the XDS Registry with CAD ID
>>>
>>> And, at the same time, there's an argument that the Bridge should NEVER
>>> feed a registry's patient ID... it should come solely from the PIX
>>> manager. I'm not going to get into RHIO / Affinity Domain creation
>>> policies ( i'll leave that to the experts ;) ) but it's something to
>>> consider as well.
>>>
>>> This is definitely something to discuss further... Sarah, Sondra...
>>> thoughts?
>>>
>>>
>>>
>>> Jesse Pangburn wrote:
>>>> Hi,
>>>> I know we discussed this a bit at Connectathon, but the resolution at
>>>> the time was a short term workaround/hack to just do the patient feed
>>>> to two different rhios.
>>>>
>>>> To reiterate, here is the example of the problem. Suppose I use the
>>>> IBM registry and the Initiate PIX Manager. In the PIX manager
>>>> settings section of the rhioConfig.xml I have something like this:
>>>> <pixProperties>
>>>> <id>PAT_IDENTITY_X_REF_MGR_INITIATE_PROPERTIES</id>
>>>> <application>PAT_IDENTITY_X_REF_MGR_INITIATE</application>
>>>> <facility>INITIATE</facility>
>>>>
>>>> <assigningAuthorityNamespaceId>INP2</assigningAuthorityNamespaceId >
>>>>
>>>>
<assigningAuthorityUniversalId>1.3.6.1.4.1.21367.2005.1.1</assigningAuthorityUniversalId >
>>>>
>>>>
>>>>
<assigningAuthorityUniversalIdType>ISO</assigningAuthorityUniversalIdType >
>>>>
>>>> </pixProperties>
>>>>
>>>> So the bridge then uses this application/facility combo in the HL7v2
>>>> PIX feed message to the PIX manager and it works fine. Then it uses
>>>> the same application/facility combo and sends to to the registry's
>>>> PIX feed port (I'm using IBM's to test with), however the registry
>>>> returns an error because it doesn't like the application/facility
>>>> values. It wants settings like this:
>>>> <facility>XDSDEMO</facility>
>>>> <application>XDSDEMO_ADT</application>
>>>>
>>>> In order to make this work, you need two RHIOs. One RHIO is has the
>>>> IBM registry setup as a phony PIX manager so the PIX feed intended
>>>> for the PIX Manager goes to the registry instead, but has the right
>>>> application/facility values. The second RHIO has the real PIX
>>>> manager you want to use setup and the registry listed with no PIX
>>>> feed urls. So when you want to create a patient, you first send the
>>>> create to RHIO #1 and populate the registry, then you send to RHIO #2
>>>> and populate the PIX manager. Then you can continue using RHIO #2 to
>>>> do PIX/PDQ queries and XDS actions.
>>>>
>>>> This is obviously not a good long term solution. What we need (I
>>>> think) is a PIXServerPropertiesID element in the registry's
>>>> pixFeedUrl element (or whatever configuration mechanism), so that we
>>>> can send different application/facility values to the registry and
>>>> PIX manager in the same PIX feed action.
>>>>
>>>> Now, it may be that this only matters for testing and demos because
>>>> in a production environment where you control the registry and the
>>>> pix manager, you can probably configure them to accept the same
>>>> values. But for testing and demos, which we all know are important
>>>> to drive sales, you may be pointing to public servers like IBM's
>>>> registry and Initiate's PIX manager- specifically for the point of
>>>> saying "look, IHE is so cool because it allows our software to work
>>>> seamlessly with servers from different vendors!!11!".
>>>>
>>>> Please let me know if I'm being clueless here (no tact required :-)
>>>> or if others feel this is a problem too?
>>>>
>>>> thanks,
>>>> Jesse
>>>>
>>>
>>
Re: Bridge PIX feed conflict with PIX Manager and Registry [message #42660 is a reply to message #42459] Thu, 03 April 2008 15:36 Go to previous messageGo to next message
No real name is currently offline No real nameFriend
Messages: 292
Registered: July 2009
Senior Member
You know me .. I can't resist adding my 2 cents -

XDS, unfortunately, is a bit mumms the word on the Patient Identity
Source for the XDS Registry. Re-reading this today - the profile asserts
the registry will recognize only one assigning authority domain, it does
not explicitly state there should be a single source actor for the
registry. IMHO - this should be singular (ie. grouped with a PIX
manager) rather than all edge systems dual feeding the registry - much
more practical. But, IHE allows for all sorts of topologies, thus OHF
should allow for these other options.

Now - I agree with matt, we should be careful as to how we design this
thing. The singluar item here is the assigning authority domain that the
registry and PIX working with this registry should share. Will take some
more thought, but point taken.

- Sarah ;-)


Jesse Pangburn wrote:
> Hi,
> In the real scenarios that I'm considering, the PIX manager will be
> doing the feeding of IDs to the Registry- it seems to be the best way so
> that's what I'm recommending to people. It is a good question of
> whether the bridge should be doing the PIX feed to the Registry or not
> in some cases, but ultimately what's going to happen if IHE doesn't
> specify it one way or the other is that customers are going to want to
> have it done different ways. Some may say "well my PIX manager is on a
> different network than the Registry so the PIX manager can't be expected
> to feed it, I want your client system to do it." This is at least the
> case with demos for anyone using a PIX manager from one company and a
> Registry from another.
>
> As IHE allows both scenarios, any reason the bridge shouldn't support
> both? I agree it's good to encourage people to go for the best path,
> but sometimes you have to work within constraints not of your choosing.
> In that case, developers using the bridge will be forced to create their
> own hacks- like sending the PIX feed to a middle man server that will
> forward it to the PIX Manager and forward a modified copy (with
> different destination app/facility) to the Registry.
>
> thanks,
> Jesse
>
> Matthew Davis wrote:
>
>> Hi Sondra,
>
>
>> This is a bug, I agree... but the design needs to be considered
>> further. And Jesse's observation about adding a PIX property setting
>> for the registry MLLP receiver is valid as well. I'm just unsure if
>> the Bridge should *EVER* feed the registry - we can't necessarily stop
>> it, but we can avoid encouraging it as its designed currently.
>
>
>> There's also a consideration of workflowing it, although the number of
>> moving parts involved in a process like that makes me uneasy.
>
>
>> -Matt
>
>
>
>
>> Sondra Renly wrote:
>>
>>> Hi All,
>>>
>>> As Matt described there are two pix feeds - one to the pix manager
>>> and one to the XDS registry. The pix feed to the pix manager contains
>>> your local ID while the pix feed to the XDS registry contains the
>>> affinity domain ID.
>>>
>>> We did not take this into account in the original Bridge design. This
>>> is a bug.
>>>
>>> Sondra
>>>
>>>
>>> Matthew Davis wrote:
>>>
>>>> Hi Jesse,
>>>>
>>>> You're spot on here. I was actually thinking about this other day
>>>> while
>>>> reviewing some things (don't recall the discussion @ Connectathon, it
>>>> might've been with Sondra or Sarah). But you definitely need to have
>>>> available and use properties specific to a registry when doing a PIX
>>>> feed.
>>>>
>>>> However, there's some question about whether the operation should even
>>>> function like it does (pix feeding to both). Generally speaking,
>>>> the ID
>>>> you're feeding to a PIX manager may not be the same ID you're
>>>> feeding to
>>>> a registry.... in fact, it shouldn't be. A PIX Feed from the Bridge
>>>> will almost always be a local application registering with a PIX
>>>> manager
>>>> (with a namespace and a domain OID that is unique to your
>>>> application/facility) whereas feeds to a registry should be the
>>>> patient's CAD ID (with no namespace and the CAD's/registry's domain
>>>> OID). Controlling the facility/application/namespace/domain
>>>> information
>>>> is easy within the scope of the the RHIO configuration, but controlling
>>>> the actual ID number (in front of the ^^^) kind of makes it
>>>> difficult to
>>>> send both at the same time...... unless you workflow it further:
>>>> 1. PIX Feed to the PIX Manager with local IDs
>>>> 2. PIX Query against the PIX Manager, restricting on the CAD's
>>>> domain to get the CAD ID for the patient
>>>> 3. PIX Feed to the XDS Registry with CAD ID
>>>>
>>>> And, at the same time, there's an argument that the Bridge should NEVER
>>>> feed a registry's patient ID... it should come solely from the PIX
>>>> manager. I'm not going to get into RHIO / Affinity Domain creation
>>>> policies ( i'll leave that to the experts ;) ) but it's something to
>>>> consider as well.
>>>>
>>>> This is definitely something to discuss further... Sarah, Sondra...
>>>> thoughts?
>>>>
>>>>
>>>>
>>>> Jesse Pangburn wrote:
>>>>
>>>>> Hi,
>>>>> I know we discussed this a bit at Connectathon, but the resolution
>>>>> at the time was a short term workaround/hack to just do the patient
>>>>> feed to two different rhios.
>>>>>
>>>>> To reiterate, here is the example of the problem. Suppose I use
>>>>> the IBM registry and the Initiate PIX Manager. In the PIX manager
>>>>> settings section of the rhioConfig.xml I have something like this:
>>>>> <pixProperties>
>>>>> <id>PAT_IDENTITY_X_REF_MGR_INITIATE_PROPERTIES</id>
>>>>> <application>PAT_IDENTITY_X_REF_MGR_INITIATE</application>
>>>>> <facility>INITIATE</facility>
>>>>>
>>>>> <assigningAuthorityNamespaceId>INP2</assigningAuthorityNamespaceId >
>>>>>
>
> <assigningAuthorityUniversalId>1.3.6.1.4.1.21367.2005.1.1</assigningAuthorityUniversalId >
>
>
>>>>>
>>>>>
>
> <assigningAuthorityUniversalIdType>ISO</assigningAuthorityUniversalIdType >
>
>>>>>
>>>>> </pixProperties>
>>>>>
>>>>> So the bridge then uses this application/facility combo in the
>>>>> HL7v2 PIX feed message to the PIX manager and it works fine. Then
>>>>> it uses the same application/facility combo and sends to to the
>>>>> registry's PIX feed port (I'm using IBM's to test with), however
>>>>> the registry returns an error because it doesn't like the
>>>>> application/facility values. It wants settings like this:
>>>>> <facility>XDSDEMO</facility>
>>>>> <application>XDSDEMO_ADT</application>
>>>>>
>>>>> In order to make this work, you need two RHIOs. One RHIO is has
>>>>> the IBM registry setup as a phony PIX manager so the PIX feed
>>>>> intended for the PIX Manager goes to the registry instead, but has
>>>>> the right application/facility values. The second RHIO has the
>>>>> real PIX manager you want to use setup and the registry listed with
>>>>> no PIX feed urls. So when you want to create a patient, you first
>>>>> send the create to RHIO #1 and populate the registry, then you send
>>>>> to RHIO #2 and populate the PIX manager. Then you can continue
>>>>> using RHIO #2 to do PIX/PDQ queries and XDS actions.
>>>>>
>>>>> This is obviously not a good long term solution. What we need (I
>>>>> think) is a PIXServerPropertiesID element in the registry's
>>>>> pixFeedUrl element (or whatever configuration mechanism), so that
>>>>> we can send different application/facility values to the registry
>>>>> and PIX manager in the same PIX feed action.
>>>>>
>>>>> Now, it may be that this only matters for testing and demos because
>>>>> in a production environment where you control the registry and the
>>>>> pix manager, you can probably configure them to accept the same
>>>>> values. But for testing and demos, which we all know are important
>>>>> to drive sales, you may be pointing to public servers like IBM's
>>>>> registry and Initiate's PIX manager- specifically for the point of
>>>>> saying "look, IHE is so cool because it allows our software to work
>>>>> seamlessly with servers from different vendors!!11!".
>>>>>
>>>>> Please let me know if I'm being clueless here (no tact required :-)
>>>>> or if others feel this is a problem too?
>>>>>
>>>>> thanks,
>>>>> Jesse
>>>>>
>>>>
>>>
>
>
Re: Bridge PIX feed conflict with PIX Manager and Registry [message #42786 is a reply to message #42660] Thu, 03 April 2008 17:19 Go to previous message
Jesse Pangburn is currently offline Jesse PangburnFriend
Messages: 166
Registered: July 2009
Senior Member
Right, I think we're all agreed that we believe the best topology in a
prod environment is the PIX Manager being the only system allowed to feed
the registry. We're also agreed that IHE is not specific on this matter
and that a scenario where the client feeds the PIX Manager and Registry is
perfectly IHE compliant.

I think that in order to feed the PIX Manager and the Registry, you can
really only have one client because that client HAS to be the assigning
authority for the domain- otherwise you cannot feed the Registry too.
It's kinda silly to allow this because you really can't have multiple
client systems in this environment unless you rig it by having different
clients use a fixed prefix on the IDs (a poor man's namespace). And then
you get multiple IDs in the same namespace that belong to the same
patient, so that doesn't really work either. It's really a worthless
setup, only good for Connectathon and demos really. Since there's no way
to send different IDs to the two places and have it make any kind of
sense, it seems to me that the only thing you need is to be able to send a
different destination application and facility. There's no way any one is
going to use it in production, what good would it be to have an IHE system
with just one client?

Jesse :-)

Sarah Knoop wrote:

> You know me .. I can't resist adding my 2 cents -

> XDS, unfortunately, is a bit mumms the word on the Patient Identity
> Source for the XDS Registry. Re-reading this today - the profile asserts
> the registry will recognize only one assigning authority domain, it does
> not explicitly state there should be a single source actor for the
> registry. IMHO - this should be singular (ie. grouped with a PIX
> manager) rather than all edge systems dual feeding the registry - much
> more practical. But, IHE allows for all sorts of topologies, thus OHF
> should allow for these other options.

> Now - I agree with matt, we should be careful as to how we design this
> thing. The singluar item here is the assigning authority domain that the
> registry and PIX working with this registry should share. Will take some
> more thought, but point taken.

> - Sarah ;-)


> Jesse Pangburn wrote:
>> Hi,
>> In the real scenarios that I'm considering, the PIX manager will be
>> doing the feeding of IDs to the Registry- it seems to be the best way so
>> that's what I'm recommending to people. It is a good question of
>> whether the bridge should be doing the PIX feed to the Registry or not
>> in some cases, but ultimately what's going to happen if IHE doesn't
>> specify it one way or the other is that customers are going to want to
>> have it done different ways. Some may say "well my PIX manager is on a
>> different network than the Registry so the PIX manager can't be expected
>> to feed it, I want your client system to do it." This is at least the
>> case with demos for anyone using a PIX manager from one company and a
>> Registry from another.
>>
>> As IHE allows both scenarios, any reason the bridge shouldn't support
>> both? I agree it's good to encourage people to go for the best path,
>> but sometimes you have to work within constraints not of your choosing.
>> In that case, developers using the bridge will be forced to create their
>> own hacks- like sending the PIX feed to a middle man server that will
>> forward it to the PIX Manager and forward a modified copy (with
>> different destination app/facility) to the Registry.
>>
>> thanks,
>> Jesse
>>
>> Matthew Davis wrote:
>>
>>> Hi Sondra,
>>
>>
>>> This is a bug, I agree... but the design needs to be considered
>>> further. And Jesse's observation about adding a PIX property setting
>>> for the registry MLLP receiver is valid as well. I'm just unsure if
>>> the Bridge should *EVER* feed the registry - we can't necessarily stop
>>> it, but we can avoid encouraging it as its designed currently.
>>
>>
>>> There's also a consideration of workflowing it, although the number of
>>> moving parts involved in a process like that makes me uneasy.
>>
>>
>>> -Matt
>>
>>
>>
>>
>>> Sondra Renly wrote:
>>>
>>>> Hi All,
>>>>
>>>> As Matt described there are two pix feeds - one to the pix manager
>>>> and one to the XDS registry. The pix feed to the pix manager contains
>>>> your local ID while the pix feed to the XDS registry contains the
>>>> affinity domain ID.
>>>>
>>>> We did not take this into account in the original Bridge design. This
>>>> is a bug.
>>>>
>>>> Sondra
>>>>
>>>>
>>>> Matthew Davis wrote:
>>>>
>>>>> Hi Jesse,
>>>>>
>>>>> You're spot on here. I was actually thinking about this other day
>>>>> while
>>>>> reviewing some things (don't recall the discussion @ Connectathon, it
>>>>> might've been with Sondra or Sarah). But you definitely need to have
>>>>> available and use properties specific to a registry when doing a PIX
>>>>> feed.
>>>>>
>>>>> However, there's some question about whether the operation should even
>>>>> function like it does (pix feeding to both). Generally speaking,
>>>>> the ID
>>>>> you're feeding to a PIX manager may not be the same ID you're
>>>>> feeding to
>>>>> a registry.... in fact, it shouldn't be. A PIX Feed from the Bridge
>>>>> will almost always be a local application registering with a PIX
>>>>> manager
>>>>> (with a namespace and a domain OID that is unique to your
>>>>> application/facility) whereas feeds to a registry should be the
>>>>> patient's CAD ID (with no namespace and the CAD's/registry's domain
>>>>> OID). Controlling the facility/application/namespace/domain
>>>>> information
>>>>> is easy within the scope of the the RHIO configuration, but controlling
>>>>> the actual ID number (in front of the ^^^) kind of makes it
>>>>> difficult to
>>>>> send both at the same time...... unless you workflow it further:
>>>>> 1. PIX Feed to the PIX Manager with local IDs
>>>>> 2. PIX Query against the PIX Manager, restricting on the CAD's
>>>>> domain to get the CAD ID for the patient
>>>>> 3. PIX Feed to the XDS Registry with CAD ID
>>>>>
>>>>> And, at the same time, there's an argument that the Bridge should NEVER
>>>>> feed a registry's patient ID... it should come solely from the PIX
>>>>> manager. I'm not going to get into RHIO / Affinity Domain creation
>>>>> policies ( i'll leave that to the experts ;) ) but it's something to
>>>>> consider as well.
>>>>>
>>>>> This is definitely something to discuss further... Sarah, Sondra...
>>>>> thoughts?
>>>>>
>>>>>
>>>>>
>>>>> Jesse Pangburn wrote:
>>>>>
>>>>>> Hi,
>>>>>> I know we discussed this a bit at Connectathon, but the resolution
>>>>>> at the time was a short term workaround/hack to just do the patient
>>>>>> feed to two different rhios.
>>>>>>
>>>>>> To reiterate, here is the example of the problem. Suppose I use
>>>>>> the IBM registry and the Initiate PIX Manager. In the PIX manager
>>>>>> settings section of the rhioConfig.xml I have something like this:
>>>>>> <pixProperties>
>>>>>> <id>PAT_IDENTITY_X_REF_MGR_INITIATE_PROPERTIES</id>
>>>>>> <application>PAT_IDENTITY_X_REF_MGR_INITIATE</application>
>>>>>> <facility>INITIATE</facility>
>>>>>>
>>>>>> <assigningAuthorityNamespaceId>INP2</assigningAuthorityNamespaceId >
>>>>>>
>>
>>
<assigningAuthorityUniversalId>1.3.6.1.4.1.21367.2005.1.1</assigningAuthorityUniversalId >
>>
>>
>>>>>>
>>>>>>
>>
>> <assigningAuthorityUniversalIdType>ISO</assigningAuthorityUniversalIdType >
>>
>>>>>>
>>>>>> </pixProperties>
>>>>>>
>>>>>> So the bridge then uses this application/facility combo in the
>>>>>> HL7v2 PIX feed message to the PIX manager and it works fine. Then
>>>>>> it uses the same application/facility combo and sends to to the
>>>>>> registry's PIX feed port (I'm using IBM's to test with), however
>>>>>> the registry returns an error because it doesn't like the
>>>>>> application/facility values. It wants settings like this:
>>>>>> <facility>XDSDEMO</facility>
>>>>>> <application>XDSDEMO_ADT</application>
>>>>>>
>>>>>> In order to make this work, you need two RHIOs. One RHIO is has
>>>>>> the IBM registry setup as a phony PIX manager so the PIX feed
>>>>>> intended for the PIX Manager goes to the registry instead, but has
>>>>>> the right application/facility values. The second RHIO has the
>>>>>> real PIX manager you want to use setup and the registry listed with
>>>>>> no PIX feed urls. So when you want to create a patient, you first
>>>>>> send the create to RHIO #1 and populate the registry, then you send
>>>>>> to RHIO #2 and populate the PIX manager. Then you can continue
>>>>>> using RHIO #2 to do PIX/PDQ queries and XDS actions.
>>>>>>
>>>>>> This is obviously not a good long term solution. What we need (I
>>>>>> think) is a PIXServerPropertiesID element in the registry's
>>>>>> pixFeedUrl element (or whatever configuration mechanism), so that
>>>>>> we can send different application/facility values to the registry
>>>>>> and PIX manager in the same PIX feed action.
>>>>>>
>>>>>> Now, it may be that this only matters for testing and demos because
>>>>>> in a production environment where you control the registry and the
>>>>>> pix manager, you can probably configure them to accept the same
>>>>>> values. But for testing and demos, which we all know are important
>>>>>> to drive sales, you may be pointing to public servers like IBM's
>>>>>> registry and Initiate's PIX manager- specifically for the point of
>>>>>> saying "look, IHE is so cool because it allows our software to work
>>>>>> seamlessly with servers from different vendors!!11!".
>>>>>>
>>>>>> Please let me know if I'm being clueless here (no tact required :-)
>>>>>> or if others feel this is a problem too?
>>>>>>
>>>>>> thanks,
>>>>>> Jesse
>>>>>>
>>>>>
>>>>
>>
>>
Re: Bridge PIX feed conflict with PIX Manager and Registry [message #585333 is a reply to message #42332] Sun, 30 March 2008 06:26 Go to previous message
Matthew DavisFriend
Messages: 269
Registered: July 2009
Senior Member
Hi Jesse,

You're spot on here. I was actually thinking about this other day while
reviewing some things (don't recall the discussion @ Connectathon, it
might've been with Sondra or Sarah). But you definitely need to have
available and use properties specific to a registry when doing a PIX feed.

However, there's some question about whether the operation should even
function like it does (pix feeding to both). Generally speaking, the ID
you're feeding to a PIX manager may not be the same ID you're feeding to
a registry.... in fact, it shouldn't be. A PIX Feed from the Bridge
will almost always be a local application registering with a PIX manager
(with a namespace and a domain OID that is unique to your
application/facility) whereas feeds to a registry should be the
patient's CAD ID (with no namespace and the CAD's/registry's domain
OID). Controlling the facility/application/namespace/domain information
is easy within the scope of the the RHIO configuration, but controlling
the actual ID number (in front of the ^^^) kind of makes it difficult to
send both at the same time...... unless you workflow it further:
1. PIX Feed to the PIX Manager with local IDs
2. PIX Query against the PIX Manager, restricting on the CAD's
domain to get the CAD ID for the patient
3. PIX Feed to the XDS Registry with CAD ID

And, at the same time, there's an argument that the Bridge should NEVER
feed a registry's patient ID... it should come solely from the PIX
manager. I'm not going to get into RHIO / Affinity Domain creation
policies ( i'll leave that to the experts ;) ) but it's something to
consider as well.

This is definitely something to discuss further... Sarah, Sondra...
thoughts?



Jesse Pangburn wrote:
> Hi,
> I know we discussed this a bit at Connectathon, but the resolution at
> the time was a short term workaround/hack to just do the patient feed to
> two different rhios.
>
> To reiterate, here is the example of the problem. Suppose I use the IBM
> registry and the Initiate PIX Manager. In the PIX manager settings
> section of the rhioConfig.xml I have something like this:
> <pixProperties>
> <id>PAT_IDENTITY_X_REF_MGR_INITIATE_PROPERTIES</id>
> <application>PAT_IDENTITY_X_REF_MGR_INITIATE</application>
> <facility>INITIATE</facility>
> <assigningAuthorityNamespaceId>INP2</assigningAuthorityNamespaceId >
>
> <assigningAuthorityUniversalId>1.3.6.1.4.1.21367.2005.1.1</assigningAuthorityUniversalId >
>
>
> <assigningAuthorityUniversalIdType>ISO</assigningAuthorityUniversalIdType >
> </pixProperties>
>
> So the bridge then uses this application/facility combo in the HL7v2 PIX
> feed message to the PIX manager and it works fine. Then it uses the
> same application/facility combo and sends to to the registry's PIX feed
> port (I'm using IBM's to test with), however the registry returns an
> error because it doesn't like the application/facility values. It wants
> settings like this:
> <facility>XDSDEMO</facility>
> <application>XDSDEMO_ADT</application>
>
> In order to make this work, you need two RHIOs. One RHIO is has the IBM
> registry setup as a phony PIX manager so the PIX feed intended for the
> PIX Manager goes to the registry instead, but has the right
> application/facility values. The second RHIO has the real PIX manager
> you want to use setup and the registry listed with no PIX feed urls. So
> when you want to create a patient, you first send the create to RHIO #1
> and populate the registry, then you send to RHIO #2 and populate the PIX
> manager. Then you can continue using RHIO #2 to do PIX/PDQ queries and
> XDS actions.
>
> This is obviously not a good long term solution. What we need (I think)
> is a PIXServerPropertiesID element in the registry's pixFeedUrl element
> (or whatever configuration mechanism), so that we can send different
> application/facility values to the registry and PIX manager in the same
> PIX feed action.
>
> Now, it may be that this only matters for testing and demos because in a
> production environment where you control the registry and the pix
> manager, you can probably configure them to accept the same values. But
> for testing and demos, which we all know are important to drive sales,
> you may be pointing to public servers like IBM's registry and Initiate's
> PIX manager- specifically for the point of saying "look, IHE is so cool
> because it allows our software to work seamlessly with servers from
> different vendors!!11!".
>
> Please let me know if I'm being clueless here (no tact required :-) or
> if others feel this is a problem too?
>
> thanks,
> Jesse
>
Re: Bridge PIX feed conflict with PIX Manager and Registry [message #585342 is a reply to message #42360] Mon, 31 March 2008 22:56 Go to previous message
Sondra Renly is currently offline Sondra RenlyFriend
Messages: 39
Registered: July 2009
Member
Hi All,

As Matt described there are two pix feeds - one to the pix manager and
one to the XDS registry. The pix feed to the pix manager contains your
local ID while the pix feed to the XDS registry contains the affinity
domain ID.

We did not take this into account in the original Bridge design. This is
a bug.

Sondra


Matthew Davis wrote:
> Hi Jesse,
>
> You're spot on here. I was actually thinking about this other day while
> reviewing some things (don't recall the discussion @ Connectathon, it
> might've been with Sondra or Sarah). But you definitely need to have
> available and use properties specific to a registry when doing a PIX feed.
>
> However, there's some question about whether the operation should even
> function like it does (pix feeding to both). Generally speaking, the ID
> you're feeding to a PIX manager may not be the same ID you're feeding to
> a registry.... in fact, it shouldn't be. A PIX Feed from the Bridge
> will almost always be a local application registering with a PIX manager
> (with a namespace and a domain OID that is unique to your
> application/facility) whereas feeds to a registry should be the
> patient's CAD ID (with no namespace and the CAD's/registry's domain
> OID). Controlling the facility/application/namespace/domain information
> is easy within the scope of the the RHIO configuration, but controlling
> the actual ID number (in front of the ^^^) kind of makes it difficult to
> send both at the same time...... unless you workflow it further:
> 1. PIX Feed to the PIX Manager with local IDs
> 2. PIX Query against the PIX Manager, restricting on the CAD's
> domain to get the CAD ID for the patient
> 3. PIX Feed to the XDS Registry with CAD ID
>
> And, at the same time, there's an argument that the Bridge should NEVER
> feed a registry's patient ID... it should come solely from the PIX
> manager. I'm not going to get into RHIO / Affinity Domain creation
> policies ( i'll leave that to the experts ;) ) but it's something to
> consider as well.
>
> This is definitely something to discuss further... Sarah, Sondra...
> thoughts?
>
>
>
> Jesse Pangburn wrote:
>> Hi,
>> I know we discussed this a bit at Connectathon, but the resolution at
>> the time was a short term workaround/hack to just do the patient feed
>> to two different rhios.
>>
>> To reiterate, here is the example of the problem. Suppose I use the
>> IBM registry and the Initiate PIX Manager. In the PIX manager
>> settings section of the rhioConfig.xml I have something like this:
>> <pixProperties>
>> <id>PAT_IDENTITY_X_REF_MGR_INITIATE_PROPERTIES</id>
>> <application>PAT_IDENTITY_X_REF_MGR_INITIATE</application>
>> <facility>INITIATE</facility>
>>
>> <assigningAuthorityNamespaceId>INP2</assigningAuthorityNamespaceId >
>>
>> <assigningAuthorityUniversalId>1.3.6.1.4.1.21367.2005.1.1</assigningAuthorityUniversalId >
>>
>>
>> <assigningAuthorityUniversalIdType>ISO</assigningAuthorityUniversalIdType >
>>
>> </pixProperties>
>>
>> So the bridge then uses this application/facility combo in the HL7v2
>> PIX feed message to the PIX manager and it works fine. Then it uses
>> the same application/facility combo and sends to to the registry's PIX
>> feed port (I'm using IBM's to test with), however the registry returns
>> an error because it doesn't like the application/facility values. It
>> wants settings like this:
>> <facility>XDSDEMO</facility>
>> <application>XDSDEMO_ADT</application>
>>
>> In order to make this work, you need two RHIOs. One RHIO is has the
>> IBM registry setup as a phony PIX manager so the PIX feed intended for
>> the PIX Manager goes to the registry instead, but has the right
>> application/facility values. The second RHIO has the real PIX manager
>> you want to use setup and the registry listed with no PIX feed urls.
>> So when you want to create a patient, you first send the create to
>> RHIO #1 and populate the registry, then you send to RHIO #2 and
>> populate the PIX manager. Then you can continue using RHIO #2 to do
>> PIX/PDQ queries and XDS actions.
>>
>> This is obviously not a good long term solution. What we need (I
>> think) is a PIXServerPropertiesID element in the registry's pixFeedUrl
>> element (or whatever configuration mechanism), so that we can send
>> different application/facility values to the registry and PIX manager
>> in the same PIX feed action.
>>
>> Now, it may be that this only matters for testing and demos because in
>> a production environment where you control the registry and the pix
>> manager, you can probably configure them to accept the same values.
>> But for testing and demos, which we all know are important to drive
>> sales, you may be pointing to public servers like IBM's registry and
>> Initiate's PIX manager- specifically for the point of saying "look,
>> IHE is so cool because it allows our software to work seamlessly with
>> servers from different vendors!!11!".
>>
>> Please let me know if I'm being clueless here (no tact required :-) or
>> if others feel this is a problem too?
>>
>> thanks,
>> Jesse
>>
>
Re: Bridge PIX feed conflict with PIX Manager and Registry [message #585355 is a reply to message #42402] Tue, 01 April 2008 09:18 Go to previous message
Matthew DavisFriend
Messages: 269
Registered: July 2009
Senior Member
Hi Sondra,

This is a bug, I agree... but the design needs to be considered further.
And Jesse's observation about adding a PIX property setting for the
registry MLLP receiver is valid as well. I'm just unsure if the Bridge
should *EVER* feed the registry - we can't necessarily stop it, but we
can avoid encouraging it as its designed currently.

There's also a consideration of workflowing it, although the number of
moving parts involved in a process like that makes me uneasy.

-Matt



Sondra Renly wrote:
> Hi All,
>
> As Matt described there are two pix feeds - one to the pix manager and
> one to the XDS registry. The pix feed to the pix manager contains your
> local ID while the pix feed to the XDS registry contains the affinity
> domain ID.
>
> We did not take this into account in the original Bridge design. This is
> a bug.
>
> Sondra
>
>
> Matthew Davis wrote:
>> Hi Jesse,
>>
>> You're spot on here. I was actually thinking about this other day while
>> reviewing some things (don't recall the discussion @ Connectathon, it
>> might've been with Sondra or Sarah). But you definitely need to have
>> available and use properties specific to a registry when doing a PIX
>> feed.
>>
>> However, there's some question about whether the operation should even
>> function like it does (pix feeding to both). Generally speaking, the ID
>> you're feeding to a PIX manager may not be the same ID you're feeding to
>> a registry.... in fact, it shouldn't be. A PIX Feed from the Bridge
>> will almost always be a local application registering with a PIX manager
>> (with a namespace and a domain OID that is unique to your
>> application/facility) whereas feeds to a registry should be the
>> patient's CAD ID (with no namespace and the CAD's/registry's domain
>> OID). Controlling the facility/application/namespace/domain information
>> is easy within the scope of the the RHIO configuration, but controlling
>> the actual ID number (in front of the ^^^) kind of makes it difficult to
>> send both at the same time...... unless you workflow it further:
>> 1. PIX Feed to the PIX Manager with local IDs
>> 2. PIX Query against the PIX Manager, restricting on the CAD's
>> domain to get the CAD ID for the patient
>> 3. PIX Feed to the XDS Registry with CAD ID
>>
>> And, at the same time, there's an argument that the Bridge should NEVER
>> feed a registry's patient ID... it should come solely from the PIX
>> manager. I'm not going to get into RHIO / Affinity Domain creation
>> policies ( i'll leave that to the experts ;) ) but it's something to
>> consider as well.
>>
>> This is definitely something to discuss further... Sarah, Sondra...
>> thoughts?
>>
>>
>>
>> Jesse Pangburn wrote:
>>> Hi,
>>> I know we discussed this a bit at Connectathon, but the resolution at
>>> the time was a short term workaround/hack to just do the patient feed
>>> to two different rhios.
>>>
>>> To reiterate, here is the example of the problem. Suppose I use the
>>> IBM registry and the Initiate PIX Manager. In the PIX manager
>>> settings section of the rhioConfig.xml I have something like this:
>>> <pixProperties>
>>> <id>PAT_IDENTITY_X_REF_MGR_INITIATE_PROPERTIES</id>
>>> <application>PAT_IDENTITY_X_REF_MGR_INITIATE</application>
>>> <facility>INITIATE</facility>
>>>
>>> <assigningAuthorityNamespaceId>INP2</assigningAuthorityNamespaceId >
>>>
>>> <assigningAuthorityUniversalId>1.3.6.1.4.1.21367.2005.1.1</assigningAuthorityUniversalId >
>>>
>>>
>>> <assigningAuthorityUniversalIdType>ISO</assigningAuthorityUniversalIdType >
>>>
>>> </pixProperties>
>>>
>>> So the bridge then uses this application/facility combo in the HL7v2
>>> PIX feed message to the PIX manager and it works fine. Then it uses
>>> the same application/facility combo and sends to to the registry's
>>> PIX feed port (I'm using IBM's to test with), however the registry
>>> returns an error because it doesn't like the application/facility
>>> values. It wants settings like this:
>>> <facility>XDSDEMO</facility>
>>> <application>XDSDEMO_ADT</application>
>>>
>>> In order to make this work, you need two RHIOs. One RHIO is has the
>>> IBM registry setup as a phony PIX manager so the PIX feed intended
>>> for the PIX Manager goes to the registry instead, but has the right
>>> application/facility values. The second RHIO has the real PIX
>>> manager you want to use setup and the registry listed with no PIX
>>> feed urls. So when you want to create a patient, you first send the
>>> create to RHIO #1 and populate the registry, then you send to RHIO #2
>>> and populate the PIX manager. Then you can continue using RHIO #2 to
>>> do PIX/PDQ queries and XDS actions.
>>>
>>> This is obviously not a good long term solution. What we need (I
>>> think) is a PIXServerPropertiesID element in the registry's
>>> pixFeedUrl element (or whatever configuration mechanism), so that we
>>> can send different application/facility values to the registry and
>>> PIX manager in the same PIX feed action.
>>>
>>> Now, it may be that this only matters for testing and demos because
>>> in a production environment where you control the registry and the
>>> pix manager, you can probably configure them to accept the same
>>> values. But for testing and demos, which we all know are important
>>> to drive sales, you may be pointing to public servers like IBM's
>>> registry and Initiate's PIX manager- specifically for the point of
>>> saying "look, IHE is so cool because it allows our software to work
>>> seamlessly with servers from different vendors!!11!".
>>>
>>> Please let me know if I'm being clueless here (no tact required :-)
>>> or if others feel this is a problem too?
>>>
>>> thanks,
>>> Jesse
>>>
>>
>
Re: Bridge PIX feed conflict with PIX Manager and Registry [message #585367 is a reply to message #42427] Tue, 01 April 2008 21:01 Go to previous message
Jesse Pangburn is currently offline Jesse PangburnFriend
Messages: 166
Registered: July 2009
Senior Member
Hi,
In the real scenarios that I'm considering, the PIX manager will be doing
the feeding of IDs to the Registry- it seems to be the best way so that's
what I'm recommending to people. It is a good question of whether the
bridge should be doing the PIX feed to the Registry or not in some cases,
but ultimately what's going to happen if IHE doesn't specify it one way or
the other is that customers are going to want to have it done different
ways. Some may say "well my PIX manager is on a different network than
the Registry so the PIX manager can't be expected to feed it, I want your
client system to do it." This is at least the case with demos for anyone
using a PIX manager from one company and a Registry from another.

As IHE allows both scenarios, any reason the bridge shouldn't support
both? I agree it's good to encourage people to go for the best path, but
sometimes you have to work within constraints not of your choosing. In
that case, developers using the bridge will be forced to create their own
hacks- like sending the PIX feed to a middle man server that will forward
it to the PIX Manager and forward a modified copy (with different
destination app/facility) to the Registry.

thanks,
Jesse

Matthew Davis wrote:

> Hi Sondra,

> This is a bug, I agree... but the design needs to be considered further.
> And Jesse's observation about adding a PIX property setting for the
> registry MLLP receiver is valid as well. I'm just unsure if the Bridge
> should *EVER* feed the registry - we can't necessarily stop it, but we
> can avoid encouraging it as its designed currently.

> There's also a consideration of workflowing it, although the number of
> moving parts involved in a process like that makes me uneasy.

> -Matt



> Sondra Renly wrote:
>> Hi All,
>>
>> As Matt described there are two pix feeds - one to the pix manager and
>> one to the XDS registry. The pix feed to the pix manager contains your
>> local ID while the pix feed to the XDS registry contains the affinity
>> domain ID.
>>
>> We did not take this into account in the original Bridge design. This is
>> a bug.
>>
>> Sondra
>>
>>
>> Matthew Davis wrote:
>>> Hi Jesse,
>>>
>>> You're spot on here. I was actually thinking about this other day while
>>> reviewing some things (don't recall the discussion @ Connectathon, it
>>> might've been with Sondra or Sarah). But you definitely need to have
>>> available and use properties specific to a registry when doing a PIX
>>> feed.
>>>
>>> However, there's some question about whether the operation should even
>>> function like it does (pix feeding to both). Generally speaking, the ID
>>> you're feeding to a PIX manager may not be the same ID you're feeding to
>>> a registry.... in fact, it shouldn't be. A PIX Feed from the Bridge
>>> will almost always be a local application registering with a PIX manager
>>> (with a namespace and a domain OID that is unique to your
>>> application/facility) whereas feeds to a registry should be the
>>> patient's CAD ID (with no namespace and the CAD's/registry's domain
>>> OID). Controlling the facility/application/namespace/domain information
>>> is easy within the scope of the the RHIO configuration, but controlling
>>> the actual ID number (in front of the ^^^) kind of makes it difficult to
>>> send both at the same time...... unless you workflow it further:
>>> 1. PIX Feed to the PIX Manager with local IDs
>>> 2. PIX Query against the PIX Manager, restricting on the CAD's
>>> domain to get the CAD ID for the patient
>>> 3. PIX Feed to the XDS Registry with CAD ID
>>>
>>> And, at the same time, there's an argument that the Bridge should NEVER
>>> feed a registry's patient ID... it should come solely from the PIX
>>> manager. I'm not going to get into RHIO / Affinity Domain creation
>>> policies ( i'll leave that to the experts ;) ) but it's something to
>>> consider as well.
>>>
>>> This is definitely something to discuss further... Sarah, Sondra...
>>> thoughts?
>>>
>>>
>>>
>>> Jesse Pangburn wrote:
>>>> Hi,
>>>> I know we discussed this a bit at Connectathon, but the resolution at
>>>> the time was a short term workaround/hack to just do the patient feed
>>>> to two different rhios.
>>>>
>>>> To reiterate, here is the example of the problem. Suppose I use the
>>>> IBM registry and the Initiate PIX Manager. In the PIX manager
>>>> settings section of the rhioConfig.xml I have something like this:
>>>> <pixProperties>
>>>> <id>PAT_IDENTITY_X_REF_MGR_INITIATE_PROPERTIES</id>
>>>> <application>PAT_IDENTITY_X_REF_MGR_INITIATE</application>
>>>> <facility>INITIATE</facility>
>>>>
>>>> <assigningAuthorityNamespaceId>INP2</assigningAuthorityNamespaceId >
>>>>
>>>>
<assigningAuthorityUniversalId>1.3.6.1.4.1.21367.2005.1.1</assigningAuthorityUniversalId >
>>>>
>>>>
>>>>
<assigningAuthorityUniversalIdType>ISO</assigningAuthorityUniversalIdType >
>>>>
>>>> </pixProperties>
>>>>
>>>> So the bridge then uses this application/facility combo in the HL7v2
>>>> PIX feed message to the PIX manager and it works fine. Then it uses
>>>> the same application/facility combo and sends to to the registry's
>>>> PIX feed port (I'm using IBM's to test with), however the registry
>>>> returns an error because it doesn't like the application/facility
>>>> values. It wants settings like this:
>>>> <facility>XDSDEMO</facility>
>>>> <application>XDSDEMO_ADT</application>
>>>>
>>>> In order to make this work, you need two RHIOs. One RHIO is has the
>>>> IBM registry setup as a phony PIX manager so the PIX feed intended
>>>> for the PIX Manager goes to the registry instead, but has the right
>>>> application/facility values. The second RHIO has the real PIX
>>>> manager you want to use setup and the registry listed with no PIX
>>>> feed urls. So when you want to create a patient, you first send the
>>>> create to RHIO #1 and populate the registry, then you send to RHIO #2
>>>> and populate the PIX manager. Then you can continue using RHIO #2 to
>>>> do PIX/PDQ queries and XDS actions.
>>>>
>>>> This is obviously not a good long term solution. What we need (I
>>>> think) is a PIXServerPropertiesID element in the registry's
>>>> pixFeedUrl element (or whatever configuration mechanism), so that we
>>>> can send different application/facility values to the registry and
>>>> PIX manager in the same PIX feed action.
>>>>
>>>> Now, it may be that this only matters for testing and demos because
>>>> in a production environment where you control the registry and the
>>>> pix manager, you can probably configure them to accept the same
>>>> values. But for testing and demos, which we all know are important
>>>> to drive sales, you may be pointing to public servers like IBM's
>>>> registry and Initiate's PIX manager- specifically for the point of
>>>> saying "look, IHE is so cool because it allows our software to work
>>>> seamlessly with servers from different vendors!!11!".
>>>>
>>>> Please let me know if I'm being clueless here (no tact required :-)
>>>> or if others feel this is a problem too?
>>>>
>>>> thanks,
>>>> Jesse
>>>>
>>>
>>
Re: Bridge PIX feed conflict with PIX Manager and Registry [message #585453 is a reply to message #42459] Thu, 03 April 2008 15:36 Go to previous message
No real name is currently offline No real nameFriend
Messages: 292
Registered: July 2009
Senior Member
You know me .. I can't resist adding my 2 cents -

XDS, unfortunately, is a bit mumms the word on the Patient Identity
Source for the XDS Registry. Re-reading this today - the profile asserts
the registry will recognize only one assigning authority domain, it does
not explicitly state there should be a single source actor for the
registry. IMHO - this should be singular (ie. grouped with a PIX
manager) rather than all edge systems dual feeding the registry - much
more practical. But, IHE allows for all sorts of topologies, thus OHF
should allow for these other options.

Now - I agree with matt, we should be careful as to how we design this
thing. The singluar item here is the assigning authority domain that the
registry and PIX working with this registry should share. Will take some
more thought, but point taken.

- Sarah ;-)


Jesse Pangburn wrote:
> Hi,
> In the real scenarios that I'm considering, the PIX manager will be
> doing the feeding of IDs to the Registry- it seems to be the best way so
> that's what I'm recommending to people. It is a good question of
> whether the bridge should be doing the PIX feed to the Registry or not
> in some cases, but ultimately what's going to happen if IHE doesn't
> specify it one way or the other is that customers are going to want to
> have it done different ways. Some may say "well my PIX manager is on a
> different network than the Registry so the PIX manager can't be expected
> to feed it, I want your client system to do it." This is at least the
> case with demos for anyone using a PIX manager from one company and a
> Registry from another.
>
> As IHE allows both scenarios, any reason the bridge shouldn't support
> both? I agree it's good to encourage people to go for the best path,
> but sometimes you have to work within constraints not of your choosing.
> In that case, developers using the bridge will be forced to create their
> own hacks- like sending the PIX feed to a middle man server that will
> forward it to the PIX Manager and forward a modified copy (with
> different destination app/facility) to the Registry.
>
> thanks,
> Jesse
>
> Matthew Davis wrote:
>
>> Hi Sondra,
>
>
>> This is a bug, I agree... but the design needs to be considered
>> further. And Jesse's observation about adding a PIX property setting
>> for the registry MLLP receiver is valid as well. I'm just unsure if
>> the Bridge should *EVER* feed the registry - we can't necessarily stop
>> it, but we can avoid encouraging it as its designed currently.
>
>
>> There's also a consideration of workflowing it, although the number of
>> moving parts involved in a process like that makes me uneasy.
>
>
>> -Matt
>
>
>
>
>> Sondra Renly wrote:
>>
>>> Hi All,
>>>
>>> As Matt described there are two pix feeds - one to the pix manager
>>> and one to the XDS registry. The pix feed to the pix manager contains
>>> your local ID while the pix feed to the XDS registry contains the
>>> affinity domain ID.
>>>
>>> We did not take this into account in the original Bridge design. This
>>> is a bug.
>>>
>>> Sondra
>>>
>>>
>>> Matthew Davis wrote:
>>>
>>>> Hi Jesse,
>>>>
>>>> You're spot on here. I was actually thinking about this other day
>>>> while
>>>> reviewing some things (don't recall the discussion @ Connectathon, it
>>>> might've been with Sondra or Sarah). But you definitely need to have
>>>> available and use properties specific to a registry when doing a PIX
>>>> feed.
>>>>
>>>> However, there's some question about whether the operation should even
>>>> function like it does (pix feeding to both). Generally speaking,
>>>> the ID
>>>> you're feeding to a PIX manager may not be the same ID you're
>>>> feeding to
>>>> a registry.... in fact, it shouldn't be. A PIX Feed from the Bridge
>>>> will almost always be a local application registering with a PIX
>>>> manager
>>>> (with a namespace and a domain OID that is unique to your
>>>> application/facility) whereas feeds to a registry should be the
>>>> patient's CAD ID (with no namespace and the CAD's/registry's domain
>>>> OID). Controlling the facility/application/namespace/domain
>>>> information
>>>> is easy within the scope of the the RHIO configuration, but controlling
>>>> the actual ID number (in front of the ^^^) kind of makes it
>>>> difficult to
>>>> send both at the same time...... unless you workflow it further:
>>>> 1. PIX Feed to the PIX Manager with local IDs
>>>> 2. PIX Query against the PIX Manager, restricting on the CAD's
>>>> domain to get the CAD ID for the patient
>>>> 3. PIX Feed to the XDS Registry with CAD ID
>>>>
>>>> And, at the same time, there's an argument that the Bridge should NEVER
>>>> feed a registry's patient ID... it should come solely from the PIX
>>>> manager. I'm not going to get into RHIO / Affinity Domain creation
>>>> policies ( i'll leave that to the experts ;) ) but it's something to
>>>> consider as well.
>>>>
>>>> This is definitely something to discuss further... Sarah, Sondra...
>>>> thoughts?
>>>>
>>>>
>>>>
>>>> Jesse Pangburn wrote:
>>>>
>>>>> Hi,
>>>>> I know we discussed this a bit at Connectathon, but the resolution
>>>>> at the time was a short term workaround/hack to just do the patient
>>>>> feed to two different rhios.
>>>>>
>>>>> To reiterate, here is the example of the problem. Suppose I use
>>>>> the IBM registry and the Initiate PIX Manager. In the PIX manager
>>>>> settings section of the rhioConfig.xml I have something like this:
>>>>> <pixProperties>
>>>>> <id>PAT_IDENTITY_X_REF_MGR_INITIATE_PROPERTIES</id>
>>>>> <application>PAT_IDENTITY_X_REF_MGR_INITIATE</application>
>>>>> <facility>INITIATE</facility>
>>>>>
>>>>> <assigningAuthorityNamespaceId>INP2</assigningAuthorityNamespaceId >
>>>>>
>
> <assigningAuthorityUniversalId>1.3.6.1.4.1.21367.2005.1.1</assigningAuthorityUniversalId >
>
>
>>>>>
>>>>>
>
> <assigningAuthorityUniversalIdType>ISO</assigningAuthorityUniversalIdType >
>
>>>>>
>>>>> </pixProperties>
>>>>>
>>>>> So the bridge then uses this application/facility combo in the
>>>>> HL7v2 PIX feed message to the PIX manager and it works fine. Then
>>>>> it uses the same application/facility combo and sends to to the
>>>>> registry's PIX feed port (I'm using IBM's to test with), however
>>>>> the registry returns an error because it doesn't like the
>>>>> application/facility values. It wants settings like this:
>>>>> <facility>XDSDEMO</facility>
>>>>> <application>XDSDEMO_ADT</application>
>>>>>
>>>>> In order to make this work, you need two RHIOs. One RHIO is has
>>>>> the IBM registry setup as a phony PIX manager so the PIX feed
>>>>> intended for the PIX Manager goes to the registry instead, but has
>>>>> the right application/facility values. The second RHIO has the
>>>>> real PIX manager you want to use setup and the registry listed with
>>>>> no PIX feed urls. So when you want to create a patient, you first
>>>>> send the create to RHIO #1 and populate the registry, then you send
>>>>> to RHIO #2 and populate the PIX manager. Then you can continue
>>>>> using RHIO #2 to do PIX/PDQ queries and XDS actions.
>>>>>
>>>>> This is obviously not a good long term solution. What we need (I
>>>>> think) is a PIXServerPropertiesID element in the registry's
>>>>> pixFeedUrl element (or whatever configuration mechanism), so that
>>>>> we can send different application/facility values to the registry
>>>>> and PIX manager in the same PIX feed action.
>>>>>
>>>>> Now, it may be that this only matters for testing and demos because
>>>>> in a production environment where you control the registry and the
>>>>> pix manager, you can probably configure them to accept the same
>>>>> values. But for testing and demos, which we all know are important
>>>>> to drive sales, you may be pointing to public servers like IBM's
>>>>> registry and Initiate's PIX manager- specifically for the point of
>>>>> saying "look, IHE is so cool because it allows our software to work
>>>>> seamlessly with servers from different vendors!!11!".
>>>>>
>>>>> Please let me know if I'm being clueless here (no tact required :-)
>>>>> or if others feel this is a problem too?
>>>>>
>>>>> thanks,
>>>>> Jesse
>>>>>
>>>>
>>>
>
>
Re: Bridge PIX feed conflict with PIX Manager and Registry [message #585509 is a reply to message #42660] Thu, 03 April 2008 17:19 Go to previous message
Jesse Pangburn is currently offline Jesse PangburnFriend
Messages: 166
Registered: July 2009
Senior Member
Right, I think we're all agreed that we believe the best topology in a
prod environment is the PIX Manager being the only system allowed to feed
the registry. We're also agreed that IHE is not specific on this matter
and that a scenario where the client feeds the PIX Manager and Registry is
perfectly IHE compliant.

I think that in order to feed the PIX Manager and the Registry, you can
really only have one client because that client HAS to be the assigning
authority for the domain- otherwise you cannot feed the Registry too.
It's kinda silly to allow this because you really can't have multiple
client systems in this environment unless you rig it by having different
clients use a fixed prefix on the IDs (a poor man's namespace). And then
you get multiple IDs in the same namespace that belong to the same
patient, so that doesn't really work either. It's really a worthless
setup, only good for Connectathon and demos really. Since there's no way
to send different IDs to the two places and have it make any kind of
sense, it seems to me that the only thing you need is to be able to send a
different destination application and facility. There's no way any one is
going to use it in production, what good would it be to have an IHE system
with just one client?

Jesse :-)

Sarah Knoop wrote:

> You know me .. I can't resist adding my 2 cents -

> XDS, unfortunately, is a bit mumms the word on the Patient Identity
> Source for the XDS Registry. Re-reading this today - the profile asserts
> the registry will recognize only one assigning authority domain, it does
> not explicitly state there should be a single source actor for the
> registry. IMHO - this should be singular (ie. grouped with a PIX
> manager) rather than all edge systems dual feeding the registry - much
> more practical. But, IHE allows for all sorts of topologies, thus OHF
> should allow for these other options.

> Now - I agree with matt, we should be careful as to how we design this
> thing. The singluar item here is the assigning authority domain that the
> registry and PIX working with this registry should share. Will take some
> more thought, but point taken.

> - Sarah ;-)


> Jesse Pangburn wrote:
>> Hi,
>> In the real scenarios that I'm considering, the PIX manager will be
>> doing the feeding of IDs to the Registry- it seems to be the best way so
>> that's what I'm recommending to people. It is a good question of
>> whether the bridge should be doing the PIX feed to the Registry or not
>> in some cases, but ultimately what's going to happen if IHE doesn't
>> specify it one way or the other is that customers are going to want to
>> have it done different ways. Some may say "well my PIX manager is on a
>> different network than the Registry so the PIX manager can't be expected
>> to feed it, I want your client system to do it." This is at least the
>> case with demos for anyone using a PIX manager from one company and a
>> Registry from another.
>>
>> As IHE allows both scenarios, any reason the bridge shouldn't support
>> both? I agree it's good to encourage people to go for the best path,
>> but sometimes you have to work within constraints not of your choosing.
>> In that case, developers using the bridge will be forced to create their
>> own hacks- like sending the PIX feed to a middle man server that will
>> forward it to the PIX Manager and forward a modified copy (with
>> different destination app/facility) to the Registry.
>>
>> thanks,
>> Jesse
>>
>> Matthew Davis wrote:
>>
>>> Hi Sondra,
>>
>>
>>> This is a bug, I agree... but the design needs to be considered
>>> further. And Jesse's observation about adding a PIX property setting
>>> for the registry MLLP receiver is valid as well. I'm just unsure if
>>> the Bridge should *EVER* feed the registry - we can't necessarily stop
>>> it, but we can avoid encouraging it as its designed currently.
>>
>>
>>> There's also a consideration of workflowing it, although the number of
>>> moving parts involved in a process like that makes me uneasy.
>>
>>
>>> -Matt
>>
>>
>>
>>
>>> Sondra Renly wrote:
>>>
>>>> Hi All,
>>>>
>>>> As Matt described there are two pix feeds - one to the pix manager
>>>> and one to the XDS registry. The pix feed to the pix manager contains
>>>> your local ID while the pix feed to the XDS registry contains the
>>>> affinity domain ID.
>>>>
>>>> We did not take this into account in the original Bridge design. This
>>>> is a bug.
>>>>
>>>> Sondra
>>>>
>>>>
>>>> Matthew Davis wrote:
>>>>
>>>>> Hi Jesse,
>>>>>
>>>>> You're spot on here. I was actually thinking about this other day
>>>>> while
>>>>> reviewing some things (don't recall the discussion @ Connectathon, it
>>>>> might've been with Sondra or Sarah). But you definitely need to have
>>>>> available and use properties specific to a registry when doing a PIX
>>>>> feed.
>>>>>
>>>>> However, there's some question about whether the operation should even
>>>>> function like it does (pix feeding to both). Generally speaking,
>>>>> the ID
>>>>> you're feeding to a PIX manager may not be the same ID you're
>>>>> feeding to
>>>>> a registry.... in fact, it shouldn't be. A PIX Feed from the Bridge
>>>>> will almost always be a local application registering with a PIX
>>>>> manager
>>>>> (with a namespace and a domain OID that is unique to your
>>>>> application/facility) whereas feeds to a registry should be the
>>>>> patient's CAD ID (with no namespace and the CAD's/registry's domain
>>>>> OID). Controlling the facility/application/namespace/domain
>>>>> information
>>>>> is easy within the scope of the the RHIO configuration, but controlling
>>>>> the actual ID number (in front of the ^^^) kind of makes it
>>>>> difficult to
>>>>> send both at the same time...... unless you workflow it further:
>>>>> 1. PIX Feed to the PIX Manager with local IDs
>>>>> 2. PIX Query against the PIX Manager, restricting on the CAD's
>>>>> domain to get the CAD ID for the patient
>>>>> 3. PIX Feed to the XDS Registry with CAD ID
>>>>>
>>>>> And, at the same time, there's an argument that the Bridge should NEVER
>>>>> feed a registry's patient ID... it should come solely from the PIX
>>>>> manager. I'm not going to get into RHIO / Affinity Domain creation
>>>>> policies ( i'll leave that to the experts ;) ) but it's something to
>>>>> consider as well.
>>>>>
>>>>> This is definitely something to discuss further... Sarah, Sondra...
>>>>> thoughts?
>>>>>
>>>>>
>>>>>
>>>>> Jesse Pangburn wrote:
>>>>>
>>>>>> Hi,
>>>>>> I know we discussed this a bit at Connectathon, but the resolution
>>>>>> at the time was a short term workaround/hack to just do the patient
>>>>>> feed to two different rhios.
>>>>>>
>>>>>> To reiterate, here is the example of the problem. Suppose I use
>>>>>> the IBM registry and the Initiate PIX Manager. In the PIX manager
>>>>>> settings section of the rhioConfig.xml I have something like this:
>>>>>> <pixProperties>
>>>>>> <id>PAT_IDENTITY_X_REF_MGR_INITIATE_PROPERTIES</id>
>>>>>> <application>PAT_IDENTITY_X_REF_MGR_INITIATE</application>
>>>>>> <facility>INITIATE</facility>
>>>>>>
>>>>>> <assigningAuthorityNamespaceId>INP2</assigningAuthorityNamespaceId >
>>>>>>
>>
>>
<assigningAuthorityUniversalId>1.3.6.1.4.1.21367.2005.1.1</assigningAuthorityUniversalId >
>>
>>
>>>>>>
>>>>>>
>>
>> <assigningAuthorityUniversalIdType>ISO</assigningAuthorityUniversalIdType >
>>
>>>>>>
>>>>>> </pixProperties>
>>>>>>
>>>>>> So the bridge then uses this application/facility combo in the
>>>>>> HL7v2 PIX feed message to the PIX manager and it works fine. Then
>>>>>> it uses the same application/facility combo and sends to to the
>>>>>> registry's PIX feed port (I'm using IBM's to test with), however
>>>>>> the registry returns an error because it doesn't like the
>>>>>> application/facility values. It wants settings like this:
>>>>>> <facility>XDSDEMO</facility>
>>>>>> <application>XDSDEMO_ADT</application>
>>>>>>
>>>>>> In order to make this work, you need two RHIOs. One RHIO is has
>>>>>> the IBM registry setup as a phony PIX manager so the PIX feed
>>>>>> intended for the PIX Manager goes to the registry instead, but has
>>>>>> the right application/facility values. The second RHIO has the
>>>>>> real PIX manager you want to use setup and the registry listed with
>>>>>> no PIX feed urls. So when you want to create a patient, you first
>>>>>> send the create to RHIO #1 and populate the registry, then you send
>>>>>> to RHIO #2 and populate the PIX manager. Then you can continue
>>>>>> using RHIO #2 to do PIX/PDQ queries and XDS actions.
>>>>>>
>>>>>> This is obviously not a good long term solution. What we need (I
>>>>>> think) is a PIXServerPropertiesID element in the registry's
>>>>>> pixFeedUrl element (or whatever configuration mechanism), so that
>>>>>> we can send different application/facility values to the registry
>>>>>> and PIX manager in the same PIX feed action.
>>>>>>
>>>>>> Now, it may be that this only matters for testing and demos because
>>>>>> in a production environment where you control the registry and the
>>>>>> pix manager, you can probably configure them to accept the same
>>>>>> values. But for testing and demos, which we all know are important
>>>>>> to drive sales, you may be pointing to public servers like IBM's
>>>>>> registry and Initiate's PIX manager- specifically for the point of
>>>>>> saying "look, IHE is so cool because it allows our software to work
>>>>>> seamlessly with servers from different vendors!!11!".
>>>>>>
>>>>>> Please let me know if I'm being clueless here (no tact required :-)
>>>>>> or if others feel this is a problem too?
>>>>>>
>>>>>> thanks,
>>>>>> Jesse
>>>>>>
>>>>>
>>>>
>>
>>
Previous Topic:Enterprises that use OHF
Next Topic:Enterprises that use OHF
Goto Forum:
  


Current Time: Thu Mar 28 15:01:23 GMT 2024

Powered by FUDForum. Page generated in 0.26244 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top