New post
AllAccepted answers
Jeffrey Drumm · Nov 5, 2017

Do you need to route the message based on criteria supplied in HL7 field values? Is any transformation required?

If the answer to both of those questions is "no," then you really don't need a router ... you can specify the operation(s) in the target config name field for the business service that receives the messages.

If you need to route, though, you'll want to disable BuildMap segment mapping error validation in the routing rule. That's enabled when using 1 as the validation selection. Try "d-m-z" instead, assuming you still want to validate that the messages have a DocType assigned.

Note that you won't be able to (easily) specify routing criteria based on fields in segments starting with the first segment that doesn't match the schema, or (again, easily) work with those segments in DTLs.

If flexibility and maintainability are a requirement, I'd recommend you go ahead and create a custom schema.

Jeffrey Drumm · Oct 25, 2017

There's a pretty good description of what needs to be done in the overview here. It describes, and offers examples of,  methods for composing and sending an email in a Business Operation based on this adapter. The primary decisions you'll need to make are whether it will be a simple text-based email vs. a multi-part message, what type of message object will trigger it, and the method to call for delivery when that message type is received.

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?