Hi Victor,

I assume that you need Dynamic Objects in order to create some JSON Output (so you can call %ToJSON() on the object to create a JSON string). So in my opinion, the complexity of your JSON object will drive these decisions - for example, how deeply nested will your JSON need to be?

From some familiarity with TextReader, it records every XML Element into a Property. So in theory, each Property can have its corresponding Dynamic Object which will be a Name/Value pair: Name = Name of Property; Value = Value of Property (i,e. XML Text Node)

It is hard to say more without seeing your XML structure or your JSON Spec. You may find the following links helpful:




I would strongly advise using Ensemble framework as a starting point as there would be much less coding involved. However, if this is not an option, you probably will need to proceed as follows:

1) Procure a Web Server that can support an AS2 protocol (I assume most Web Servers can do that and you most likely already have one). You would use SSL Certificates to authenticate the request if sent over https, which would be installed into the Trust Store of your Web Server (for Apache on Linux, it is just a file containing nothing but certs that look like hex characters).  I am not familiar with AS2 but I assume that you would probably need to activate a Web Server module for its support and there may be additional certs to install. The incoming requests will be forwarded to your Application Server

(This step is likely needed even if you were to use Ensemble)

2) Build  SOAP-based or REST-based Web Service that can receive http requests with attachments. If you can do all of the authentication on the Web Server, this Web Service will be running on your Application Server. It would simply need to process the request and read your attached EDI file. Here is the docs I found that might be helpful:

For SOAP: https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GSOAP_intro
For REST: https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GREST_services

3) Build business logic to parse the EDI file. This is where Ensemble comes in really handy because it likely already has an EDI parser.

I hope this helps... Maybe someone with more AS2 experience can comment on this thread.

Hi Jo Ellen,

Can you try to change your SQL query into

INSERT INTO myTable (MessageType) values (?)

I have not tested this but from what I read about ISNULL(), this might work. If your MessageType  field is NULL (I assume that is your default) it should return '' which might parametrize your query...

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!

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.