O3: Test Result Trees Driven by Concept Sets

Development
, ,
10

Doing this seems like it would strain the concept dictionary in the same way that, e.g., reference ranges do. In other words the actual panel-as-performed should probably still be an obs group and this is just a way for showing related obs.

Thanks for the outline @zacbutko!. I have a few persnickety comments on tihs:

  1. The GET would likely be against some URL like /obs/tree/ or maybe just /obstree/ not /concept, because ultimately what you’re getting back is really a tree of obs (tests) categorised according to their defining concepts (also /concept is already an endpoint in the REST API).
  2. I would name the url parameters patient and conceptSet. It may be better to allow conceptSet to take either a name or UUID.
  3. For API consistency, it’s probably best that we just map properties as we already do, so that, e.g., each Set is returned as a concept using either the standard ref view or a predefined custom view. You can see most of the properties, e.g., here. At the very least, it’s best if the attribute names are in line with existing attribute names (“display” for “name”, “conceptClass” for “class” where “conceptClass” is resolvable to an object if needed).
  4. For similar reasons, “tests” → “obs”. While the initial target for this is lab tests, this is actually a fairly generic feature to construct a tree structure of Obs built from nested concept sets, so it’s much more general than just tests.
  5. The results returned in the “obs” array should match our standard obs properties, so, e.g., what’s returned from here.
  6. Really, really needless, but “sub-sets” should probably be “subSets”.
  7. I’m a little confused on the distinction you’re trying to make between “values” and “attributes”. On the naming convention side of things: attributes have a specific meaning in the backend and Obs already have a property called value, so we might want names that are less ambiguous for those.

I’d imagine (for ease of developing the backend) we’d end up with something like this structure:

{
  "display": "Bloodwork",
  "concept": {
     // Bloodwork concept details
  },
  "obs": [],
  "subSets": [
     {
       "display": "Hematology",
       "concept": {
            // Hematology concept details
        },
        "obs": [],
        "subSets": [
           {
              "display": "Complete Blood Count",
              "concept": {
                 // CBC concept details
               },
               "obs": [
                  // this is just an array of standard obs ordered according to concepts
               ],
               "subSets": []
           }
        ]
     }
  ]
}

Does that seem acceptable?

2 Likes