The TLS capabilities are also platform dependent, so simple Ensemble upgrade will not suffice.

Not sure if I understood your requirement correctly, but I use Modality Emulator like (https://www.dvtk.org/dicom/ris-emulator/) to test FIND for example WorkList queries. There is a free version if you want to try that first.

Since nobody seems to take this, I’ll say what I think. 
First, there is no ’standard’ sample for any ORM, or any other HL7 v2 message. Each application utilizing these messages pose their own interpretations, coding and other requirements on the applicable message exhange. IRIS for Health provides a nice virtual document (vDOC) to view and manipulate HL7 messages and exposes all valid fields according to selected HL7 version schema. 

If you are looking to provide a messaging service using HL7 v2 messages with a party, you can pick an choose pretty much how you use the message format. If the orher party already has that defined, you should ask them to provide the samples for you.

-Pasi-

You can create a REST based interface in IRIS for your application to talk to, but IRIS sounds like a huge overkill to become just a ”database” unless there are tons of requirements to integrate with other back end systems at the same time.

-Pasi-

I have been using %XML.Document methods to manipulate XML. As soon as you find the appropriate %XML.Node, you can use method ReplaceCharacter().

-Pasi-

With ftp errors I just usually google with the error code. This is Error: 426 Connection closed; transfer aborted. This could be related to active/passive mode setting. Have you considered this in your custom adapter?

I have implemented a dicom worklist service with integration to our RIS system.

I would advice you against a 1:1 messaging back to Epic though. Here is why:

- many Modalities request worklists very frequently, so the workload or latency to Epic side might become a limiting factor
- modalities share several study rooms/resources and that modality/resource mapping might not be available in Epic (I could be wrong here)
 

In stead, how I did it was to attach the dicom service to our RIS’s event handler mechanism which would send a Soap call upon any changes of a study status and describing details of the study to the dicom service. The dicom service would then store/update the relevant details of the study internally, so when the modality requests a worklist, the service already has all the data and does not have to request it from somewhere else. The dicom service also holds mapping between resources, modality AET’s and provides an UI to maintain that.

I have used these tools on legacy versions:

https://github.com/PlanetCache/CacheJSON

-Pasi-