This is a little messy and I'm going to report part of the answer as a bug internally. But regardless, here's one way to make it work - in short, have all of the things that could be listed as a recipient extend a common parent class, and in that class override %JSONNew to detect which type it is.

Class DC.Demo.Container Extends (%RegisteredObject, %JSON.Adaptor)
{
Property recipient As DC.Demo.Recipient;
ClassMethod Demo()
{
    for json = {"recipient":{"dob":"2021-06-10"}}, {"recipient":{"reference":"foo"}} {
        set inst = ..%New()
        do inst.%JSONImport(json)
        write !,json.%ToJSON(),!,$classname(inst.recipient),!
    }
}
}

Class DC.Demo.Recipient Extends (%RegisteredObject, %JSON.Adaptor)
{
/// Get an instance of an JSON enabled class.<br><br>
/// 
/// You may override this method to do custom processing (such as initializing
/// the object instance) before returning an instance of this class.
/// However, this method should not be called directly from user code.<br>
/// Arguments:<br>
///     dynamicObject is the dynamic object with thee values to be assigned to the new object.<br>
///     containerOref is the containing object instance when called from JSONImport.
ClassMethod %JSONNew(dynamicObject As %DynamicObject, containerOref As %RegisteredObject = "") As %RegisteredObject
{
    // This is weird: shouldn't need to reference .recipient here
    if dynamicObject.recipient.%IsDefined("dob") {
        quit ##class(DC.Demo.Patient).%New()
    } elseif dynamicObject.recipient.%IsDefined("reference") {
        quit ##class(DC.Demo.Reference).%New()
    } else {
        quit ..%New()
    }
}
}

Class DC.Demo.Reference Extends DC.Demo.Recipient
{
Property reference As %String;
}

Class DC.Demo.Patient Extends DC.Demo.Recipient
{
Property dob As %Date;
}

Output is:

 d ##class(DC.Demo.Container).Demo()
{"recipient":{"dob":"2021-06-10"}}
DC.Demo.Patient
{"recipient":{"reference":"foo"}}
DC.Demo.Reference

Only problem is, %JSONNew (as advertised in class reference documentation) should get the %DynamicObject representing the object itself, not the parent %DynamicObject. This would only really work if each type is used in exactly one context like this, which seems unlikely.

First off, it's generally best to avoid xecute. ;)

In the first case, routine is private (it isn't visible in the xecute stack frame). In the second, it's public, so it is visible there.

You could get the best of both worlds with:

ClassMethod Run()
{
   set routine="variable"
   set call="(routine) write routine,!"
   xecute (call, routine)
   quit
}

For more info see https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...

Perhaps pass the object ID into something like:

Query GetInfo(refId As %String) As %SQLQuery(CONTAINID = 1, ROWSPEC = "IdList:%String,IdProcess:%String,Duration:%String")
{
    SELECT list.IdList, list.IdProcess, list.Duration
    FROM Kurro.MyClass list
    JOIN Kurro.MyClass ref on ref.ID = :refId
    AND ref.KeyProcess = list.KeyProcess
    AND ref.CodeSpecialist = list.CodeSpecialist
    AND ref.CodeProvider = list.CodeProvider
    AND ref.CodeCenter = list.CodeCenter
    AND ref.Date = list.Date
}

With what we've done the syntax ends up looking like:

Class DC.Demo.Hierarchy Extends %Persistent [ MemberSuper = AppS.Index.Methods ]
{

Property message As %String;

Property login As %String;

Property parentId As DC.Demo.Hierarchy [ SqlFieldName = parent_id ];

Index parentId On parentId [ Type = bitmap ];

ClassMethod RunDemo()
{
    Do ..%KillExtent()
    &sql(insert into DC_Demo.Hierarchy (message, login, parent_id)
        values ('Bacon ipsum dolor amet pork shoulder ribs', 'User 1', null))
    &sql(insert into DC_Demo.Hierarchy (message, login, parent_id)
        values ('BGouda croque monsieur emmental.', 'User 2', 1))
    &sql(insert into DC_Demo.Hierarchy (message, login, parent_id)
        values ('Manchego fromage frais airedale', 'User 3', 2))
        
    Do ##class(%SQL.Statement).%ExecDirect(,
        "select id, message, parent_id from DC_Demo.Hierarchy "_
        "where id %FIND DC_Demo.Hierarchy_parentIdFind(2,'all descendants')").%Display()
        
    Do ##class(%SQL.Statement).%ExecDirect(,
        "select id, message, parent_id from DC_Demo.Hierarchy "_
        "where id %FIND DC_Demo.Hierarchy_parentIdFind(3,'all related')").%Display()
}

}

Because there's a self-referencing property with a bitmap index, the hierarchy support is automatic via the MemberSuper class. Output is:

d ##class(DC.Demo.Hierarchy).RunDemo()
ID    message    parent_id
2    BGouda croque monsieur emmental.    1
3    Manchego fromage frais airedale    2

2 Rows(s) Affected

ID    message    parent_id
1    Bacon ipsum dolor amet pork shoulder ribs    
2    BGouda croque monsieur emmental.    1
3    Manchego fromage frais airedale    2

3 Rows(s) Affected

There's nothing built-in for this, but you can simulate it via custom class queries or %SQL.AbstractFind. I have an implementation of %SQL.AbstractFind/%Library.FunctionalIndex that does some things with hierarchies but falls short of the capabilities you linked in the Oracle doc. Specifically, it can find all ancestors/descendants/both (the whole tree) in a hierarchy efficiently, but it doesn't follow the same rules around ordering and won't let you do paths and such. (I'd want to clean it up a good deal before sharing, but that's probably worthwhile at some point.)

@Daniel Bertozzi , following up - I downloaded ImageMagick and the following works just fine for me (though I'm a little surprised at how slow it is):

Class DC.Demo.ImageMagick
{

ClassMethod Convert(inFile As %String = "C:\Temp\ImageMagick\inFile.jpg", outFile As %String = "C:\Temp\ImageMagick\outFile.jpg")
{
    Do $zf(-100,"","magick",inFile,"-resize","640x480",outFile)
}

}

I think the likely issue is that ImageMagick isn't on your PATH. You'll need to restart your instance for it to pick up PATH changes, so this might be the root cause if you just installed ImageMagick. Could also be interesting to run with the /SHELL flag and see if that works.

Hopefully this helps!