2-6 Medication Request with Medication Norvasc (Walter Wellauer, Daniel Ratschiller CISTEC)

[ig-feedback]

ch.fhir.ig.ch-emed#5.0.0-ci-build /MedicationRequest-2-6-MedReqNorvasc.html

Identifier UUID in example instance stimmt nicht mit Structurdefinition überein

Walter Wellauer, Daniel Ratschiller CISTEC

[ziegm]

@walterwellauer @drats-cis

https://fhir.ch/ig/ch-emed/MedicationRequest-2-6-MedReqNorvasc.json.html

  "identifier" : [
    {
      "system" : "urn:ietf:rfc:3986",
      "value" : "urn:uuid:d41d72ba-2100-11e6-b67b-9e71128cae77"
    }
  ],

https://fhir.ch/ig/ch-emed/StructureDefinition-ch-emed-medicationstatement.html

What do you exactly mean with "does not match"?

[walterwellauer]

@ziegm und @pjolo
The question here is not so much whether something is wrong, but rather

1. why this identifier is profiled
2. in which way the examples given in the structure definition are helping the implementer clarifying the use of this identifier as thios is an implementation guide, especially as the provided example instances use other examples sometimes.

ad 1) I understood by discussion with @oliveregger yesterday that these identifiers are an artefact of the cda mapping. They are not needed purely for tthese FHIR resources themselves.
1a. As cda are intented not to be followed in Switzerland it is questionnable whether this profiling is of further use
1b. I do not understand the fixed value of urn:ietf:rfc:3986 on the system parameter http://hl7.org/fhir/R4/datatypes.html#uri. The datatype of uri already asks for rfc:3986 - so what is the point of fixing it here?
1c. Is that realyy the right way to constrain the value to urn:uuid? I might have missed a point here so I would apreciate clarification

ad 2) I guess as of the above mentionned reason of mapping between cda and fhir ressources uuids are given as examples on the value parameter.
Example CH EMED: urn:uuid:daa8cd41-34a1-4a9c-9a6d-cd3f850142e9 in http://build.fhir.org/ig/hl7ch/ch-emed/StructureDefinition-ch-emed-medicationstatement.html for example. But always at it seems the same value
In the example instances "urn:uuid:d41d72ba-2100-11e6-b67b-9e71128cae77" but always at it seems the sa.me value
This leads to the question whether these examples are representing a clandestine semantic and have to be the same ? or whether it is just copy&paste in different circumstances or - together with 1c. they could be omitted in the structure definition and used mit arbitrarliy different uuids as in the real world.
Also here I may have missed a crucial point about these identifiers so I'd appreciate clarification, may be also in the IG home.

[ziegm]

Meeting 10.07.2024 PJ/OE/MZ

@ziegm und @pjolo The question here is not so much whether something is wrong, but rather

1. why this identifier is profiled

The reason for the document identifiers and resource identifiers is to link between the different medication documents (e.g. linking from a Medication Dispense document to a Medication Treatment Plan document, see here). A Medication Prescription document can have n MedicationRequest entries, if you want to reference one of those MedicationRequests, you need the identifier of the resource.

2. in which way the examples given in the structure definition are helping the implementer clarifying the use of this identifier as thios is an implementation guide, especially as the provided example instances use other examples sometimes.

In the structure definition you can only give an example of the datatype, that's why there is an example uuid is provided. The use case uses for each document/resource own identifiers (note that often the same identfier is used for the composition and the resource).

ad 1) I understood by discussion with @oliveregger yesterday that these identifiers are an artefact of the cda mapping. They are not needed purely for tthese FHIR resources themselves. 1a. As cda are intented not to be followed in Switzerland it is questionnable whether this profiling is of further use 1b. I do not understand the fixed value of urn:ietf:rfc:3986 on the system parameter http://hl7.org/fhir/R4/datatypes.html#uri. The datatype of uri already asks for rfc:3986 - so what is the point of fixing it here? 1c. Is that realyy the right way to constrain the value to urn:uuid? I might have missed a point here so I would apreciate clarification

1a) see reasoning above, it is to link between the different documents
1b/c) It was decided to use UUIDs as identifiers and not OID/URL with extension pairs. For representing UUIDs the system needs to be urn:ietf:rfc:3986 as described here.

ad 2) I guess as of the above mentionned reason of mapping between cda and fhir ressources uuids are given as examples on the value parameter. Example CH EMED: urn:uuid:daa8cd41-34a1-4a9c-9a6d-cd3f850142e9 in http://build.fhir.org/ig/hl7ch/ch-emed/StructureDefinition-ch-emed-medicationstatement.html for example. But always at it seems the same value In the example instances "urn:uuid:d41d72ba-2100-11e6-b67b-9e71128cae77" but always at it seems the sa.me value This leads to the question whether these examples are representing a clandestine semantic and have to be the same ? or whether it is just copy&paste in different circumstances or - together with 1c. they could be omitted in the structure definition and used mit arbitrarliy different uuids as in the real world. Also here I may have missed a crucial point about these identifiers so I'd appreciate clarification, may be also in the IG home.

2. It illustrates the example of an UUID.
   We will provide a 'Guidance' entry how the relationship between the documents works.

[ziegm]

see also #289

[ziegm]

Please have a look at the changes at the telco at 04.10.2024 (PJ/OE/SK):

• #272 (this issue): Guidance for Relationship between documents
• #289 (related issue): Added relationship to parent documents in 2-1 Medication List document
• Changelog (both issues listet)

[SabrinaVivien]

PJ OE QL SK (04.09.2024)
PJ discuss the issue with Walter