Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-25474

Update GraphDefinition resource to allow it to describe a graph

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • R4
    • FHIR Infrastructure
    • GraphDefinition
    • 5.10.4
    • Hide

      We will not make the changes exactly as proposed (we need to keep some of the elements that were removed and aren't comfortable with some of the cardinalities & names).  However, we will revamp the structure to have a list of node definitions, a list of edge relationships between node definitions and an optional pointer to one of the node definitions as being the 'root' (needed by messages, documents and certain other cases).  

      Will also add in structures to allow constraining references to specific node instances

      Show
      We will not make the changes exactly as proposed (we need to keep some of the elements that were removed and aren't comfortable with some of the cardinalities & names).  However, we will revamp the structure to have a list of node definitions, a list of edge relationships between node definitions and an optional pointer to one of the node definitions as being the 'root' (needed by messages, documents and certain other cases).   Will also add in structures to allow constraining references to specific node instances
    • Rick Geimer/Grahame Grieve: 13-0-1
    • Correction
    • Non-compatible
    • R5

    Description

      The current R4 GraphDefinition doesn't allow one to refer back to a specific node instance when one defines a reference. Alignment with the graphML standard is proposed, defining a graph as a series of nodes and a series of links, which could have explicit identifiers.

      Proposal is to leave the 'meta/header' part of the GraphDefinition resource as-is, but to replace the actual definitional part as shown in the image attachment. This proposed solution also covers the use case of two node instances having the be the same, or two edges having to reference the same source node or destination node.

      Known issue not covered by this proposal: a node instance having to be explicitly different from another node instance.

      Additional descriptive wording will be required for the various data elements in this proposed model, I'm willing to lead the creation of those.

      (after the 2019 Amsterdam DevDays I created a similar issue to this one, but I'm not sure where it ended up as I'm unable to locate it).

      Attachments

        1. image-2020-01-15-16-04-13-296.png
          image-2020-01-15-16-04-13-296.png
          250 kB

        Activity

          People

            lloyd Lloyd McKenzie
            rene.spronk Rene Spronk
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: