Is Flag.category required for zib MedicationContraIndication, and if so, with what code?

[pieter-edelman-nictiz]

The profile for zib MedicationContraIndication on the Flag resource currently adds SNOMED-code 140401000146105 (Medical contraindication related to medication) on Flag.category. However, is it actually correct/needed to require this code here?

Reasons to include it here:

• It can be used to query all contra-indications related to medication for a particular person. However, the fact that this is a contra-indication is already conveyed by the fact that this is a Flag resource, so the more generic and more compatible code for "drug" from FHIR core can be used. In addition, systems could simply query for Flags that use the G-standaard Contra Indicaties as code system as described by the zib.
• It helps identifying the profile as "zib MedicationContraIndication". However, this seems like a false reason. The purpose of the profiles should be to convey the information from the zib, not to identify the information as "being the zib". In addition, a query on the G-standaard Contra Indicaties as mentioned above might be more suitable anyway.

[ArdonToonstra]

I think this issue will play a role in more zib-profiles. Perhaps we should rewrite the issue a bit to make its context somewhat broader and find an audience for input?

The HL7 Vital Signs profiles contain a mandatory fixed .category element and is used extensively in the described search requests. There is a difference between the Vital Signs use of category and the fixed category for the zib MedicationContraIndication. The former actually acts as a category for multiple known profiles while the zib category currently has only one profile.

Perhaps we should only fix a category if we also use intent to use it as a proper category?

On the other hand, Medication Process heavily leans on the use of a fixed category for querying individual zibs. I don't think those fixed categories function as proper categories too. How would querying work if we don't use the category? (search on meta.profile?)

[ArdonToonstra]

I feel this spans a wider area than only Flag.category in MedicationContraIndication. What do you think? Do we need to do something with or do we continue as we have done in the past?

[jd-nictiz]

I thinks we could/should discuss this. Hadn't seen the issue until know.

On the other hand, Medication Process heavily leans on the use of a fixed category for querying individual zibs.

This is a circular argument. If we decide to not use fixed categories, the queries have to be revised. But sure, before the decision we need to check if this is possible. If not, that we be an argument for keeping the fixed categories.

That being said:

In addition, systems could simply query for Flags that use the G-standaard Contra Indicaties as code system as described by the zib.

There actually isn't a search parameter for Flag.code (https://www.hl7.org/fhir/flag.html), so I guess this actually isn't possible (edit: without a custom search parameter). So if there would be a use case to get all MCI's, we probably would need Flag.category.

[pieter-edelman-nictiz]

• Some resources have only an example binding whereas other resources have a preferred or extensible binding.
• The code on .category might actually represent a category, e.g. 'the category of CarePlans that are nursing interventions'
• .category is usually 0..*. As long as it doesn't prohibit other uses, it doesn't harm to add it.

[pieter-edelman-nictiz]

Conclusion:

• If it doesn't prohibit other uses of .category AND it semantically represents a category, than it is helpful to add this. In other situations this should be closely inspected.

[pieter-edelman-nictiz]

Vervolgstappen:

• Toevoegen aan profiling guidelines
• Nalopen gemaakte profielen

[ArdonToonstra]

For some of the medication profiles we have a .category element that is 0..1 (which will be relaxed in R5) and we do have the need to be able to query the individual profiles. Hence, for mainly pragmatic reasons the profile (e.g. MedicationDispense) contain the zib's fixed pattern on .category and have an extension containing the FHIR native category on .category.extension if others want to reuse the profile and use the category in a different way.

In short, this doesn't fit the above conclusion perfectly at all, but I don't see another (pragmatic) option here.

[pieter-edelman-nictiz]

@jduwel will look into alternative queries for the above situation

[jd-nictiz]

When referring to the MedicationDispense resource: at the moment, this is done by .category. An alternative would be .type, but the example ValueSet found there does not match the intent of the (difference between) the zibs any better than .category. When looking at current STU3 exchange of the zib and with the notion that this issue will be fixed in R5, I would propose leaving this situation as is.

The ext-MedicationDispense.Category extension only found in nl-core-MedicationDispense (not in nl-core-AdministrationAgreement, shouldn't it be added in both if applicable?) does not have a functional basis. If there is no use case for exchanging the native FHIR category, in my opinion it is up to implementers to add and maintain such an extension if there is a need for internal storage or limited exchange of the native category.