Hey Ephraim.

You will see from looking at the classmethod being called that there is a start date parameter which was left blank by Michael so that it will export everything up to the end date.

In your case, you could do the following to fulfil your example:

##class(%SYS.Audit).Export("AuditExport.xml",,,"2022-03-01 00:00:00","2022-04-11 23:59:59")

However this will only be useful to your specific date range, which is where Michaels use of $ZDT and $H come into play.

If you wanted to execute the task and have it return the last 30 days, you could do this:

##class(%SYS.Audit).Export("AuditExport.xml",,,$zdt($h-30,3)_" 00:00:00",$zdt($h,3)_" 23:59:59")

Hey Shamus. I do appreciate you replying, however I may not be being clear in my original question.

Even if I have the correct settings in the Business Service, if the content format is one that conflicts with UTF-8, the display within the management portal will show as per my examples because the browser is trying to display non UTF-8 content as UTF-8. My original question was asking how others work with this.

If you spot my second top-level comment, you will see that I had looked into using the browser to change the http content-type header, but that the major browsers no longer support such a feature.

I'm guessing my only option is to export a message and then review the content there.

Hey Shamus.

I'm back to eat some humble pie!

Turns out, I had confused myself early on and wrongly believed that Windows-1252/Latin1 were the same and I had my service set to Latin 1. This was then creating a scenario where I was digging myself into a hole of bad information.

In fact, they are almost the same except for the exact characters I was using in my example. These code points are used by Latin-1 as control codes, and when Windows-1252 is mislabeled as Latin-1 they get lost...

Thanks again for replying to my initial question and comments.

I have looked at how I can change the behavior of the browser, but it seems that the big 3 (well, two) no longer have this feature. Here is an article giving some back story.

Basically, Chrome used to have the option to manually overwrite the encoding type, but this was removed (however there are some 3rd party extensions out there to replace this feature, but I feel uncomfortable using random 3rd party extensions around healthcare data)

Firefox also used to have this feature, but they replaced it with a tool that attempts to repair the character encoding, however it didn't do a great job as it decided it was "IBM866" so the content looked like this:

Hey Leon.

The element of this issue that is perplexing me is that there is a difference between the RAW and Full view.

Could you try sending a sample message to a HL7 File operation with the charset set to UTF-8? I'm curious to know if the characters display as expected, stay as the ANSI character, or become something else.

I am wondering if the ANSI displaying in just the Full message viewer is contained to just the display of the full message, and any issues you are seeing in a destination system are a separate but similar issue with character encoding.