[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.technology.ohf] Re: Bridge PIX feed conflict with PIX Manager and Registry 
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