You need ODS in order to use FHIR with Information Exchange.  However, the storage impact can be minimized by using the production settings in ODS, so that data is only placed in ODS when requested, and gets purged after it is no longer being fetched.

Please check the user documentation, at (in my instance):

http://localhost:57776/csp/docbook/DocBook.UI.Page.cls?KEY=HETRM_ch_gend...

You can just search for the word "gender"

We try to not operate on an entire container, since containers can be arbitrarily large.  The API that you are using is one that should be combined with GetNextSDA, to process one streamlet at a time.

In the registry menu, select reports - run management reports.  There are a number of reports that can answer this question, such as the clinical data access report.

Please look at class HS.SDA3.Encounter, property HealthCareFacility.  The class/property documentation provides details about where the data comes from, and where it goes in the viewer database.

Was there a question?  Yes, of course, Cache' supports methods to serialize and deserialize XML enabled objects.  However, those methods have to apply to all sorts of general XML structures, and as a result, are much less efficient than ones where we have a very known/constrained data model.  One specific case involves embedded serial objects - serializing these to XML will cause them to be instantiated in memory even if null.  In addition, SDA containers can be arbitrarily large - we have examples of 50-100mb size containers.  Depending on your partition size, attempting to deserialize an entire container can cause a <STORE> error.

There are a couple of API method that can be helpful here, in class HS.SDA3.Container:

1. ListStreamletIds - this can return a list of streamlet IDs (in the aggregation cache) corresponding to a patient in the viewer.

2. LoadSDAObject - this takes a streamlet ID and returns an instantiated SDA object.

These can be called from custom code within the viewer to populate UI elements on the fly.

Alternatively, in the access gateway production, HS.Gateway.Access.Manager has a NotificationOperation that gets called during key events as data gets loaded into the viewer cache.  The events are Initialize, Abort, WaitTimeout, FetchNotification, and FetchComplete.

There are no standard supported ways of loading data into a chart, however.

There's no mention of what message class is being used or what service is being used, so it's hard to determine how to answer your question.  In general, for messages that extend HS.Types.XMLMessage, HealthShare expects you to populate the ContentStream property.

Not the least bit inefficient.

• It's the minimum required to represent the data.
• Any other attempts to represent the data with this cardinality would heap on complexities and inefficiencies (nasty denormalizations).
• When considering efficiency, the general parameters are execution speed (and corresponding resource impact)  and storage utilization.  In Cache, even if we assumed a 1-1 cardinality (and we can't so this is all hypothetical), the space taken by having this is a child table is only slightly greater than embedding it in the parent row.  Storing the data only causes a single extra global set in an adjacent spot in the disk block, which is a negligible impact.  Because of the way the data is stored, the cost to query and fetch the data is virtually the same.  One could argue that having this in a child table is actually a bit more efficient for events where there are no documents (which may represent the vast majority of events).

Perhaps you are thinking about other SQL databases, with different performance characteristics?  Even with those other databases, denormalizing this sort of cardinality is usually something to avoid (although there are cases where denormalization can help efficiency).

The "documents" that you are finding with your query are not documents, but are SDA record requests.  If you are looking for retrievals of IHE documents from a document repository, the event type to use is "Retrieve Document Set".  You didn't mention what version of HealthShare you are running, but in recent versions, the ATNA repository has a relationship to a child table, HS_IHE_ATNA_Repository.Document, and you can join to that.  It has a RepositoryID and DocumentID property.