· Dec 7, 2017

Anyone created an SDA external of HealthShare

Newbie question. So bear with me please.

We have a requirement to extract or build a file off of our local db to feed to HealthShare.

The requirement is for us to create the extract and send it to HealthShare the SDA format.

My initial thought is why would you do that when the SDA is native to HS.  We could create a file in any format csv,tab etc let HS consume it, convert it to HL7 2.5.1 and then let HS do the work with the SDA.

However, the current direction is for us to query, get the data and map it to an xml file built off of the SDA.

Has anyone taken this approach?

Thanks in advance,

Discussion (4)0
Log in or sign up to continue

I have used the  %XML.Writer class to create a document, but only for a fairly simple one that was destined for a SOAP outbound call. The SDA is tricky, so I would imagine using HealthShare (Ensemble) would be much easier. (I have used Ensemble classes like EnsLib.EDI.XML.Document that can be added to a message, etc. and used as the target for transformations once you have an appropriate document definition loaded in. Reduces the coding required, though not entirely as repeating groups are an issue.)


Hi Ed,

At J2 Interactive, we've done several direct SDA integrations into HealthShare that you describe. Your alternate approach of generating HL7v2 messages to send in to HealthShare will absolutely work. However, if your organization is committed to using HealthShare, it is worth the effort to learn the SDA XML structure since it is a core part of the technology. Additional benefits of the direct SDA approach include

  1. More control: you can populate any SDA field, including custom ones you define, without touching ISC code.
  2. Better stability: since you're not relying on ISC standard translations, you don't have to adjust your generated messages when that logic changes.
  3. Fewer Translations: less opportunities for the data to be changed slightly (e.g. like in a game of telephone)
  4. Easy Export from SDA: once the data is in HealthShare, you can leverage standard transformations that turn SDA into HL7v2 and other formats if you need to send the information to downstream systems that don't accept SDA.

Hope that helps,


Is this project a single conversion effort, or an ongoing transmission of data to HealthShare?  For a long-term process, I'd choose a standard data transmission format supported by HealthShare (HL7, CDA, FHIR).  That approach allows you to transmit the data to other systems.  SDA is proprietary; InterSystems can change it, leaving your organization with the need to adapt to the new structures to keep the data load process working.