Are you able to share the full error you're seeing?

I have just tested this, and I'm getting no such errors when compiling.

This may cause some regions to opt for FHIR as a response while others opt for other solutions such as OpenEHR.

There's no reason for these to be seen as competing standards. A model where the data storage is OpenEHR and the data transfer is FHIR is seen by some as the best of both worlds 🙂

I'm not sure there's a way to select it when creating a production export.

The data in stored within the Global "Ens.Config.BusinessPartnerD" which you could export separately and then import into your new environment?

Stupidly, no.

As the default was set to "TEST" in my function, it worked fine throughout testing. Once the upgrade to Prod occurred, the issue was spotted, and the simple solution was to just reset the values. As I was moving from an adhoc to a official release, I chalked it up to that.

Next time, WRC will be getting a call 🙂

Word of warning for using this - I have had this value be reset during an upgrade on Healthconnect.

I was using this value in a function to control the output of a Transform, and I hadn't accounted for the chance of this returning null.

My code looked something like this:

ClassMethod WhatEnvAmI()
{
	Set Env = $SYSTEM.Version.SystemMode()
	
	If (Env = "LIVE")||(Env = "FAILOVER"){
		Quit "LIVE"
		}
	Quit "TEST"
}

So, post upgrade, the transform suddenly begun outputting values specific to the test system from the live environment.

If you were to use the Parenthesis () Syntax in your routing rule, you could simply make your rule something like:

The reason this works is that using the parenthesis syntax to access repeating values from a message will return all of the entries in the repeating segment as a *delimited string, and you can then check the string contains the - character using the contains function.

*Do make sure that the delimiter isn't the character you're looking for. Maybe throw in a trace when you first test this and check how it's returned.

Hey Michael.

A good use of a lookup table would be when working with an integration between two systems that use differing codes for the same values.

For example, you could have System A that records Sex as 1 for Male, 2 for Female, 0 for Not Known, and 9 for Not Specified, whereas System B uses M for Male, F for Female, and O for Other.

You could have a winding If/Else in a transform, or you could simply reference a lookup table in your DTL using the ..Lookup() function:

and then build up your lookup table to look like this:

As you can see, System A has more values than System B so the values for Not Known and Not Specified are being added as Other in my example.

Another example could be you needed to filter messages in a router based on a code within the HL7 message. You could add the codes to a lookup table as the key and a description as the value, and then use the Exists() function within your routing rule:

Which becomes:

Hey Jon.

One option could be to change the permissions for the source directory to be read only for the account running Ensemble/Healthshare? This way, the adapter will copy the file from the directory but will then be unable to delete it from the directory, while also keeping track of what files it has copied.

The log for the passthrough service will be a bit messy at first. but you'll end up with something like:

However, if the directory you're going to be checking for documents will be an ever growing list of a large number of documents, then your own suggestion of copying the files into a secondary working directory before being picked up by ensemble might actually be the best option as there's a bit of an overhead for the adapter when it's scanning a directory that contains a large number of files.

Depending on how soon after the files creation you need it for onward processing, you could create a scheduled task that copies all files from the previous day into your working directory and then sends an email if that fails for any reason?

It's great to see that there's a built in macro for this!

StackOverflow suggests using svglib and reportlab to achieve this with python:

from svglib.svglib import svg2rlg
from reportlab.graphics import renderPM
drawing = svg2rlg("my.svg")
renderPM.drawToFile(drawing, "my.png", fmt="PNG")

Oooh, I like this way more than my approach!

I would recommend approaching this in three parts:

1. Create a custom message class for your target system.
2. Use a DTL to transform your HL7 into your custom message class
3. Use a custom File Operation to write the file output based on your custom message class

For #1, this could be as basic as:

Class Demo.Messages.SystemX.CustomBody Extends Ens.Request
{

Property Param1 As %String;

Property Param2 As %String;

Property Param3 As %String;

Property Etc As %String;

}

For #2, your transform would then be something like:

And then for #3, your file operation would be something along the lines of:

Class Demo.Operations.SystemX.FileWriter Extends Ens.BusinessOperation
{

Parameter ADAPTER = "EnsLib.File.OutboundAdapter";

Property Adapter As EnsLib.File.OutboundAdapter;

Parameter INVOCATION = "Queue";

Method OnMessage(pRequest As Demo.Messages.SystemX.CustomBody, Output pResponse As Ens.Response) As %Status
{

	Set Line1 = pRequest.Param1_"|"pRequest.Param2
	Set Line2 = pRequest.Param3_"|"pRequest.Param4
	Set Line3 = pRequest.Param5_"|"pRequest.Param6
	Set outString = Line1_$C(13)_$C(10)_Line2_$C(13)_$C(10)_Line3_$C(13)_$C(10)
	
	Set fileName = "Filename"
	Set sc = ..Adapter.PutString(fileName_".dat",outString)
	Quit sc
}

}

Please note that the above is a super rough draft - there's no error handling, and you'd need to consider how you'd make the filename unique per message, but I'm hoping this gets you on the right path.