Hi Blake,

Can you provide a bit more detail? If you need to create an individual HL7 message for each repeating element in the XML document, my answer here is probably the easiest way to get there. If there's a "master/detail" relationship within the XML, though, you'll need to handle that in a BPL, and perhaps still "chunk" the XML before handing it off to the BPL if there are multiple elements with master/detail relationships. You'd do that with the XML Object file service mentioned in the link (assuming you're getting these XML documents as local files ... there's also an FTP version of the service).

There are tutorials on BPLs in ISC's Learning library.

I'm not finding any significant differences in the supporting classes between HS and I4H 2020.1. You might want to open an incident with the WRC to see why you're successful in I4H and not HS.

I'm also thinking that you might be better off developing your NACK logic in a BPL, though. Routing Rules aren't really designed for this sort of thing.

What versions of HealthShare are you running?

I guess that depends on what you want to do if you get an invalid date. Here's a method you can add to the class I referenced above:

ClassMethod IsValidBirthDate(pDate As %String) As %Boolean
{
    Try {
            Set tHDate = $ZDATEH(pDate)
    } Catch ex {
        Return 0
    }
    Return 1
}

And you'd use it something like this:

If you know that there will always be 8 characters at the position of the 2nd "*" character, you should be able to use this pattern instead:

TEST_PID*_NDCA_Drug_Utilization_????????_UD.txt
 

I'm pretty sure that System Default Settings would only solve this issue if you were already using it to "default" the original value for those interfaces. Had you done that, making the update would be a very simple change of one entry in SDS.

@Craig Regester's solution is probably the easiest to implement quickly, but it might also be an opportunity to move to an SDS-based configuration.

Thank you for the clarification. I'm in the middle of a Cache/Ensemble on SUSE -> IRIS for Health on RHEL migration  and would prefer to be at the latest available release prior to go-live. But I guess I am, per the release schedule.

Full kits will not be available for this release?

Would you like us to post feature requests here, on GitHub, or not at all? 

For example, I want to be able to go back and edit a previously entered line before execution ...

Did you try GetHostSettingValue()?  I'm working with 2018.1.2, but I'd be surprised if the API changed.

Hi Dmitriy,

UPDATE: Also posted as an issue to GitHub

Here's the layout in VS Code's Explorer:

The code-workspace file from the Workspace top-level directory:

Note that I've tried both manually creating the file and adding directories to the workspace using the VS Code menus. The only difference I can see in the result is that the json name value appears in the explorer tree rather than the actual directory name.

Hers's a .vscode\settings.json file from one of the directories referenced in the code-workspace file shown above:

The oddest symptom is that when I change just one of the settings.json files, all directories change to those value in the OBJECTSCRIPT:EXPLORER view (only the file I've actually edited and saved has the changes in it, though):

Thanks for looking into this.

PS.

Just in case it matters:

Version: 1.46.1 (user setup)
Commit: cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
Date: 2020-06-17T21:13:20.174Z
Electron: 7.3.1
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18362

Hi Dmitriy,

I've created the .code-workspace file up as you've described, with the "main" name/path and the "part" names/paths pointing to their respective subdirectories. Each subdirectory has it's own .vscode/settings.json file. However, when I go into Explorer, all of the workspace directories show connections to the same server, not the distinct ones defined for each workspace subdirectory.

There are no objectscript.* values defined in the main .code-workspace file or the .vscode/settings.json file in the root of the main workspace directory.

I'm obviously missing something, but I've tried a variety of options and I'm stuck.

Thanks!

InterSystems documentation states that this method should never be used in a live, deployed environment. It will remove all messages from queues, along with other state management data.

Link