[Kyley Jex]

By changing the ‘Retries’ value from -1 (unlimited), I’m now able to ERROR the message from the UPOC protocol.

[Kyley Jex]

It is helpful to know that 1) difference between erroring in pre-proc vs. xlate and 2) that your practice is to not error from translate.

I assume that this is the same for post-proc?  Also, is the post-proc message the inbound message or the output of the xlate?

[Kyley Jex]

How is that different than validating and setting the USERDATA in a pre proc?

[Kyley Jex]

Thanks for the explanation.

If what you describe is true, then what is the value of xpmmetaset?  So if you error the message, it sounds as if none of the metadata will ever be attached to the message.  That seems to be a defect.

What is the process to submit a defect in the xpm api?  I would like to see this functionality in the next release.

I understand that a possible work around would be to handle the validation of the message as either a pre/post proc to the xlate — but then all validation/error reporting has to be a proc and not easily done within the xlate (non-programmers will be creating xlate).

[Kyley Jex]

After a little thought, I’ve put together a very easy solution that I believe will work for us.  I’m welcome to any comments or suggestions.

What does “black box” mean?  For my purposes, it means that there is a separation of default configuration files from the site-specific configuration files.  Additionally, from installation it means that each set of files can be downloaded/installed/updated independently (Cloverleaf Engine, default config., site-specific config).

Within Cloverleaf I’ve configured two sites: client, default.  The client site contains a stripped-down configuration that can be modified at each site.  This configuration receives the HL7 message from the document systems and translates/routes the HL7 messages to the default site based on site-specific needs.  The default site (set as the master site) contains the default configurations for the interface.  This configuration provides the default translations/routing of the HL7 messages to all other threads — and would be the same at all clients.  Because the Cloverleaf Engine manages each site within their own directory, site configurations are separated and can be installed/updated independently of each other.

For new installations, after the Cloverleaf Engine/Client is installed, the client and default sites will be initialized.  When performing an update, the default site will be updated with the latest default configuration while the client site will not be modified.  So, from the standpoint of the installer: 1) install Cloverleaf  2) initialize default site  3) if client doesn’t exist then initialize 3mhis_client site.  If any site-specific changes need to be made to the translation of the HL7 message, it is done within the client site which is completely separate from the default site configuration files.

I believe this is a very simple design and provides the ability to use the Cloverleaf Client tools to define the site-specific changes, while separating it from the product default configurations.

[Kyley Jex]

Thank you for your responses, it has been helpful to understand more about the XPM architecture and API.  However, I’m still unable to set the user data for the error that I’m generating.

The error does get generated in the Error DB with “msgState: Tcl callout abort (303)”, but the msgUserData is not set.  Here is the latest Tcl that I’m using:

Code:

lassign $xlateInVals input_1
set tvalue [tbllookup 0004.tbl $input_1]
if {[string equal $tvalue “”]} {
   set errMsg “$input_1 is invalid for Patient Class”
   xpmmetaset $xlateId USERDATA $errMsg
   xpmerror $xlateId action “action error $errMsg”
} else {
   set xlateOutVals [list $tvalue]
}

Is what I’m trying to do generally a good practice?  or would this be better handled some other way?

[Kyley Jex]

How do I get the message handle ($mh) in the Tcl Pre Proc for the COPY action?  I realize that if the Tcl is in a file as a function, then I can use:

Code:

keylget args MSGID mh

… but if it’s just within the COPY Action Pre Proc can it be done?

[Kyley Jex]

Apparently, a Message is not allowed to be created within an protocol write TPS.  Doing so resulted in the following Error (Message ignored – cannot create messages inside protocol write TPS).

Therefore, I resolved to replacing the data within the original message.  So now I create the Hl7M from the Message, get the Observation Value (OBX-5), convert RTF to TXT, search for index of the data within the original message content, and simply replace it.

Code:

msg.setContent(txtData, index, rtfData.length());

This works, but is this the correct way?

[Kyley Jex]

Thank you for your responses.

Jim, with what you prescribed, is it appropriate to delay the ACK until after the xlate–to ensure that all the proper fields are populated?  Or would that be checking for data content?  If so, is the generating of the ACK always done from the xlate(proc call) rather than from the TPS Inbound Data?

[Author]

Replies