Hi Stephen, this is a valid approach however you will lose information about problematic calls such as json can't be parsed or API key in headers is wrong. I prefer to actually save the http call in full as http generic message and then call a process or operation with transformation to the proper message format, as Alex demonstrated in his third example. You can still call operation manually if you want, passing the parsed message. 

Hi Bob,

That's good news and I like new names much more than old ones. I hope old tags for old releases will still be available?

A couple of entries from my container tagging wishlist (one can dream, you know)

- provide :latest tag for all containers, but especially for community ones, which will just pull the latest working release without having to rebuild dockerfiles every year when license expires

- provide 2023.1.x tag which will follow the latest minor version

Hi Phillip,

In TrakCare, interoperability is controlled by TrakCare Health Messaging Framework (HMF). Each Interface has to go through HMF Gateway, which is an IRIS Production, and then all those are getting routed through HMF Router which is a separate IRIS production. Please have a look at HMF documentation for more details. A lot of this code is auto-generated so you need to understand what needs to be configured in TrakCare and what needs to be configured in Production.

Well first of all there is a first-class support for FHIR data in IRIS for Health and I would definitely recommend to use it instead of rolling out your own class-based solution. See documentation here https://docs.intersystems.com/irisforhealth20221/csp/docbook/Doc.View.cl...

If you want to work with projections, given that even basic data fields in FHIR are quite complex https://www.hl7.org/fhir/datatypes.html#primitive you'll need to define separate embedded classes for each data type; it doesn't have to be a separate class for each field.