FHIR Chat · Validating data with GraphDefinitions · implementers

Stream: implementers

Topic: Validating data with GraphDefinitions


view this post on Zulip Tadas Antanavicius (Dec 10 2020 at 20:07):

Hi,

I see that one of the intents of GraphDefinition is to "Document rules about the relationship between a set of resources". Lower in the documentation near the discussion about compartments, there is a note, "Todo: how would this be validated? - where is the graph referred to?".

This idea was noted here as well:

One of the usecases that came up was that we'd like GraphDefinition to be able to validate a tree of data, especially the linkage, since that's pretty hard to do otherwise.

Is this documentation up to date? Has there been any thought put into where you might invoke this kind of validation?

My use case is, roughly, that I have an application that creates/modifies FHIR resources for a user workflow. At the end of that workflow, the user clicks a button to generate a report based on the data in a graph of FHIR resources. Prior to producing this report, I want to validate that the graph of FHIR resources is in the expected state: starting at an Encounter that adheres to profile X, there exists a Patient with profile Y, an Account with profile Z, etc. I want to validate the cardinality and attached profiles of each of these linkages.

Does this use case make sense? It seems like I can effectively encode the information needed for my use case in GraphDefinitions. Is there an existing operation definition of some kind that does this kind of linkage traversal validation given a GraphDefinition, or am I on my own in implementing a usage of GraphDefinition in this manner?

Thanks!

view this post on Zulip Lloyd McKenzie (Dec 10 2020 at 20:09):

@Grahame Grieve

view this post on Zulip Tadas Antanavicius (Dec 10 2020 at 22:57):

I see in this presentation that it seems to suggest placing a reference to a GraphDefinition in Resource.meta.profile, which seems potentially in the direction of what I'm looking for. But Resource.meta.profile docs suggests that the value needs to be a StructureDefinition, not GraphDefinition.

view this post on Zulip René Spronk (Dec 11 2020 at 07:58):

GraphDefinition is still subject to discussion. During the last HL7 WGM a session was held to discuss how to move forward with it - but I haven't attended that session, so I'm unaware as to it outcome. Meta.profile is intended to also allow a reference to a GraphDefinition.

view this post on Zulip Grahame Grieve (Dec 18 2020 at 00:33):

catching up on this.

view this post on Zulip Grahame Grieve (Dec 18 2020 at 00:33):

I don't believe that this is true:

Meta.profile is intended to also allow a reference to a GraphDefinition.

view this post on Zulip Grahame Grieve (Dec 18 2020 at 00:33):

it would be good to fix the todo:

Todo: how would this be validated?

view this post on Zulip Grahame Grieve (Dec 18 2020 at 00:33):

and I think that the most logical way to do it would be

view this post on Zulip Grahame Grieve (Dec 18 2020 at 00:34):

GET [base]/Patient/example/$validate?graph=[graph]

view this post on Zulip Grahame Grieve (Dec 18 2020 at 00:35):

e.g start at the patient example and check that all the rules in the graph are met

view this post on Zulip René Spronk (Dec 18 2020 at 08:43):

During earlier discussions (in a different stream, probably a year ago) we concluded that profile could be used to reference a graphDefinition.

view this post on Zulip René Spronk (Dec 18 2020 at 08:44):

So what has been decided at the WGM re: the future of GraphDefinition ?


Last updated: Apr 12 2022 at 19:14 UTC