User Answers

Hi Cyriak, you do not need to generate the Aggregation Key, as that is done automatically when the Access Gateway fetches a patient's data.

I believe the simplest way for custom code running in the Viewer to get the Aggregation Key value would be to first get the ID of the patient object in the Viewer Cache from the CSP session:

Hi, with regard to your second question, if your property "CODE" is unique and indexed, ie, your class definition includes something like:

Index CodeIndex on CODE [Unique];

 Then there is a generated method you can use to open the object that has CODE=Xparameter:

set myObject = ##class(User.MyPersistentClass).CodeIndexOpen(Xparameter, concurrency, .sc)

For any unique index, the method name is always "[index-name]Open".  You can read more about auto-generated methods here:

How about saving the values of a, b, and c in whatever way makes sense given the context - global, PPG, %-var, %session, or have the method return them, and then also make them arguments to the method.  When calling the method again, check for them in whatever way they were saved, and if not found initialize them to "".

If you do find them, you might have to "rewind" each subscript by one to make sure you don't miss anything, which is easy to do with $ORDER:

set a = $ORDER(^data(a), -1)

Here's a routine I use to restart a particular host in the production:

Hi Krystian, are you referring to the "extension" property in the data model?  If so, then that is currently supported by FHIR repository in HealthShare.  Resources can be created in the repository with extensions and these will be saved.  I'm attaching an example of a patient resource that contains multiple extensions. Note that this is a DSTU2 resource, which is the FHIR version that HealthShare currently supports.  The current version of FHIR is STU3.  HealthShare will support this in a future release.

Hi Conor,

The issue is that HealthShare does not support CORS requests against FHIR endpoints that are secured with standard Caché authentication.  So if you look at the Network tab in your browser's developer tools, you'll see that before your browser sends the GET request to that URL, it sends an OPTIONS request to that same URL.  HealthShare responds with a 404, and what the browser actually complains about is the response missing some headers that are expected in a CORS response.

Hi Tom, can you describe how you created the FHIR namespace? Also, I'm pretty sure the version of HSCore you're using is 15.03, but could you also include the full version string, for future reference?

My guess is that you are trying to interact with a FHIR Gateway namespace, which does not support the create interaction from clients.

Hi Surya,

HealthShare has no single transform that can convert from HL7 to FHIR.  Rather, what you would do is, first convert the HL7 to an SDA3 container via the Ensemble operation HS.Gateway.HL7.InboundProcess, then convert the SDA3 container into a FHIR bundle via the process HS.FHIR.FromSDA.DTL.Transaction.Process.

Hi Scott,

One way you could do this is via an MDM^T02 HL7 message.  There is actually an example message containing a PDF document distributed with HealthShare: <install-directory>\Data\Scenario_4.hl7

The document data is encapsulated in a series of OBX segments:

OBX||ED|||^^PDF^Base64^JVBERi0xLjINCiXi48/TDQolICAgICAgICAgIA0KJTEwMDIzMFszMl0NCjEgMCBvYmogDTw8DQov

The critical pieces of this are:

OBX-2: Must be "ED" for "Encapsulated Data"