The 2016.1 release of Corepoint Integration Engine  includes some high-profile enhancements. This latest edition adds support for utilizing a remote database for queuing and logging, enhances the native web service functionality to also support RESTful interfaces, and introduces an easy method for staging an off-site standby engine instance through the Disaster Recovery option.
Having been involved with the development process for this release, I can say confidently that each of these features was no small feat and was the culmination of collaborative efforts that required input from every department in our company, in addition to the feedback we had received from users on the enhancements they would like to see.
Another such enhancement that underwent numerous rounds of discussions and gradual improvements is one that, for many users, may have flown under the radar in this release, despite the fact that it affects one of the most often used parts of the engine. This new functionality has been grouped together as “Editing Action List Enhancements.”
One feature that falls in this category was the source for some very lengthy planning conversations, which actually led to additional improvements in other areas. The release notes for 2016.1 mention that “action list actions are now pre-populated with default operand values, based upon previously defined actions in the same action list.” Internally, we refer to this functionality as being a form of “heuristics” – rather than simply storing the last path you may have seen, the editor now has the capability to scan through what is already present in the action list to pre-populate the next action.
For example, if a user’s last action involved hardcoding a value into a particular HL7 is a Standards Developing Organization accredited by the American National Standards Institute (ANSI) to author consensus-based standards representing a board view from healthcare system stakeholders. HL7 has compiled a collection of message form... message handle, the next action added will automatically start up with the last message handle and the last HL7 path used. The editor will also assume that the user may again want to hardcode a value and set the source tab to a literal value. In many cases, this will help users more quickly insert correct values and move on to the next action. However, if the user decides to switch the source tab to indicate a path from another message handle, the editor will quickly perform a scan to determine the last path used as a source operand and jump to that spot.
All of this quickly happens behind the scenes any time a new action is added and is aware of its position within the action list.
Use case: suppose a user is in the middle of manipulating values in the PID segment of an ADT message when they realize steps were missed when working on the MSH segment. If the user jumps back to that portion of the action list and adds in another ItemCopy, the editor no longer jumps to the PID segment and, instead, realizes that this action is being added in a section dealing with the MSH segment. Therefore, it will be pre-populated with paths and values that correspond to the prior actions in that section.
We are constantly striving to improve the user experience within the engine and hope that, along with the rest of the enhancements introduced in the action list editor, this latest release will help to streamline and improve the efficiency of the action list building process.
If you haven’t already, I encourage customers to grab the latest version and try out these features for yourself. As always, we welcome any feedback that you may have. And, if you feel there is something missing that would help us improve the product, we want to hear what you have to say!