New post
Question
· Apr 16, 2020

Retrieve XDS.b document registered, but not stored in the repository

#HealthShare

Rather than doing a PnR I can register documents in the XDS.b Registry and store the data elsewhere, such as in the file system.  Upon retrieval, however, how can I fetch it from a non-standard location? For example, a progress note whose body is stored in a SDA3 streamlet?

Discussion (4)1
Log in or sign up to continue
Vitaly Furman · Apr 17, 2020

Usually, when we register a document with HealthShare, we need to specify RepositoryUniqueId in the RegisterDocumentSet-b (ITI-42) metadata. In turn, you would create a Repository with the Repository OID (unique ID) in the OID Registry and a Repository EndPoint in the Service Registry. The EndPoint configuration will have the URL to access your External Repository. 

All of this applies if you are storing the whole document externally. A progress note can be a type of document, and if you describe its type (RTF, PDF, etc...) you can probably use HS.IHE.XDSb.Consumer.Operations in HSCONSUMER namespace to retrieve the document and have it aggregated into the larger SDA for delivery to your Access Gateway. You may have to customize the HS.IHE.XDSb.Consumer.Operations component. The Retrieval path would then be:

HSACCESS -> (Patient Fetches to Edge Gateways, including HSCONSUMER) -> HSCONSUMER -> (Retrieve call to External Repository; likely using https) -> External File System (Return Document in the <https> <soap> etc  envelope) -> HSCONSUMER -> (Process the document so that it can be inserted into SDA) -> HSACCESS (return aggregated SDA and insert into Viewer Cache)

However, if you store the body of the document in a say, Document Streamlet, I would have to assume that your external repository is another HealthShare Edge Gateway... in this case, the above would likely not apply; and instead, you would need custom code that would be able to pull the SDA directly from an external Streamlet database. I guess, more information is needed to fully answer this question.

0 0
Kevin Kindschuh · Apr 17, 2020

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

0 0
Vitaly Furman · Apr 27, 2020

I think I understand better what you are trying to do. You would like to convert a Progress Note being passed in the HL7 v2 message into an XDS.b document. While there may be use cases for this, I just want to mention that Clinical Viewer can display documents stored in the Document streamlet and received via HL7 v2. For example, I would get Discharge Summaries in the MDM message (those were b64-encoded PDF) and they would display in the Documents tab.

Back to your use case:

1. The first step in this process would be to intercept the message somewhere on Edge Gateway where HL7-to-SDA3 conversion is taking place. The issue is, we first need to detect that a document is being stored. If all of your HL7 messages going to that edge carry documents (and you want all of them registered), that step is not needed. I will omit it for the sake of this discussion. So once you determine that there is a Document to be registered, you would need a custom Operation that would create the Register-Document-Set-b metadata and set the correct Repository ID. You will have to create a separate Repository in the OID Registry with an OID as Repository ID and a path to it in the Service Registry (the EndPoint would end on /HS.IHE.XDSb.Repository.Services.cls). The target for this Operation would be XDSb.Registry (HS.IHE.XDSb.Registry.Services on the Hub). You also would need a Document Unique ID and ObjectType (there is a hex value for Stable documents as this would be a Stable, not OnDemand, document)

2. The standard HS.IHE.XDSb.Consumer.Operations is running on HSCONSUMER. You may have to customize it a little bit (see below)

3. I think your workflow is correct. When you customize  HS.IHE.XDSb.Repository.Operations, you will likely use LoadSDA() method and then you can walk to the <Document> SDA, pull the data out and attach it in the Response that the Operation constructs. The HSCONSUMER should process the response (using something like GetDocumentAsSDA()) and create an EPRFetchNotification which will be returned to the Access Gateway.  I think EPRFetchNotification needs to be created similarly to how it is done in HS.Gateway.ECR.Process (which returns regular Edge data)

I think you are on the right path... Good luck!

0 0
Kevin Kindschuh · May 6, 2020

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!

0 0