Hi Michael,

To summarize, HealthConnect is built on top of Ensemble. If you are getting HealthConnect, you must also have Ensemble. 

Here is the main difference: Ensemble in an Interface Engine that is used primarily to receive data in most common formats and transform the data before re-sending transformed data to another destination. Ensemble supports FTP File Transfer, SQL Transfer (with a connection to another DB), HTTP Transfer and TCP Transfer. As part of TCP Transfer there is also support for HL7 Standard. The outbound support is the same as for inbound. As part of Ensemble there are Transformation Languages (BPL, DTL) that allow you to transform your data.

HealthConnect has all of that but because it is specialized, in addition to the above transfer modes, it also implements the IHE IT Infrastructure Technical Framework (if you search for it you will get its documentation on the IHE web site). In order to implement the framework, in addition to the Interface Engine, you have to have a set of Configuration Databases (Registries). This is what HealthConnect provides. In a nutshell, with HealthConnect, you can process and transform not only HL7 messages but also Continuity of Care Documents (CCDs) - XML-based documents that are typically delivered via SOAP messages with a specialized SOAP Body (IHE Transaction) and a payload/attachment (the CCD document itself which is typically b64-encoded). HealthConnect also has a native intermediate XML format (SDA) and it provides ready-made (and customizable) XSLT transforms that can transform the CCD to and from this native format.

I hope this helps.

Hi Kurro,

1) The best way to debug SOAP issues is to enable SOAP Logging on the client side.

On your Cache server, use Terminal to zn to the namespace from which the request originates and type:

NAMESPACE> set ^ISCSOAP("LogFile")="C:\temp\SOAP.log"

NAMESPACE> set ^ISCSOAP("Log")="ios"

and then retry your GET/POST. You should see messages in the file above.

To turn off logging, type:

NAMESPACE> set ^ISCSOAP("Log")=""

2) If you try this you will likely see the same error in the SOAP log. So the most likely issue is the ContentType property of your HttpRequest object.

In your Business Operation, your probably have code like this somewhere:

Set tHttpRequest = ##class(%Net.HttpRequest).%New()

Set tHttpRequest.ContentType = "text/xml" // is this property set?

Here is the message from the class on its default behavior:

Sets/gets the 'Content-Type:' entity header field in the HTTP request. If it
/// is not specified and there is an <PROPERTY>EntityBody</PROPERTY> then it default
/// to 'text/html'.<p>

...

Property ContentType As %String [ Calculated ];
 

So if you used HttpRequest.EntityBody for your payload, you probably need to set ContentType explicitly.

I hope this helps.

Hi Ahmad,

Please see my summary below:

From the Management point of view, Option 2 is much preferred - less configuration, and as a result, less maintenance (also less work for your EHR Participants). One variable is Consent and the legal framework under which you are operating. Can doctors from the same Facility Group see patients belonging to different branches? How is Consent collected at these branches (does the medical staff collect consent per branch or is it understood that the information can be shared with doctors within the Facility Group)? Option 2 is only even possible because MRNs are the same within the Facility Group.

That said, there is one additional consideration which may end up a deal-breaker. If an ADT message for a patient in Facility Group A Branch 1 is processed, and then another ADT message (different ADT event) for the same patient is processed in Facility Group A Branch 2, unless the Medical Record is truly shared on the EMR side, you may have order issues. For example, ADT^A04 (register) is at Branch 1 and then the patient is discharged (A03), then patient goes to Branch B, there is an ADT^A04 (new register) and the patient is admitted and transferred to Inpatient (A06). So far, everything is OK because the patient cannot be in two branches at the same time but if there is a glitch and one of the Branches stops transmitting for a while (unlikely but possible) the order of events may get scrambled.

I hope this helps.

This use case looks good for the ISC product "HealthConnect"... it is designed to accept some data, transform it and output new data. It includes built-in XSLT Transforms that can transform CCD Documents into SDA (XML format for ISC Data Model) and back to CCD.

If you have ISC HealthConnect, you can do the following:

1) Use one of the CCDA-to-SDA transforms to create an SDA XML Document

2) Use TransformIntoObject() method of HS.Util.XSLTTransformer to get an SDA Object with Properties

3) Change whatever you need and save a new SDA Object

4) Use TransformFromObject() of the same class to get a new SDA Document

5) Use one of the SDA-to-CCDA XSLT Transforms to create a new CCDA Document.

All of this is basically out of the box... you just need to find a way to get your document into the system. If you just use FTP you can either use Ensemble FTP Service or write a script to transfer the files onto the file system where an Ensemble FileService would pick them up. 

You probably would need to create a Business Operation that would invoke the Transforms and manipulate your data; after that you can pass your output to an FTPOperation that will send the files out to your recipients.

If you don;t have HealthConnect, I would recommend getting it - XSLT is very fast compared to reading the XML directly into Objects. ISC basically solved this problem for you (for extra money of course...) If it is not possible, you may need to write your XML to Obj conversion... I don;t think there is anything like that in Ensemble...

Hi Frances,

You are saying that you are getting an Order message. Is it an ORM message or an ORU message (the latter typically contains OBX segments and is of type Observation/Result). 

In general, you would probably have to do something of the following:

1) During message processing, concatenate the content of every OBX:5 field into a single variable. In order to avoid a "Long String" problem in Cache, I would open a GlobalCharacterStream or FileCharacterStream and keep writing each new OBX:5 field to Stream as you loop over the segments.

2) In order to convert anything into PDF, you would need an external Rendering Engine. There is one I found on Open Exchange:

https://openexchange.intersystems.com/package/iris-pdf-generator

Also, Cache provides Apache FOP PDF Engine.  Here is some documentation on how to run it:

https://xmlgraphics.apache.org/fop/

https://xmlgraphics.apache.org/fop/2.5/running.html

The issue is, how to invoke the rendering engine from your ObjectScript code. This thread might be helpful:

https://community.intersystems.com/post/how-create-pdf-file-html

You can then write your PDF to a file.

3) If you wrote your PDF to file, you can use the following article on how to embed it into the HL7 Message:

https://community.intersystems.com/post/ensemble-how-embed-pdf-file-hl7-...

This is a complex project; but the tools listed here should help you.

Hi Blakely,

I assume you already have code that goes over your XML and extracts data into the HL7 fields.

So then you get to the Par_Location element, do something like this:

Set tPar_Location_Text = M071|M074|...

For i=1:1:$LENGTH(tPar_Location_Text) {

    Set word = $PIECE(tPar_Location_Text, "|", i)

    Do createSegment("IVT", i, word, field3, ...)

}

Note I assume you have a routine that creates the segments...

I hope this helps

Vitaly