Definately would always recommend full commands.   I remember the day when we had to write code this way however it isn't the case anymore.

That said, it's good to be able to read code like this because it still exists out there.

This is referring to mapping between SDA and Health Insight cubes.

Please PM me so we can discuss your need further.   I am one of the Sales Engineers working with the VA.

Simply select the code to convert and then select Edit -> Advanced -

 And then either Expand or Compress  Commands.

I think full commands are much easier to read for those that might be coming into your organization and will be taking over development of your projects in the future.

It's pretty easy to convert from one to the other using the Expand and Compress commands option in Studio.

For those that might be visually impaired, it would be a lot easier to dictate expanded commands than abbreviated versions.

Just my 2 cents

Hi Richard-

I'm assuming you are working for or with VA as the build you mention is a specific build provided to the VA.  I don't believe that the FHIR annotations were released until version 2018.x of HealthShare.

If you can reach out to the VA sales engineers via email we'd be happy to get you a copy.

If you are running IRIS for Health

From the management portal, assuming you have a Foundation namespace created you can click Health -> <select foundation namespace> -> Schema Documentation -> FHIR Annotations

If you do not have a foundation namespace created, click

Health -> Install Wizard -> Configure Foundation

Enter the name for the Namespace, click Save and then click Activate

Once you have created a Foundation namespace you should be able to access the FHIR Annotations as mentioned above.

The same holds true for Health Connect instances as well, I believe.

ODS namespaces are applicable to HealthShare Unified Care Record instances and sounds like it's not applicable to your situation.


I'm not sure that you can.   From within a production you can call from one host to another, e.g. bs->bp, bs->bo, bp->bp, bp->bo, bo->bp, bo->bo, etc.

From outside the production you cant really call a bp or a bo directly.

Why do you not want to setup a bs that can route your call to whatever bp or bo you want?

From a business host you would use the ..SendRequestSync or ..SendRequestAsync method call.

From outside of a business host you could create a business service that took a target configname and a request message as input and use the CreateBusinessService method in End.Director to iinstanciate and call it 


With regard to the name, it's just that, a name.  It doesn't have any effect on what the production can and cant be used for.