Replies

Looking at the code, I see that EnsLib.RecordMap.Service.FileService extends EnsLib.RecordMap.Service.Standard. You can try to create a custom Business Service (for example, EnsLib.RecordMap.Service.StreamService) extending the same parent class and override the OnProcessInput method to process your stream.

One issue you might have is, the FileService is bound to EnsLib.File.InboundAdapter that does a lot of work in the service. There are other types of out-of-the-box adapters - like EnsLib.HTTP.InboundAdapter which you could use here but your code would be customized.

Please note that this might not be officially supported by ISC.

I had not worked with DICOM for quite a while but my first tack would be to enable logging on the receiving PACS and try to see what the errors look like.

Hi Mary,

I just went through a similar exercise, although in my case, I was importing JSON Data directly into SDA.

I can think of two ways of going about this:

The first one is what you are doing - that is, extracting JSON data using %Get(), %GetNext(), etc... and save the data to the Properties of the correct EnsLib.HL7.Message object (based on the message type). This is the most straightforward way but I found that it has drawbacks. The biggest one is that you have to initialize every variable that is being saved to the object Property. The reason is, you usually wouldn't know whether a certain field that you expect is populated or not (unless you have a way to check this by running the JSON files through some kind of schema first). So if you try to store something that you expect but does not exist in this particular JSON snippet, your processing would stop. Everything that is being set to a Property should be initialized (usually to ""). 

Because you are on IRIS, you have another option. IRIS now supports JSON Adaptors (not sure if your particular version supports it). You could create a Data Model: a separate Object for each HL7 message, which would all extend %JSON.Adaptor. This is rather like working with %XML.Adaptor: you should be able to read JSON messages directly without using Dynamic Objects. The advantage would be that before storing the data in the HL7 Message Object, you would store it in an intermediate object. I see the following advantages:

1) If you need to make a change because message structure changes, you would make a change only to the particular object, not the whole Business Process/Operation that would be extracting all of your JSON files.

2) It is easier to troubleshoot and maintain for the same reason.

3) It is easier to scale for different Participants (if they have differing JSON objects)

4) These objects would be %Persistent so you could pass them to Methods and in Ensemble messages.

Because you are dealing with JSON objects that mimic HL7 messages, this method may not give you more advantages. HL7 messages are discrete so if you create a Business Service for each message you could create a business process for each one as well, making it easier to troubleshoot. 

I hope this helps.

Hi Dmitry,

I just typed a lengthy answer but I think Marc's answer is better... looks like Ensemble has a Business Operation that solves your issue

Yes or course... in this case, you would return patients that have an instance of one Facility but not the other.

There might be an easier way:

Select * from HS_Registry.Patient where Facility='ABC' and MPIID in

(select MPIID from HS_Registry.Patient where Facility='XYZ')

MPIID is an indexed field so this should be relatively fast. Since the Patent table is the same you really need to get your "*" data only once; you just need to constrain it to only return a subset of patients that have instances of both Facilities (if I understand you correctly)

Hi George,

I would start by reading the following:

https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=EF...

This explains how the FTP Inbound Adapter works and how to create a Business Service with the ADAPTER parameter. As an example, take a look at EnsLib.FTP.PassthroughService  class.

An Ensemble FTP Service is essentially a poller - it would connect to the remote FTP server and pull files from a remote folder that is specified in the File Path property on the Business Service.

We had to deal with this issue once. The class is EnsLib.HL7.SearchTable which extends Ens.VDoc.SearchTable. You can extend EnsLib.HL7.SearchTable and add a new PropName "MSHSendingFacility" to the SearchSpec XData block:

<Item DocType=""  PropName="MSHSendingFacility>[MSH:3]</Item>

Or you can create a parallel class that extends %Persistent and Ens.VDoc.SearchTable directly and copy the XData block from EnsLib.HL7.SearchTable, adding the line above to the block.

Hi Ahmad,

I would start with the following:

Generating Alerts:

cedocs.intersystems.com/latest/csp/docbook/Doc.View.cls?KEY=EGDV_prog#EGDV_prog_alerts_defining

Monitoring Alerts:

https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?K...

There is more documentation about Alerts and and ISC Training (it is part of Study Materials for Certified Health Connect Expert Certification). 

Implementing alerts might let you sort the errors you are getting in the Event Log and decide which errors would need an alert that can then be sent to your Participant.

Hi,

I may try this later if I have time by I think I know why this would not work.

SourceTable.Field2 is a static Property so I don't think you can change its name on the fly. 

I have to run now but I would suspect that we may be able to get to the Property name with a Dynamic SQL Query and maybe set it while iterating through the ResultSet