search

gematik / spec-ISiK-Medikation

The ISiK module "Medication" enables data integration through structured communication options based on a RESTful API for the exchange of medication information ("Medication Plan") as well as prescription and administration data.
Other
6 stars 1 forks source link

TC 2 und 3 - Erläuterung in CapabilityStatement benötigt #87

Closed f-peverali closed 7 months ago

f-peverali commented 1 year ago

Das Beispiel prüfen und ggf. Anpassen.

Anfrage: " The samples here https://github.com/gematik/spec-ISiK-Medikation/blob/main-stufe-3/Resources/fsh-generated/resources/Bundle-ExampleISiKMedikationTransaction.json dont conform with the IG" https://chat.fhir.org/#narrow/stream/287581-german.2Fisik/topic/MedicationAdministration.20use.20cases

### Tasks
- [x] PTDATA-675
markus020 commented 1 year ago

@f-peverali: ich habe gerade kurz drüber geschaut und jetzt auf die schnelle keine Abweichung zum IG gesehen.

f-peverali commented 1 year ago

nochmal automatisiert prüfen (codfsh, Referenzvalidator) für beide Stufe 2 und 3. FYI wie eben besprochen @alexey-tschudnowsky , @f.busch ... ggf. auch für dich als Hintergrund relevant @MaxMTheilig

f-peverali commented 1 year ago

Sichtprüfung und Prüfung mittels Referenzvalidator ergab keinen Fehler. Rückfrage wird gestellt.

f-peverali commented 1 year ago

Ggf. muss Bundle-Example aus Basis (3) in die Entsprechende IG-Passage (Bericht-Subsystem)?

vivekr2001 commented 1 year ago

The MedicationStatement resource only has Patient reference. The bundle does not have the Patient resource. the details of which are required for Patient matching

f-peverali commented 1 year ago

@vivekr2001 do you have an Error-Message from a validation process? From the mere perspective of the Spcification's status quo I do not see the necessity to provide the Patient as an own Entry within the bundle. If you have good reasons to think it should be a requirement, then the problem would be the Spec itself and not the example ...

vivekr2001 commented 1 year ago

The IG says Patient "shall" be part of the bundle and Shall in FHIR terminology is must. Please correct me if my interpretation is wrong image

alexzautke commented 1 year ago

This SHALL only means that you must support creating a Patient resource via the transaction. However the client decides which resources to include in the transaction. It doesn’t not have any influence on the cardinality of resources within the transaction.

Additionally, the requirement to do a match on the patient reference only exists for Document bundles, not transaction bundles.

@f-peverali I can see the confusion here. We should add a note about this in the base IG.

markus020 commented 1 year ago

That's because in a FHIR CababilityStatement are "interaction" (mean which of transaction | batch | search-system | history-system operations are supportet) and which ressource (and which interaction per ressource are supportet) are two different things.

The first SHALL only says, that the Server has to support transactional (whatever) instead of batch* for example).

Which type of Ressource with wich Request you can write in your Transaction Bundle is defined within the Ressource interactions. For the Patient Ressource-type a server only needs to support Read and Search, so in this case a server don't need to support any writing-operations on this ressource. In the real world it would be bad, if with a e.g. a MedicationAdministration also a Create or Update for a Patient-Ressource is includet. Those Systems are typically not allowed to change a Patient - as it is a transaction Bundle failing this request will make the whole transaction fail.

@f-peverali: i also see a need for some more information

MaxMTheilig commented 7 months ago

we clarified this in the Basismodul as 'only for document bundles' and therefore, the above mentioned example is still correct. clarification added https://github.com/gematik/spec-ISiK-Medikation/commit/300557d6166ca9d9acf717fe22837c50b90b2bf9