In Studio's Tools menu, select Options, Environment, Documentation and Proxy. Check "Templates and add-ins will use Proxy server for <hostname>." Enter the address (including 'https://' if you're using SSL/TLS) and port number for your standalone web server. Click Apply.

You may have to re-authenticate each time you select a template, but at least you'll be able to get to them (and I'm sure there's a way around that too).

For checking the progress of deletion of older messages, just bring up the message viewer and set the Sort Order to Oldest First and the Time Format to Complete. Each time you click the Search button, you should see progressively "newer" messages as the older ones are purged.

So, putting it all together ...

NOTE: This is NOT production-ready code. There's no error handling or input validation. You get to add that stuff yourself :)

Class User.HL7.Operation.Email extends Ens.BusinessOperation {

Parameter ADAPTER = "EnsLib.EMail.OutboundAdapter";

Property Adapter As EnsLib.EMail.OutboundAdapter;

Parameter INVOCATION = "Queue";

Method SimpleMessage(pInput As EnsLib.HL7.Message, Output pOutput As Ens.Response) As %Status

{

    Set email=##class(%Net.MailMessage).%New()

    Set addr = pInput.GetValueAt("PID:13.4")

    Do email.To.Insert(addr)

    Set email.Subject="The subject of your message"

    Do email.TextData.Write("This is the body of your message.")

    Set tSc=..Adapter.SendMail(email)

    //send an empty response message after message is sent

    Set pOutput=##class(Ens.Response).%New()

    Quit $$$OK

}

XData MessageMap {

    <MapItem MessageType="EnsLib.HL7.Message">

        <Method>SimpleMessage</Method>

    </MapItem>

}

}

You specify the schema to use in the "Message Schema Category" field of the of the inbound Business Service's configuration.

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.

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)

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.