Hi Akshay,

this functionality was teased at Virtual Summit but is not released yet. Also, this will be an IRIS for Health feature, as the DTL Generator works on inbound and outbound pairs of HL7 messages.



Hi Duncan,

great to hear that you find the community edition beneficial! We are currently working on making the IRIS for Health Community Edition available on the docker store as well. I can't give you an exact time window, but it shouldn't be too far away. Stay tuned, it will be announced on the developer community when it is available.

As Sylvain has pointed out, you can always pull the images from the WRC Distribution page if you are a registered partner. The offerings on AWS, Azure or GCP can still be helpful with zero cost, as you often get a voucher when you sign-up for a new account. Enough for playing around for sure.



You have various options, depending on what you want to achieve:

  1. Added a property of type %DynamicObject or %DynamicArray to a persistent class
  2. Store the JSON content in the Document Data Model
  3. Parse a JSON structure as Eduard indicated and generate the corresponding persistent class(es).
  4. I would not advise to use %Document.Object. Use the Document Model instead.

With option 1) and 2) you don't need to define a schema at all, but can easily persist and manage your JSON content as objects. No SQL access to individual properties of the JSON content for option 1). With the document data model you can add support for SQL queries for individual JSON paths.

Option 3) is work, but doable. Figuring out the correct datatypes will be the greatest challenge. If you have JSON schema instead, your life is much simpler. 

Hi Tim,

$compose works with deep structures but it replaces values of key-value pairs at the top level. It does not merge sub-arrays or sub-objects by default. Consider the following code:

SAMPLES>set o1 = {"a":1,"c":2,"deep":{"f":1,"g":1}}
SAMPLES>set o2 = {"b":1,"c":1,"deep":{"f":3,"j":1}}
SAMPLES>s o3 = o2.$compose({"returnValue":o1})
SAMPLES>w o3.$toJSON()

You can easily spot, that the path "deep" in o3 has the value from o2 and completely misses "deep.g" from o1. We just copied the path "deep" from o2 into o1. We do provide a way  to override this behavior if you want to, but in a future release, we plan to ease this by introducing compose maps. I will cover this topic in more detail in an upcoming post.