diff --git a/Resources/fsh-generated/fsh-index.json b/Resources/fsh-generated/fsh-index.json index 842eae9..b766cdd 100644 --- a/Resources/fsh-generated/fsh-index.json +++ b/Resources/fsh-generated/fsh-index.json @@ -4,8 +4,8 @@ "fshName": "Suchergebnis-Beispiel", "fshType": "Instance", "fshFile": "ISiKDokumentenSuchergebnisse.fsh", - "startLine": 18, - "endLine": 24 + "startLine": 29, + "endLine": 35 }, { "outputFile": "CapabilityStatement-ISiKCapabilityStatementDokumentenaustauschServer.json", @@ -20,40 +20,40 @@ "fshName": "dok-beispiel-client-with-binary-jpeg-example-short", "fshType": "Instance", "fshFile": "ISiKDokumentenMetadaten.fsh", - "startLine": 262, - "endLine": 281 + "startLine": 269, + "endLine": 288 }, { "outputFile": "DocumentReference-dok-beispiel-client-with-binary-jpeg-example.json", "fshName": "dok-beispiel-client-with-binary-jpeg-example", "fshType": "Instance", "fshFile": "ISiKDokumentenMetadaten.fsh", - "startLine": 283, - "endLine": 302 + "startLine": 290, + "endLine": 309 }, { "outputFile": "DocumentReference-dok-beispiel-client-with-binary-pdf-example-short.json", "fshName": "dok-beispiel-client-with-binary-pdf-example-short", "fshType": "Instance", "fshFile": "ISiKDokumentenMetadaten.fsh", - "startLine": 241, - "endLine": 260 + "startLine": 248, + "endLine": 267 }, { "outputFile": "DocumentReference-dok-beispiel-client-with-binary-pdf-example.json", "fshName": "dok-beispiel-client-with-binary-pdf-example", "fshType": "Instance", "fshFile": "ISiKDokumentenMetadaten.fsh", - "startLine": 304, - "endLine": 323 + "startLine": 311, + "endLine": 330 }, { "outputFile": "DocumentReference-dok-beispiel-server.json", "fshName": "dok-beispiel-server", "fshType": "Instance", "fshFile": "ISiKDokumentenMetadaten.fsh", - "startLine": 218, - "endLine": 239 + "startLine": 225, + "endLine": 246 }, { "outputFile": "Encounter-BeispielBesuch.json", @@ -85,7 +85,7 @@ "fshType": "Profile", "fshFile": "ISiKDokumentenMetadaten.fsh", "startLine": 1, - "endLine": 214 + "endLine": 221 }, { "outputFile": "StructureDefinition-ISiKDokumentenSuchergebnisse.json", @@ -93,7 +93,7 @@ "fshType": "Profile", "fshFile": "ISiKDokumentenSuchergebnisse.fsh", "startLine": 1, - "endLine": 15 + "endLine": 27 }, { "outputFile": "ValueSet-ISiKConfidentialityCodes.json", diff --git a/Resources/fsh-generated/fsh-index.txt b/Resources/fsh-generated/fsh-index.txt index 5989e4d..86afa5b 100644 --- a/Resources/fsh-generated/fsh-index.txt +++ b/Resources/fsh-generated/fsh-index.txt @@ -1,14 +1,14 @@ Output File Name Type FSH File Lines -Bundle-Suchergebnis-Beispiel.json Suchergebnis-Beispiel Instance ISiKDokumentenSuchergebnisse.fsh 18 - 24 +Bundle-Suchergebnis-Beispiel.json Suchergebnis-Beispiel Instance ISiKDokumentenSuchergebnisse.fsh 29 - 35 CapabilityStatement-ISiKCapabilityStatementDokumentenaustauschServer.json ISiKCapabilityStatementDokumentenaustauschServer Instance ISiKCapabilityStatementDokumentenaustauschServer.fsh 1 - 152 -DocumentReference-dok-beispiel-client-with-binary-jpeg-example-short.json dok-beispiel-client-with-binary-jpeg-example-short Instance ISiKDokumentenMetadaten.fsh 262 - 281 -DocumentReference-dok-beispiel-client-with-binary-jpeg-example.json dok-beispiel-client-with-binary-jpeg-example Instance ISiKDokumentenMetadaten.fsh 283 - 302 -DocumentReference-dok-beispiel-client-with-binary-pdf-example-short.json dok-beispiel-client-with-binary-pdf-example-short Instance ISiKDokumentenMetadaten.fsh 241 - 260 -DocumentReference-dok-beispiel-client-with-binary-pdf-example.json dok-beispiel-client-with-binary-pdf-example Instance ISiKDokumentenMetadaten.fsh 304 - 323 -DocumentReference-dok-beispiel-server.json dok-beispiel-server Instance ISiKDokumentenMetadaten.fsh 218 - 239 +DocumentReference-dok-beispiel-client-with-binary-jpeg-example-short.json dok-beispiel-client-with-binary-jpeg-example-short Instance ISiKDokumentenMetadaten.fsh 269 - 288 +DocumentReference-dok-beispiel-client-with-binary-jpeg-example.json dok-beispiel-client-with-binary-jpeg-example Instance ISiKDokumentenMetadaten.fsh 290 - 309 +DocumentReference-dok-beispiel-client-with-binary-pdf-example-short.json dok-beispiel-client-with-binary-pdf-example-short Instance ISiKDokumentenMetadaten.fsh 248 - 267 +DocumentReference-dok-beispiel-client-with-binary-pdf-example.json dok-beispiel-client-with-binary-pdf-example Instance ISiKDokumentenMetadaten.fsh 311 - 330 +DocumentReference-dok-beispiel-server.json dok-beispiel-server Instance ISiKDokumentenMetadaten.fsh 225 - 246 Encounter-BeispielBesuch.json BeispielBesuch Instance referencedExamples.fsh 53 - 88 OperationDefinition-UpdateMetadata.json UpdateMetadata Instance OperationUpdateMetadata.fsh 1 - 32 Patient-PatientinMusterfrau.json PatientinMusterfrau Instance referencedExamples.fsh 1 - 51 -StructureDefinition-ISiKDokumentenMetadaten.json ISiKDokumentenMetadaten Profile ISiKDokumentenMetadaten.fsh 1 - 214 -StructureDefinition-ISiKDokumentenSuchergebnisse.json ISiKDokumentenSuchergebnisse Profile ISiKDokumentenSuchergebnisse.fsh 1 - 15 +StructureDefinition-ISiKDokumentenMetadaten.json ISiKDokumentenMetadaten Profile ISiKDokumentenMetadaten.fsh 1 - 221 +StructureDefinition-ISiKDokumentenSuchergebnisse.json ISiKDokumentenSuchergebnisse Profile ISiKDokumentenSuchergebnisse.fsh 1 - 27 ValueSet-ISiKConfidentialityCodes.json ISiKConfidentialityCodes ValueSet terminologies.fsh 1 - 8 \ No newline at end of file diff --git a/Resources/fsh-generated/resources/OperationDefinition-UpdateMetadata.json b/Resources/fsh-generated/resources/OperationDefinition-UpdateMetadata.json index 3384093..b8dd6ff 100644 --- a/Resources/fsh-generated/resources/OperationDefinition-UpdateMetadata.json +++ b/Resources/fsh-generated/resources/OperationDefinition-UpdateMetadata.json @@ -10,7 +10,7 @@ "name": "update-metadata", "description": "Update selected, uncritical document metadata in a safe and controlled manner without having to replace the whole document", "code": "update-metadata", - "comment": "\n Expected behaviour:\n* Servers SHALL update the DocumentReference.docStatus with the submitted values\n* Servers SHALL ensure that DocumentReference.text reflects this change\n", + "comment": "\r\n Expected behaviour:\r\n* Servers SHALL update the DocumentReference.docStatus with the submitted values\r\n* Servers SHALL ensure that DocumentReference.text reflects this change\r\n", "resource": [ "DocumentReference" ], diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKDokumentenMetadaten.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKDokumentenMetadaten.json index 96bce6f..52559db 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKDokumentenMetadaten.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKDokumentenMetadaten.json @@ -9,8 +9,8 @@ "experimental": false, "date": "2024-09-24", "publisher": "gematik GmbH", - "description": "Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Dokumentenmetadaten im Rahmen des Bestätigungsverfahrens der gematik. \n\n ### Motivation\nDie Ressource DocumentReference enthält die Metadaten, die für die Verwaltung von und die Suche nach Dokumenten benötigt werden. Der Inhalt des Dokumentes wird über DocumentReference.content beschrieben und über DocumentReference.content.attachment referenziert. Die Trennung von Dokument und Metadaten ermöglicht Clients die effiziente Suche und Auflistung von verfügbaren Dokumenten, ohne dass diese vollständig vom Server geladen werden müssen. Servern ermöglicht dieser Ansatz die Trennung zwischen den Metadaten in einer Datenbank und der Dokumentenablage in z.B. einem Dateisystem.\n\n ### Kompatibilität\nDieses Profil basiert auf dem Profil [MHD DocumentReference Comprehensive UnContained References Option](https://profiles.ihe.net/ITI/MHD/StructureDefinition-IHE.MHD.UnContained.Comprehensive.DocumentReference.html) (Version 4.2.0) von IHE International.\n\n #### Abweichungen vom IHE-Profil\nDie Verwendung von `DocumentReference.docStatus` ist im ISiK-Kontext gestattet.\n`DocumentReference.category` muss vom Client bei Vorhandensein eines KDL-Codes in `DocumentReference.type` nicht gefüllt werden. Bei der Verarbeitung auf dem Server im Rahmen der Interaktion {{pagelink: AkteureUndInteraktionen-Interaktion-Dokumentenbereitstellung}} wird `DocumentReference.category` anhand der [KDL-Mappings](https://simplifier.net/kdl/%7Eresources?category=ConceptMap&sortBy=RankScore_desc) ergänzt und damit die IHE-Kompatibilität hergestellt.\n`DocumentReference.sourcePatientInfo` muss im Rahmen von ISiK nicht gefüllt werden\n\n#### Einschränkungen des IHE-Profils\nElemente mit ValueSet-Bindings ohne verbindliche Vorgabe seitens IHE wurden auf die in Deutschland gebräuchlichen Terminologien (gemäß der Festlegungen von IHE Deutschland e.V.) eingeschränkt.", - "purpose": "Die Ressource [DocumentReference](https://hl7.org/fhir/R4/documentreference.html) enthält die Metadaten, \ndie für die Verwaltung von und die Suche nach Dokumenten benötigt werden. \nDer Inhalt des Dokumentes wird über `DocumentReference.content` beschrieben und über `DocumentReference.content.attachment` referenziert. \nDie Trennung von Dokument und Metadaten ermöglicht Clients die effiziente Suche und Auflistung von verfügbaren Dokumenten, ohne dass diese vollständig vom Server geladen werden müssen. \nServern ermöglicht dieser Ansatz die Trennung zwischen den Metadaten in einer Datenbank und der Dokumentenablage in z.B. einem Dateisystem.", + "description": "Dieses Profil spezifiziert die Minimalanforderungen für die Bereitstellung von Dokumentenmetadaten im Rahmen des Bestätigungsverfahrens der gematik. \r\n\r\n ### Motivation\r\nDie Ressource DocumentReference enthält die Metadaten, die für die Verwaltung von und die Suche nach Dokumenten benötigt werden. Der Inhalt des Dokumentes wird über DocumentReference.content beschrieben und über DocumentReference.content.attachment referenziert. Die Trennung von Dokument und Metadaten ermöglicht Clients die effiziente Suche und Auflistung von verfügbaren Dokumenten, ohne dass diese vollständig vom Server geladen werden müssen. Servern ermöglicht dieser Ansatz die Trennung zwischen den Metadaten in einer Datenbank und der Dokumentenablage in z.B. einem Dateisystem.\r\n\r\n ### Kompatibilität\r\nDieses Profil basiert auf dem Profil [MHD DocumentReference Comprehensive UnContained References Option](https://profiles.ihe.net/ITI/MHD/StructureDefinition-IHE.MHD.UnContained.Comprehensive.DocumentReference.html) (Version 4.2.0) von IHE International.\r\n\r\n #### Abweichungen vom IHE-Profil\r\nDie Verwendung von `DocumentReference.docStatus` ist im ISiK-Kontext gestattet.\r\n`DocumentReference.category` muss vom Client bei Vorhandensein eines KDL-Codes in `DocumentReference.type` nicht gefüllt werden. Bei der Verarbeitung auf dem Server im Rahmen der Interaktion {{pagelink: AkteureUndInteraktionen-Interaktion-Dokumentenbereitstellung}} wird `DocumentReference.category` anhand der [KDL-Mappings](https://simplifier.net/kdl/%7Eresources?category=ConceptMap&sortBy=RankScore_desc) ergänzt und damit die IHE-Kompatibilität hergestellt.\r\n`DocumentReference.sourcePatientInfo` muss im Rahmen von ISiK nicht gefüllt werden\r\n\r\n#### Einschränkungen des IHE-Profils\r\nElemente mit ValueSet-Bindings ohne verbindliche Vorgabe seitens IHE wurden auf die in Deutschland gebräuchlichen Terminologien (gemäß der Festlegungen von IHE Deutschland e.V.) eingeschränkt.", + "purpose": "Die Ressource [DocumentReference](https://hl7.org/fhir/R4/documentreference.html) enthält die Metadaten, \r\ndie für die Verwaltung von und die Suche nach Dokumenten benötigt werden. \r\nDer Inhalt des Dokumentes wird über `DocumentReference.content` beschrieben und über `DocumentReference.content.attachment` referenziert. \r\nDie Trennung von Dokument und Metadaten ermöglicht Clients die effiziente Suche und Auflistung von verfügbaren Dokumenten, ohne dass diese vollständig vom Server geladen werden müssen. \r\nServern ermöglicht dieser Ansatz die Trennung zwischen den Metadaten in einer Datenbank und der Dokumentenablage in z.B. einem Dateisystem.", "fhirVersion": "4.0.1", "mapping": [ { @@ -59,7 +59,7 @@ { "id": "DocumentReference.identifier", "path": "DocumentReference.identifier", - "comment": "Abweichend zu MHD V4.0.1 ist die Angabe eines Identifiers in ISiK nicht erforderlich.\nEin solcher kann bei Bedarf (z.B. zur Weitergabe des Dokumentes per XDS) erzeugt werden.\n [Konsens der Arbeitsgruppe vom 12.11.2021]\n\nUpdate für Stufe 3:\nIn MHD 4.2.0 wurde die Verpflichtung zur Angabe eines Identifiers gelockert, das ISiK-Profil ist damit in diesem Punkt wieder kompatibel zu IHE MHD.\n", + "comment": "Abweichend zu MHD V4.0.1 ist die Angabe eines Identifiers in ISiK nicht erforderlich.\r\nEin solcher kann bei Bedarf (z.B. zur Weitergabe des Dokumentes per XDS) erzeugt werden.\r\n [Konsens der Arbeitsgruppe vom 12.11.2021]\r\n\r\nUpdate für Stufe 3:\r\nIn MHD 4.2.0 wurde die Verpflichtung zur Angabe eines Identifiers gelockert, das ISiK-Profil ist damit in diesem Punkt wieder kompatibel zu IHE MHD.\r\n", "mustSupport": true, "mapping": [ { @@ -85,7 +85,7 @@ "id": "DocumentReference.docStatus", "path": "DocumentReference.docStatus", "short": "Bearbeitungsstatus des Dokumentes", - "comment": "Abweichend zu MHD V4.0.1 ist die Verwendung von docStatus im ISiK-Kontext erlaubt. Doe Verwendung von docStatus bleibt jedoch optional,\n da nicht alle Dokumentenerzeugende Systeme einen expliziten Freigabe-Workflow haben. Dokumentenserver müssen jedoch in der Lage sein, den Dokumentenstatus\n (sofern vorhanden) zu persistieren, anzuzeigen und zu reproduzieren.\n [Konsens der Arbeitsgruppe vom 10.12.2021]", + "comment": "Abweichend zu MHD V4.0.1 ist die Verwendung von docStatus im ISiK-Kontext erlaubt. Doe Verwendung von docStatus bleibt jedoch optional,\r\n da nicht alle Dokumentenerzeugende Systeme einen expliziten Freigabe-Workflow haben. Dokumentenserver müssen jedoch in der Lage sein, den Dokumentenstatus\r\n (sofern vorhanden) zu persistieren, anzuzeigen und zu reproduzieren.\r\n [Konsens der Arbeitsgruppe vom 10.12.2021]", "mustSupport": true, "mapping": [ { @@ -98,7 +98,7 @@ "id": "DocumentReference.type", "path": "DocumentReference.type", "short": "Dokumententyp", - "comment": "Im ISiK-Kontext ist die Typisierung eines Dokumentes mit Hilfe eines KDL-Codes *und* des IHE-XDS-Type-Codes erforderlich und ein Server MUSS beide Kodierungen bereitstellen - trotz der Kardinalität DocumentReference.type.coding:XDS 0..1 -, jedoch ist der IHE-XDS-Type-Code bei Übermittlung für Clients nicht verpflichtend (s.u. zu XDS).\n Während KDL-Codes eine feingranulare Dokumentenklassifikation für die gezielte Suche nach medizinischen und Administrativen Dokumenten ermöglichen,\n sind IHE-XDS-Type-Codes für den einrichtungsübergreifenden Dokumentenaustausch maßgeblich.\n Der XDS-Type-Code kann mit Hilfe der bereitgestellten [ConceptMaps](https://simplifier.net/kdl/~resources?category=ConceptMap)\n aus dem KDL-Code ermittelt werden. Weitere Typisierungen (z.B. nach SNOMED oder LOINC) sind uneingeschränkt erlaubt. [Konsens der Arbeitgruppe vom 18.02.2022]. Im Falle, dass der Code 'UNK' entsprechend der ConceptMap verwendet werden soll, MUSS das System 'http://terminology.hl7.org/CodeSystem/v3-NullFlavor' verwendet werden.", + "comment": "Im ISiK-Kontext ist die Typisierung eines Dokumentes mit Hilfe eines KDL-Codes *und* des IHE-XDS-Type-Codes erforderlich und ein Server MUSS beide Kodierungen bereitstellen - trotz der Kardinalität DocumentReference.type.coding:XDS 0..1 -, jedoch ist der IHE-XDS-Type-Code bei Übermittlung für Clients nicht verpflichtend (s.u. zu XDS).\r\n Während KDL-Codes eine feingranulare Dokumentenklassifikation für die gezielte Suche nach medizinischen und Administrativen Dokumenten ermöglichen,\r\n sind IHE-XDS-Type-Codes für den einrichtungsübergreifenden Dokumentenaustausch maßgeblich.\r\n Der XDS-Type-Code kann mit Hilfe der bereitgestellten [ConceptMaps](https://simplifier.net/kdl/~resources?category=ConceptMap)\r\n aus dem KDL-Code ermittelt werden. Weitere Typisierungen (z.B. nach SNOMED oder LOINC) sind uneingeschränkt erlaubt. [Konsens der Arbeitgruppe vom 18.02.2022]. Im Falle, dass der Code 'UNK' entsprechend der ConceptMap verwendet werden soll, MUSS das System 'http://terminology.hl7.org/CodeSystem/v3-NullFlavor' verwendet werden.", "min": 1, "mustSupport": true }, @@ -167,7 +167,7 @@ "path": "DocumentReference.type.coding", "sliceName": "XDS", "short": "Dokumenttyp gem. IHE-De-Terminologie", - "comment": "Die Übermittlung des XDS-Type-Codes ist im Rahmen der Dokumentenbereitstellung für Clients nicht verpflichtend,\n MUSS jedoch vom Server bei der Entgegennahme ggf. ergänzt und bei der Dokumentenabfrage zurückgegeben werden. Der XDS-Type-Code kann über die im Rahmen der [KDL-Spezifikation](https://simplifier.net/kdl) publizierten\n [ConceptMaps](https://simplifier.net/kdl/~resources?category=ConceptMap) aus dem KDL-Code ermittelt werden", + "comment": "Die Übermittlung des XDS-Type-Codes ist im Rahmen der Dokumentenbereitstellung für Clients nicht verpflichtend,\r\n MUSS jedoch vom Server bei der Entgegennahme ggf. ergänzt und bei der Dokumentenabfrage zurückgegeben werden. Der XDS-Type-Code kann über die im Rahmen der [KDL-Spezifikation](https://simplifier.net/kdl) publizierten\r\n [ConceptMaps](https://simplifier.net/kdl/~resources?category=ConceptMap) aus dem KDL-Code ermittelt werden", "min": 0, "max": "1", "patternCoding": { @@ -213,7 +213,7 @@ "id": "DocumentReference.category", "path": "DocumentReference.category", "short": "Dokumentklasse/-Kategorie", - "comment": "Die Kategorisierung von Dokumenten erfolgt mittels der von IHE Deutschland publizierten XDS-Class-Codes.\n Die übermittlung des XDS-Class-Codes ist im Rahmen der Dokumentenbereitstellung für Clients nicht verpflichtend,\n muss jedoch vom Server bei der Entgegennahme ggf. ergänzt und bei der Dokumentenabfrage zurückgegeben werden.\n Der XDS-Class-Code kann mit Hilfe der bereitgestellten [ConceptMap](https://simplifier.net/kdl/~resources?category=ConceptMap)\n aus dem KDL-Code ermittelt werden.", + "comment": "Die Kategorisierung von Dokumenten erfolgt mittels der von IHE Deutschland publizierten XDS-Class-Codes.\r\n Die übermittlung des XDS-Class-Codes ist im Rahmen der Dokumentenbereitstellung für Clients nicht verpflichtend,\r\n muss jedoch vom Server bei der Entgegennahme ggf. ergänzt und bei der Dokumentenabfrage zurückgegeben werden.\r\n Der XDS-Class-Code kann mit Hilfe der bereitgestellten [ConceptMap](https://simplifier.net/kdl/~resources?category=ConceptMap)\r\n aus dem KDL-Code ermittelt werden.", "max": "1", "mustSupport": true }, @@ -280,7 +280,7 @@ "id": "DocumentReference.subject", "path": "DocumentReference.subject", "short": "Patientenbezug des Dokumentes", - "comment": "Im ISIK-Kontext MUSS der referenzierte Patient konform zum [ISIKPatient](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKPatient) des Basismoduls sein.\n \n Für sonstige Kontexte siehe [FHIR Kernspezifikation](http://hl7.org/fhir/documentreference-definitions.html#DocumentReference.subject)", + "comment": "Im ISIK-Kontext MUSS der referenzierte Patient konform zum [ISIKPatient](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKPatient) des Basismoduls sein.\r\n \r\n Für sonstige Kontexte siehe [FHIR Kernspezifikation](http://hl7.org/fhir/documentreference-definitions.html#DocumentReference.subject)", "min": 1, "type": [ { @@ -310,13 +310,13 @@ { "id": "DocumentReference.date", "path": "DocumentReference.date", - "comment": "Abweichend zu MHD V4.0.1 ist die Verwendung von date im ISiK-Kontext nicht verpflichtend.\nDie Motivation für die verbindliche Verwendung von `date` seitens IHE ist nicht nachvollziehbar.\nEin entsprechender Change Request zur Harmonisierung wurde eingereicht. Das Dokumentendatum wird in attachment.creation gesetzt.\n\nUpdate für Stufe 3:\nIn MHD 4.2.0 wurde die Verpflichtung zur Angabe von date gelockert, das ISiK-Profil ist damit in diesem Punkt wieder kompatibel zu IHE MHD.\n" + "comment": "Abweichend zu MHD V4.0.1 ist die Verwendung von date im ISiK-Kontext nicht verpflichtend.\r\nDie Motivation für die verbindliche Verwendung von `date` seitens IHE ist nicht nachvollziehbar.\r\nEin entsprechender Change Request zur Harmonisierung wurde eingereicht. Das Dokumentendatum wird in attachment.creation gesetzt.\r\n\r\nUpdate für Stufe 3:\r\nIn MHD 4.2.0 wurde die Verpflichtung zur Angabe von date gelockert, das ISiK-Profil ist damit in diesem Punkt wieder kompatibel zu IHE MHD.\r\n" }, { "id": "DocumentReference.author", "path": "DocumentReference.author", "short": "Autor des Dokumentes", - "comment": "In dieser Ausbaustufe ist die Nennung des Namens oder Kürzels des Autors ausreichend.\n Eine darüber hinaus gehende Verlinkung auf einen Pracitioner (auflösbar auf dem Server) ist möglich aber nicht erforderlich.", + "comment": "In dieser Ausbaustufe ist die Nennung des Namens oder Kürzels des Autors ausreichend.\r\n Eine darüber hinaus gehende Verlinkung auf einen Pracitioner (auflösbar auf dem Server) ist möglich aber nicht erforderlich.", "mustSupport": true, "mapping": [ { @@ -380,7 +380,7 @@ "id": "DocumentReference.securityLabel", "path": "DocumentReference.securityLabel", "short": "Vertraulichkeit", - "comment": "Die Bereitstellung des Vertraulichkeitsinformation durch den Ersteller des Dokumentes ist verpflichtend.\nEbenso sind Dokumentenserver verpflichtet, diese Information zu persistieren und bei der Dokumentenabfrage zu reproduzieren.\nDie ISiK-Spezifikation trifft jedoch keine Annahmen darüber, wie sich einzelne Vertraulichkeitsstufen auf die Zugriffsberechtigungen\nverschiedener benutzer auf ein Dokument auswirken. Im ISiK-Kontext ist die Angabe einer der drei Vertraulichkeitsstufen\nN | R | V verpflichtend, jedoch ohne Einschränkung der Verwendung zusätzlicher Vertraulichkeits-Flags.\n \n\n[Konsens der Arbeitsgruppe vom 12.11.2021]", + "comment": "Die Bereitstellung des Vertraulichkeitsinformation durch den Ersteller des Dokumentes ist verpflichtend.\r\nEbenso sind Dokumentenserver verpflichtet, diese Information zu persistieren und bei der Dokumentenabfrage zu reproduzieren.\r\nDie ISiK-Spezifikation trifft jedoch keine Annahmen darüber, wie sich einzelne Vertraulichkeitsstufen auf die Zugriffsberechtigungen\r\nverschiedener benutzer auf ein Dokument auswirken. Im ISiK-Kontext ist die Angabe einer der drei Vertraulichkeitsstufen\r\nN | R | V verpflichtend, jedoch ohne Einschränkung der Verwendung zusätzlicher Vertraulichkeits-Flags.\r\n \r\n\r\n[Konsens der Arbeitsgruppe vom 12.11.2021]", "min": 1, "mustSupport": true, "binding": { @@ -420,7 +420,7 @@ "id": "DocumentReference.content.attachment.language", "path": "DocumentReference.content.attachment.language", "short": "Sprache, in der das Dokument verfasst wurde.", - "comment": "Kann bei Systemen, die keine Mehrsprachigkeit unterstützen,\n fest auf "de" oder "de-DE" gesetzt werden.", + "comment": "Kann bei Systemen, die keine Mehrsprachigkeit unterstützen,\r\n fest auf "de" oder "de-DE" gesetzt werden.", "min": 1, "mustSupport": true, "mapping": [ @@ -434,14 +434,14 @@ "id": "DocumentReference.content.attachment.data", "path": "DocumentReference.content.attachment.data", "short": "Base64-codierte Binärdaten", - "comment": "Um die Suche nach Dokumenten effizient zu gestalten, dürfen die Dokumente selbst nicht in die DocumentReference eingebettet werden, \n sondern müssen als separates Datenobjekt referenziert werden. \n \nUpdate für Stufe 3:\nDie Ausnahme bildet die Interaktion "Dokumentenbereitstellung", \nbei der die Binärdaten des Dokumentes eingebettet in die DocumentReference an den Server übermittelt und dort dann in eine separate \nRessource ausgelagert und über Attachment.url referenziert werden.\n\nEs ist zu beachten, dass diese base64-codierten Daten wiederum ein FHIR-Bundle (z.B. ein MIO oder ein ISiK Bericht aus einem Subsystem) repräsentieren können. Um eine einheitliche Handhabung der Dokumente für Clients zu ermöglichen werden diese trotz strukturiertem Inhalt per base64 abgebildet.", + "comment": "Um die Suche nach Dokumenten effizient zu gestalten, dürfen die Dokumente selbst nicht in die DocumentReference eingebettet werden, \r\n sondern müssen als separates Datenobjekt referenziert werden. \r\n \r\nUpdate für Stufe 3:\r\nDie Ausnahme bildet die Interaktion "Dokumentenbereitstellung", \r\nbei der die Binärdaten des Dokumentes eingebettet in die DocumentReference an den Server übermittelt und dort dann in eine separate \r\nRessource ausgelagert und über Attachment.url referenziert werden.\r\n\r\nEs ist zu beachten, dass diese base64-codierten Daten wiederum ein FHIR-Bundle (z.B. ein MIO oder ein ISiK Bericht aus einem Subsystem) repräsentieren können. Um eine einheitliche Handhabung der Dokumente für Clients zu ermöglichen werden diese trotz strukturiertem Inhalt per base64 abgebildet.", "mustSupport": true }, { "id": "DocumentReference.content.attachment.url", "path": "DocumentReference.content.attachment.url", "short": "Referenz auf Dokument", - "comment": "Um die Suche nach Dokumenten effizient zu gestalten, dürfen die Dokumente selbst nicht in die DocumentReference eingebettet werden, \n sondern müssen als separates Datenobjekt referenziert werden. \n\nWird ein separates Datenobjekt im ISIK-Kontext referenziert, so MUSS dieses konform zum Profil [ISIKBinary](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKBinary) aus dem Basismodul sein.\n \nUpdate für Stufe 3:\nDie Ausnahme bildet die Interaktion "Dokumentenbereitstellung", \nbei der die Binärdaten des Dokumentes eingebettet in die DocumentReference an den Server übermittelt und dort dann in eine separate \nRessource ausgelagert und über Attachment.url referenziert werden.", + "comment": "Um die Suche nach Dokumenten effizient zu gestalten, dürfen die Dokumente selbst nicht in die DocumentReference eingebettet werden, \r\n sondern müssen als separates Datenobjekt referenziert werden. \r\n\r\nWird ein separates Datenobjekt im ISIK-Kontext referenziert, so MUSS dieses konform zum Profil [ISIKBinary](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKBinary) aus dem Basismodul sein.\r\n \r\nUpdate für Stufe 3:\r\nDie Ausnahme bildet die Interaktion "Dokumentenbereitstellung", \r\nbei der die Binärdaten des Dokumentes eingebettet in die DocumentReference an den Server übermittelt und dort dann in eine separate \r\nRessource ausgelagert und über Attachment.url referenziert werden.", "mustSupport": true, "mapping": [ { @@ -454,7 +454,7 @@ "id": "DocumentReference.content.attachment.creation", "path": "DocumentReference.content.attachment.creation", "short": "Dokumentendatum", - "comment": "Es obliegt dem erzeugenden System, zu entscheiden,\n welches Datum als Dokumentendatum geeignet ist, z.B. Datum der Erstellung oder Datum der letzten Änderung", + "comment": "Es obliegt dem erzeugenden System, zu entscheiden,\r\n welches Datum als Dokumentendatum geeignet ist, z.B. Datum der Erstellung oder Datum der letzten Änderung", "min": 1, "mustSupport": true, "mapping": [ @@ -468,7 +468,7 @@ "id": "DocumentReference.content.format", "path": "DocumentReference.content.format", "short": "Format des Dokumentes", - "comment": "Sofern das Dokument nicht auf einem standardisierten,\n strukturierten Austauschformat (z.B. CDA) basiert, für dessen Interpretation ein konkretes Schema herangezogen werden muss,\n genügt die Angabe des Codes\n "urn:ihe:iti:xds:2017:mimeTypeSufficient"", + "comment": "Sofern das Dokument nicht auf einem standardisierten,\r\n strukturierten Austauschformat (z.B. CDA) basiert, für dessen Interpretation ein konkretes Schema herangezogen werden muss,\r\n genügt die Angabe des Codes\r\n "urn:ihe:iti:xds:2017:mimeTypeSufficient"", "min": 1, "mustSupport": true, "binding": { @@ -491,7 +491,7 @@ { "id": "DocumentReference.context.encounter", "path": "DocumentReference.context.encounter", - "comment": "Abweichend zu MHD V4.0.1 ist die Verwendung der Encounter-Referenz im ISiK-Kontext erlaubt. \n Wird ein Encounter im ISIK-Kontext referenziert, so MUSS dieser konform zum Profil [ISIKKontaktGesundheitseinrichtung](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKKontaktGesundheitseinrichtung) aus dem Basismodul sein. \nUpdate für Stufe 3: \nIn MHD 4.2.0 wurde das Verbot der Angabe einer Encounter-Referenz gelockert, das ISiK-Profil ist damit in diesem Punkt wieder kompatibel zu IHE MHD.\n ", + "comment": "Abweichend zu MHD V4.0.1 ist die Verwendung der Encounter-Referenz im ISiK-Kontext erlaubt. \r\n Wird ein Encounter im ISIK-Kontext referenziert, so MUSS dieser konform zum Profil [ISIKKontaktGesundheitseinrichtung](https://gematik.de/fhir/isik/v3/Basismodul/StructureDefinition/ISiKKontaktGesundheitseinrichtung) aus dem Basismodul sein. \r\nUpdate für Stufe 3: \r\nIn MHD 4.2.0 wurde das Verbot der Angabe einer Encounter-Referenz gelockert, das ISiK-Profil ist damit in diesem Punkt wieder kompatibel zu IHE MHD.\r\n ", "max": "1", "mustSupport": true, "mapping": [ diff --git a/Resources/fsh-generated/resources/StructureDefinition-ISiKDokumentenSuchergebnisse.json b/Resources/fsh-generated/resources/StructureDefinition-ISiKDokumentenSuchergebnisse.json index 11fb64e..d0a43e0 100644 --- a/Resources/fsh-generated/resources/StructureDefinition-ISiKDokumentenSuchergebnisse.json +++ b/Resources/fsh-generated/resources/StructureDefinition-ISiKDokumentenSuchergebnisse.json @@ -20,11 +20,16 @@ { "id": "Bundle.type", "path": "Bundle.type", - "fixedCode": "searchset" + "short": "Bundle-Typ", + "comment": "Fix: `searchset`", + "fixedCode": "searchset", + "mustSupport": true }, { "id": "Bundle.total", "path": "Bundle.total", + "short": "Gesamtzahl der Suchtreffer", + "comment": "Gesamtzahl der Suchtreffer auf dem Server, unabhängig vom Page-Size des aktuellen Bundles", "min": 1 }, { @@ -40,22 +45,29 @@ "rules": "open" } }, - { - "id": "Bundle.entry.fullUrl", - "path": "Bundle.entry.fullUrl", - "min": 1 - }, { "id": "Bundle.entry:DocumentReference", "path": "Bundle.entry", "sliceName": "DocumentReference", - "short": "DocumentReference", + "short": "Suchergebnis", + "comment": "Jedes Suchergebnis wird in einer separaten `entry` abgebildet. Bundles mit `total = 0` haben keine `entry`", "min": 0, - "max": "*" + "max": "*", + "mustSupport": true + }, + { + "id": "Bundle.entry:DocumentReference.fullUrl", + "path": "Bundle.entry.fullUrl", + "short": "Serverseitige URL der Ressource", + "comment": "Serverseitige URL der Ressource in `entry.resource`", + "min": 1, + "mustSupport": true }, { "id": "Bundle.entry:DocumentReference.resource", "path": "Bundle.entry.resource", + "short": "Eingebettete Ressource", + "comment": "Eingebettete Ressource (hier: DocumentReference, die den Suchkriterien entspricht)", "min": 1, "type": [ { @@ -64,7 +76,8 @@ "https://gematik.de/fhir/isik/StructureDefinition/ISiKDokumentenMetadaten" ] } - ] + ], + "mustSupport": true } ] } diff --git a/Resources/fsh-generated/resources/ValueSet-ISiKConfidentialityCodes.json b/Resources/fsh-generated/resources/ValueSet-ISiKConfidentialityCodes.json index 3c14093..0fa3721 100644 --- a/Resources/fsh-generated/resources/ValueSet-ISiKConfidentialityCodes.json +++ b/Resources/fsh-generated/resources/ValueSet-ISiKConfidentialityCodes.json @@ -5,8 +5,8 @@ "id": "ISiKConfidentialityCodes", "title": "ISiKConfidentialityCodes", "description": "Vertraulichkeitsstufen", - "url": "https://gematik.de/fhir/isik/ValueSet/ISiKConfidentialityCodes", "version": "4.0.1", + "url": "https://gematik.de/fhir/isik/ValueSet/ISiKConfidentialityCodes", "experimental": false, "publisher": "gematik GmbH", "date": "2024-09-24", diff --git a/Resources/input/fsh/ISiKDokumentenSuchergebnisse.fsh b/Resources/input/fsh/ISiKDokumentenSuchergebnisse.fsh index 8d7afba..97ae4a3 100644 --- a/Resources/input/fsh/ISiKDokumentenSuchergebnisse.fsh +++ b/Resources/input/fsh/ISiKDokumentenSuchergebnisse.fsh @@ -3,17 +3,28 @@ Parent: Bundle Id: ISiKDokumentenSuchergebnisse Title: "Suchergebnisse einer Dokumentensuche" * insert Meta +* type MS * type = #searchset (exactly) + * ^short = "Bundle-Typ" + * ^comment = "Fix: `searchset`" * total 1.. + * ^short = "Gesamtzahl der Suchtreffer" + * ^comment = "Gesamtzahl der Suchtreffer auf dem Server, unabhängig vom Page-Size des aktuellen Bundles" * entry ^slicing.discriminator[0].type = #profile * entry ^slicing.discriminator[0].path = "resource" * entry ^slicing.rules = #open -* entry.fullUrl 1.. -* entry contains DocumentReference 0..* -* entry[DocumentReference] ^short = "DocumentReference" -* entry[DocumentReference].resource 1.. -* entry[DocumentReference].resource only ISiKDokumentenMetadaten - +* entry contains DocumentReference 0..* MS +* entry[DocumentReference] + * ^short = "Suchergebnis" + * ^comment = "Jedes Suchergebnis wird in einer separaten `entry` abgebildet. Bundles mit `total = 0` haben keine `entry`" +* entry[DocumentReference] + * fullUrl 1.. MS + * ^short = "Serverseitige URL der Ressource" + * ^comment = "Serverseitige URL der Ressource in `entry.resource`" + * resource 1.. MS + * resource only ISiKDokumentenMetadaten + * ^short = "Eingebettete Ressource" + * ^comment = "Eingebettete Ressource (hier: DocumentReference, die den Suchkriterien entspricht)" Instance: Suchergebnis-Beispiel InstanceOf: ISiKDokumentenSuchergebnisse