New post
AllAccepted answers
Matt Spielman · Feb 10, 2021

It is not 100% clear to me what is causing your problem but one issue with your code that I foresee is resiliency around image sizes. You are using a lot of string processing to handle images which is very risky. If your image file size exceeds the length of a string, you will run into <MAXSTRING> errors and other problems. Particularly since this isn't human-readable text that you will need to do things like $ZCVT or $REPLACE, I suggest refactoring your code to handle this data as streams.

Matt Spielman · Jan 7, 2021

Another option to consider is at the time the EQ edge gets the fetch request, do a synchronous PatientSearchRequest to the hub for the demographics of the patient. Then transform that data into SDA. Unfortunately, while there is an existing XSLT to go from SDA to a PatientSearchRequest (csp/xslt/SDA3/SDA-to-MPIUpdatePatient.xsl), there is not a transform the other direction so you will need to build something..

Matt Spielman · Nov 17, 2020

If you have a license key and a HealthShare Unified Care Record  kit, you can run "do ##class(HS.Util.Installer).InstallBusDemo()" in the HSLIB namespace which will lay down a fully functional demo environment.

Regarding Docker, please be aware that HealthShare Unified Care Record is not currently tested or certified for deployment in a Container and this is not a supported configuration in production environments. You may run into some issues using some of the more exotic features of the product in a Container.

Matt Spielman · Oct 21, 2020

Hi Stephen,

Unfortunately, I don't have an answer for you from a product perspective in terms of support for POCT01. However, generally speaking, if you're talking about receiving HL7 V3 XML over what would presumably be a HTTP connection, you should be able to do that in Health Connect or IRIS for Health without the need of any middleware. You would need to set up a HTTP service in a new production and any downstream business hosts needed to properly process the data and orchestrate any workflow.

The scenario I could imagine where specialty software would be needed is where there are regulatory or certification requirements around this protocol that cannot be met without extensive testing of a custom solution built 100% in Health Connect.

I hope that helps!

Regards,

Matt Spielman

Matt Spielman · Jul 22, 2020

Hi Bukhtiar,

I would like to also disambiguate a couple of terms to help in your planning processes. An Edge Gateway is a Namespace and Interoperability Production that lives on an instance of HealthShare. You can have multiple Edge Gateways on a single instance and this is actually recommended for both licensing costs and maintenance overhead. The decision to put an Edge Gateway on a new instance is usually driven by data volumes and that is definitely something the sizing tools can help with.

One thing I would recommend against is combining multiple facilities into a single Edge Gateway Namespace. While this is a perfectly passable solution from a technical perspective, it does mean that if you ever need to split those facilities onto separate instances in the future because of data growth, it will be very difficult. Also, if you ever have a need to remove a facility's data completely from HealthShare, it is much easy to do when that data is wholly self-contained on it's own Edge Namespace.

Regards,

Matt

Matt Spielman · Apr 19, 2018

Thanks for the clarifications!

I would suggest experimenting with a few things first:

  1. On your inbound FHIR Patient Query message, first try to see if the PDQm Services can successfully transform it into a HS.Message.Patient Search Request. If not, then I suggest using Ensemble DTL and transforming the HS.Message.FHIR.Request into a HS.Message.PatientSearchRequest
  2. Once you get #1 sorted, I suggest feeding your HS.Message.PatientSearchRequest message into the HS.IHE.PDQ2.Consumer.Operation and see if the vanilla operation is able to successfully negotiate the QBP-RSP interaction. If not, then you may need to either look at extending the operation or writing other additional code to pipeline the V2 message until the PAS can handle the query.

In both these cases, you shouldn't need to transform to SDA.

Matt Spielman · Apr 4, 2018

Hi Stephen,

I second Craig's comments re the format of your GET request.  Additionally, a little more detail about your use case would be helpful.

  • Is the QBP^Q21 actually an IHE PIX or PDQ query request or just a plain HL7 V2 QBP^Q21?
  • What is the workflow? If they are both queries, how are you translating one to another? What is the triggering event for this workflow?

A few extra things to consider:

  • You don't have to use SDA as an intermediary to translate HL7 V2 <--> FHIR. You can also do this directly using DTL which will likely perform faster (but may require some additional work to implement)
  • If the QBP is being sent to you instead of being sent by you, consider using the HS IHE PIX Supplier to transform the QBP into a HS.Message.PatientSearch Request message.
Matt Spielman · Sep 27, 2017

Without more detail on your specific use case, I am going to assume you already have either a standard SDA3 Container Object or you have a typical SDA Container as a Stream

First create a new FileCharacterStream:

  1. Create a new %Stream.FileCharacter Object (i.e. set tFileStream = ##class(%Stream.FileCharacter).%New())
  2. Next set tFileStream.Filename = "<your file name/path>". Ensure Cache has the proper privileges to write to the supplied file path.

If you have a HS.SDA3.Container Object:

  1. Assuming your container object is named, "tSDA", run: set tStatus = tSDA.ToQuickXMLStream(.tFileStream)
  2. Next Run: do tFileStream.%Save()

If you have a SDA3 Stream:

  1. Assuming your stream is named, "tSDAStream", run: do tFileStream.CopyFromAndSave(tSDAStream)

Regards,

Matt Spielman

Product Manager, HealthShare Information Exchange