New post
AllAccepted answers
Jeffrey Drumm · Oct 20, 2017

For your testing purposes, are you looking to simply examine the output of the transformation or do you need to have the message continue to its destination?

You can select messages by Header ID or Body ID for transformation via the Ensemble / Interoperate / HL7 v2.x / HL7 v2.x Message Viewer facility and examine the transformed output in HTML-ized form.

Alternately, you can execute the DTL in the terminal against a message object you've opened by Body ID and write the output to a file for viewing in an external application:

ISYSDEV>set imsg=##class(EnsLib.HL7.Message).%OpenId(1668896)
ISYSDEV>set sc=##class(RegADT.ADTtoCMSDtl).Transform(imsg,.omsg)
ISYSDEV>do omsg.OutputToFile("/home/jdrumm/tmp/zzzfile.hl7")

This doesn't have the effect of releasing anything from the queue; the messages are all still there waiting to be processed by the BP.

Jeffrey Drumm · Aug 23, 2017

So, assuming you've defined the context variables on the Context tab of the BPL, they're visible/accessible as objects with DTL called from the BPL, just like variables you define within the DTL. You can treat them just like any other variable of the defined Type:

 

Given the example from the screenshot, you can reference cvisCurrMessage as context.cvisCurrMessage within the DTL and use any methods or properties associated with its class. context.cvisCurrMessage.GetValueAt("MSH:10"), for example, returns the value of the MSH:10 field of the HL7 message referenced by context.cvisCurrMessage.

The one thing you have to be very careful about is synchronous vs. asynchronous calls to operations. You can't be guaranteed that the response object will be populated in a timely fashion when invoking the operation asynchronously, and sometimes even synchronously if you're using the BPL <call> object. You'll want to invoke the operation via the process.SendRequestSync() method in a <code> object to keep things sequenced properly.

Does that help? (if yes, please mark this response as your answer :D)

Jeffrey Drumm · Aug 22, 2017

I need to spend more time thinking about what you're trying to accomplish, but this comment specifically caught my eye:

As far as I know it is not possible to use the context of a process as input for a data transformation. If I am wrong i'd like to know.

Context variables defined within the process are available to DTLs invoked within the BPL. And you can of course use context variables to reference objects and pass them to DTLs as source or target objects. Not sure that this is what you were getting at, though.

Jeffrey Drumm · Aug 21, 2017

I like this idea; it's probably easier to implement than some other solutions.

I also think that a "Please Read: Community Etiquette" link on the main page might increase followup participation.

That said, I believe that part of the problem may  be that this is a vendor-hosted community forum rather than independent; I suspect many users may view this as "WRC-lite" and have a sense of entitlement based on their ongoing financial commitment to ISC.

I co-moderated the STC-User mailing list for many years, which had some 1600 subscribers (the group was focused on a succession of integration products from STC/SeeBeyond/Sun Microsystems/Oracle). It was completely user moderated and hosted, and while we had no formal "solution accepted" or "like" feedback mechanism, there seemed to be a stronger sense of community among a greater proportion of its members. Very few questions went unanswered, and few answers went un-thanked. Of course, my memories may be slightly rose-colored by my optimistic nostalgia filter :D

It could just be a matter of the relative newness of the DC. STC-User was born in the late 90's, grew to its peak in the mid-to-late 00's, and started circling the drain in the early 10's. 

Jeffrey Drumm · Aug 2, 2017

Hi Scott,

What metadata are you referring to? Document properties such as Title, Author, Subject, Keywords, etc. or are you looking to actually extract patient data from formatted page elements?

It doesn't look like HealthShare has any built-in PDF parsing features, but there may be something developed by the community (if there is, I'm not aware of it, though). If it's the properties I mentioned above, though, they're normally stored near the end of the file and it's conceivable that you could scrape them out with COS. To do it right, though, I think you'd want to call an external utility to fetch it. The pdfinfo utility in xpdf does that pretty efficiently:

jdrumm@oobuntoo:/mnt/hgfs/DDownloads/Intersystems$ pdfinfo Sample.pdf 
Title:          Sample
Subject:        Just another pdf
Keywords:       test metadata cache fetching
Author:         Jeff Drumm
Creator:        PDFCreator Version 1.7.3
Producer:       GPL Ghostscript 9.10
CreationDate:   Wed Aug  2 07:32:38 2017

If you're looking to get data stored as formatted page elements, though, that's an entirely different challenge.

Jeffrey Drumm · Jul 27, 2017

The problem is that your syntax doesn't really describe  a property; it's shorthand that works in the routing rule and DTL editors.

Try, instead, set context.X = request.GetValueAt("MSH:9.2").

EDIT: Looking at the log you included, it appears as though you are using the correct syntax at some point. Is context.X defined as a %String in the BPL context variable definitions?

Jeffrey Drumm · Jul 17, 2017

It's not a character set problem, it's a malformed HL7 problem. If the vendor sending the message needs to include a carriage return character in the middle of a segment, they should be escaping it. 

If the vendor won't fix it, you're probably looking at overriding the inbound service's OnProcessInput() method to strip out \0x0D\0x0A sequences and replace them with something else. If they're in there for textual formatting purposes, you'll need to know what the target system expects for a line-break character sequence.

Jeffrey Drumm · Jul 17, 2017

Are you sure you're looking at the right task? I/O logs would normally be purged using Ens.Util.Tasks.Purge, which is also used to purge messages, alerts, and other production logging. Here's a task I created specifically for demonstration purposes. You won't find this in your scheduled task list by default. You may have another, similar task that someone may have set up in your environment, though:

 

Jeffrey Drumm · Jul 15, 2017

If you're working with messages coming in from an HL7 service, the doctype will likely already be set. I only set it in my example because I used the ImportFromFile() method, which does not automatically select a schema and DocType category.

The DocType essentially defines the message object's rules use for parsing the message, so without one, you won't really be able to do much with them.

You could do some basic parsing/counting with $PIECE and some loop constructs against the raw message, but that doesn't sound like a lot of fun ...