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.

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..

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.

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

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

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.

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.

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

Hi Conor,

The FHIR Gateway as well as the associated setup methods including OAuthServer() are Information Exchange features and not available in Health Connect. The FHIR Repository which is a Health Connect component can be used as a building block to create your own FHIR based solutions but it requires some assembly, including the authentication components. If you need some help on working with the OAuth capabilities of Caché/Health Connect, please refer to the documentation and contact your Sales Engineer or WRC for assistance. 

 

Regards,
Matt Spielman
Product Manager, Information Exchange

Correct, out of the box HealthConnect's FHIR server doesn't offer any post-processing of Subscription resources. This is something we will offer in the future as the solution matures however, it is still possible to hook into the existing FHIR server to build a subscription processing engine. You are not the first person to ask about this and we are working on a  quick write-up on where/how to implement that processing.

Matthew Spielman, Product Manager
HealthShare Information Exchange, Personal Community
InterSystems Corporation

Hi Scott, you are already an Information Exchange customer; this is the core HIE product used by MHC. The Clinical Viewer is a feature of the Information Exchange product. Health Insight utilizes DeepSee but also has a number of pre-built analytics cubes and has a lot of special functionality to automate the ETL of data from Information Exchange. 

Health Connect, App Server, and Provider Directory are stand-alone products although Provider Directory will be able to integrate more tightly with Information Exchange in a future release. Personal Community and Health Insight require Information Exchange.

If you have more detailed questions about any of the products or would like to arrange a demo, please reach out to your account team and they will be happy to help you.

Hi Leonardo,

That's a great question and I'm happy to answer it for you. 

As many of our long-time customers are aware, Ensemble predates HealthShare by several years. Ensemble gained popularity in the healthcare market, in large part, because of its capabilities around the HL7 V2 standard, DICOM, X12, etc. 

Initially, HealthShare was a single product targeted to customers establishing Health Information Exchange infrastructures. As the capabilities of the solution grew over time, HealthShare changed from a single product to a family of solutions under the HealthShare name. In the process of developing these solutions, we had to add a lot of support for more modern interoperability standards such as HL7 CDA, CCDA, IHE Profiles, and HL7 FHIR. Those features and the underlying frameworks they rely on are only present in HealthShare solutions and are not available in Ensemble. Other healthcare specific features were also added to the platform to increase the value of the offering to our healthcare customers. The currently available products in the HealthShare platform are:

  • HealthConnect - Healthcare integration solution
  • AppServer - Connected healthcare application development platform
  • Information Exchange - Health Information Exchange platform
  • Patient Index - Master Patient Index
  • Health Insight - Data analytics and population health tools
  • Personal Community - Patient Portal
  • Provider Directory - Healthcare provider and organization directory (Coming in 2017)

If you are a new customer in the healthcare vertical, you will be looking at one of the HealthShare solutions listed above and not Ensemble.

HealthShare products are built on top of Caché and Ensemble and HealthShare inherits the capabilities of those products. However, there are some differences in licensing and appropriate use between Caché/Ensemble and HealthShare. I will not get into those details in this post but your account team can help to clarify those details for you. 

If you are an existing Ensemble customer, the HealthShare analog to your current product will be either HealthConnect or AppServer depending on your use case. Some Ensemble customers have migrated to HealthShare; if you have any questions about this, please contact your InterSystems account team for further details. 
 

Matthew Spielman
Senior Product Manager, HealthShare
One Memorial Drive
Cambridge, MA 02142-1358
United States

Hi Amit, typically the error you're seeing comes from a wrong endpoint being used. There are usually two ways the endpoint can be wrong:

1) Pointing something like a document source actor to a registry endpoint (instead of repository) for a provide and register document transaction. That can give you a SOAPACTION error.

2) You reinstalled or upgraded to a newer version which now uses /services for SOAP endpoints. So for example, if you had a Repository endpoint which used to be https://<server>/csp/healthshare/hsrepository/HS.IHE.XDSb.Repository.Services.cls, it should now be https://<server>/csp/healthshare/hsrepository/services/HS.IHE.XDSb.Repository.Services.cls

Hi Scott,

It really depends on the analysis you're trying to do. If you want to analyze structure; my tool of choice is Oxygen XML Editor with the CDA R2 schemas loaded in for structure validation; you can do the same with Altova XMLSpy and other similar products. If you want to do semantic validation; really the only tools that come close to that are the validators like NIST, Lantana, etc. but those barely scratch the surface.

Semantic validation of CDA documents is one of the more challenging aspects of the standard.

Hi John, can you please provide details on the version of HealthShare kit you are using? I just set up a new HealthShare instance and created a HS enabled namespace and do not see any Test.* package, global, or routine maps. I also checked back on a couple VMs with older instances and don't see any.

Matthew Spielman, Product Manager
HealthShare Information Exchange, Personal Community
InterSystems Corporation

Hi Andy,

We are working on a maintenance release of HealthShare (Version 14.02) that is based on Ensemble 2016.1. We expect it to be released approximately 1 - 2 weeks after the release of Ensemble 2016.1.

Additionally, the next major release of HealthShare (Version 15) planned for Q2 will also be based on Ensemble 2016.1. 

Regards,

Matthew Spielman, Product Manager
HealthShare Information Exchange, Personal Community
InterSystems Corporation