Hi Cyriak, the HS_SDA3_Streamlet.Abstract table is used on *both* the Edge *and* the Access Gateway.  When a patient's data is fetched on the Access Gateway, it is stored in this table temporarily, until the CSP session that initiated the fetch has ended, plus however long it takes for the session cleanup process to fire (usually a few minutes).  So once you've loaded a patient's record into the Viewer and you have their Aggregation Key, you can use that to query for their data on the Access Gateway.

I tried to use one of the "GetStored" methods of %Dictionary.MethodDefinition (specifically, "DescriptionGetStored") and got a "<METHOD DOES NOT EXIST>" error.  I suspect this is because this class has "StorageStrategy=custom".  So if a class specifies a custom storage definition, does that mean these methods won't be auto-generated?

How is the client report being generated?  Would it be possible to implement this as a Zen Report?  That might allow you to embed the image in the report and specify its size within the report.

I tend to use "if" rather than postconditionals because it makes the code read more like spoken language, and I think it's easier to understand for those who are not seasoned Caché veterans.

However I make exceptions for "quit" and "continue":

quit:$$$ISERR(tSC)

continue:x'=y

I like to have these out in front, rather than buried in a line somewhere, so that when I'm scanning code I can easily see "this is where the execution will branch if a certain condition is met."

Hi Krystian,

I understand now, you mean you want to extend the FHIR data model, rather than use the "extension" property in the FHIR core spec.  Extending the data model is not something that is supported in the 15.03 release of HealthShare Core, but currently we are planning to support this in the next release.  However, even when this is supported, we will actually encourage users to use the "extension" property for simple extensions, rather than extending the data model.  This is a sentiment shared by much of the FHIR community, based on their collective experience with extensions.

Hi Tom, HealthShare provides transforms between FHIR and SDA (the format HealthShare Information Exchange uses to store and transport patient data internally), as well as Ensemble Business Processes that call into these transforms.  So if you wanted to feed FHIR data into Information Exchange, and your FHIR data were in patient-centric bundles, then one thing you could do is, implement a REST handler in a HealthShare Edge Gateway namespace that marshalls the FHIR request into an Ensemble request.  You can look at HS.FHIR.REST.Handler for an example of how to do this, but I would recommend against trying to use this class as your REST handler.  It does things that are specific to a FHIR namespace.  Have the REST handler dispatch the request to a service in the Edge production, which should pass the request on to HS.FHIR.ToSDA.DTL.Transaction.Process.  This will transform the FHIR bundle in an SDA container, which can be processed normally into the HealthShare Edge gateway.  Note that if you decide to do this, you are essentially creating a FHIR endpoint that is write-only.  The original FHIR resource cannot be read from that endpoint.  Though technically, it isn't really even a FHIR endpoint unless it can serve up a conformance statement.

You can read more about transforming between FHIR and SDA here:

http://host:port/csp/docbook/DocBook.UI.Page.cls?KEY=FOVW_fhir#FOVW_fhir...

In %SQL.StatementResult, do not use %Get to get columns by name, instead just reference the properties directly, e.g. 'Write resultOref.Name' instead of 'Write resultOref.%Get("Name")'

Just curious. What is the reason for this?