Binding code datatype to the corresponding valueset

1

Hi,
I’ve been looking for a simple guide to bind code datatype to the corresponding valueset.
Just the like the gender field for a patient and the corresponding AdministrativeGender valueset.

In my code I am using this function to generate a code field in the resource:-
...code({ name: 'gender', description: 'male | female | other | unknown', input }),
So If I do something like this:
...code({ name: 'gender', description: 'male | female | other | unknown', input, valueSet: 'administrative-gender' }),
and get the values for the code directly from the database, will that be considered Direct Value Set reference ? as per documentation here Terminologies

I’ve read the docs but I am really lost here I don’t know if I should use ElementDefinition, DataElement or StructureDefinition.
I was hoping to find a simple guide for doing this at the code element level only.

Regards,
Mostafa

2

You’ll need StructureDefinition which defines a profile on the resource. It, in turn, makes a reference to ElementDefinition which is where the actual binding occurs. The creation of StructureDefinitions is complicated, so I’d encourage you to look to a tool like Forge or Trifolia to do the authoring and then look at the output they produce to get a sense of what’s going on. You can also look at the various profiles defined in the FHIR IG itself. The key part will look like this:

"differential": {
  "element": [
    ...
    {
      "path": "Observation.code",
      "binding": {
        "strength": "required",
        "bindingReference": {
           "reference": "http://somewhere.org/fhir/ValueSet/myvaluesetid"
        }
      }
    }
    ...
  ]
}
1 Like
3

Thanks for your explanation, I think I have clearer understanding now of how to implement FHIR.
So, I’ve got a couple of points that I wish to discuss about the StructureDefinition resource.

I am taking a look at a patient profile here.
And according to my understanding StructureDefinition has two elements which contain a list of ElementDefinition

  • snapshot which is letterly as if it’s a snapshot of the resource definition by FHIR specs

    snapshot
    test.png817×1136 118 KB

  • differential

  • this is where my actual implementation of the resource for my specific use case takes place

  • this is what the user input should be validated against.

  • this what will be available at the server’s HTTP endpoint for this specific resource.

I know I am taking a look at a very small part of the FHIR specs, But according to the above my approach for creating my own FHIR server will be something like this :-

  • Have a folder where the StructureDefinition json files will be placed.
  • Then I will parse those json files to create the HTTP endpoints for the resources represented in them.

Please let me know what are your thoughts, I really can make use of some guidance here.

4

A few clarifications:

  • The differential represents what’s different between your constrained version of the resource and the parent resource or profile. So, for example, if the only difference between your version of Patient and the base Patient resource was that you wanted to change the cardinality of Patient.identifier, then your differential would contain only one element with a path of “Patient.identifier” and would assert a single constraint - min=1.
  • The snapshot represents all allowed elements once the differential is applied to the base resource. So it would exactly mirror the snapshot for the base Patient resource, with the exception that the “min” property of Patient.identifier would be “1” instead of “0”
  • It’s possible to have multiple StructureDefinition profiles for a single resource type - for example, you might have a profile for vital sign Observations, lab Observations and social history Observations. You’d still only have one Observation endpoint. So StructureDefinition don’t necessarily correspond to endpoints. However, you can use StructureDefinition instances to validate data that is posted to an endpoint

Hopefully that helps.

1 Like
5

Thanks, you’ve certainly been very helpful … it’s the first time I’ve been making progress in the infrastructure part of FHIR, and I’ve been able to understand the documentation better now.
So, one last question as regards this part

I’ve been trying to figure out how would I know which StructureDefinition my resource should validate against if there are multiple ones for the same HTTP endpoint.
Is it something like and extra parameter added specifying the StructureDefinition to validate against?

6

Well, there are a few possibilities. You could hope that the inbound instance declares one of the profiles you care about in the meta/profile element (meta gets inherited by all resources from Resource). That hope might be faint or non-existant or it may be near certainty depending on how much money you have to give to your communication partners and/or how much regulatory power you have. However, if the inbound data doesn’t declare a profile you recognize, then you either need to dig into the instance to find a piece of information that will help you figure out what profile is appropriate (e.g. look at the value in Observation.code and figure out what kind of Observation it is) or you need to validate against all of the profiles you support that apply to that particular resource type. In some cases you may try a mixture of both approaches - look up the Observation.code to whittle down the set of profiles that might apply, then validate against that smaller set of profiles.

1 Like
7

Thanks for your guidance, I’ve just finished creating a parser that generates both GraphQL and Mongoose Schema from a Structure Definition json file in my project.
You can take a look at my project here.
It can’t be considered a FHIR implementation because it’s using GraphQL instead of REST but I went with GraphQL anyway because I believe it’s better.

8

Keep in mind that the objective of having a “standard” is to create interoperability between systems without site-specific agreements. It’s almost always possible to come up with a “better” solution for a particular constrained problem space. However, each “better” solution will also be different, which significantly increases overall costs for everyone. There’s nothing to stop people from using FHIR structures however they like, but I’d strongly encourage systems to consider supporting the “standard” way of doing things in addition to any custom solution to maximize chanses for interoperability.

1 Like