Recent posts:
Recent replies:

Yes, these document already appear in the Clinical Viewer, however, they do not appear for document consumers that fetch through XDS.b, not the viewer. So the question is how to make them visible for those consumers as well.  My customer considered replicating the documents in the registry, which is the cleanest approach used by another of my customers. But there are an extremely large number of these accumulated over a decade so they prefer an approach that avoids duplicating them in requisitioned expansion of storage. 

Your insight has already been valuable. Many thanks!

This is very helpful.

So if I received a progress note in HL7 v2, I could

  1. add registration of it as a document with a repositoryID that indicates the edge gateway where it is being stored in SDA
    1. This would add the progress note to the list returned by an XDS.b document search response by an external consumer
  2. It looks as if the standard  HS.IHE.XDSb.Consumer.Operations in the Registry would pass a request for retrieval of the to the particular edge in which it is stored without any customization, right?
  3. In the Edge that may have the progress note document stored in the steamlet, add the HS.IHE.XDSbRepositoryServices and HS.IHE.XDSb.Repository.Process components and set the RepositoryOperations setting to a custom version of HS.IHE.XDSb.Repository.Operations that overrides the RetrieveDocument() method grab the document body from the streamlet instead of the ECR.
  4. This would allow document search and retrieval to operate just as if the entire document was stored with with a PnR

Am I close?

Thanks!!
Kevin

I suspect the Message Schema Category setting specified in your Business Service is NOT specifying category 2.2. This setting overrides whatever version number is in MSH:12 (since the MSH value is notoriously unreliable). You may be specifying another version or a custom schema.  When the message hits your rule, the docCategory constraint value is compared to what the Business Service assigned, not MSH:12. 

Look at a message that failed in the Message Viewer Body tab, to see the MessageTypeCategory value (which is compared to docCategory) and Name value (which is compared to docName). One of them does not match, otherwise the message would be sent.

The WHEN conditional expression in Rule 1 does absolutely nothing. The pair of AND conditions duplicates the docName filter in the Constraint so also has no effect. And therefore adding  OR 1=1 further has no effect. So the Constraint has to be your problem.

If you added the same constraints to Rule 2, it would also break, since your problem is with the constraints. 

Followers:
Kevin has no followers yet.
Following:
Global Masters badges: