Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diesen Akteur implementiert.

Jede Instanz eines bestätigungsrelevanten Systems MUSS an ihrem Endpunkt eine CapabilityStatement-Ressource bereitstellen. Hierzu MUSS die capabilities-Interaktion gemäß FHIR-Kernspezifikation unterstützt werden. Der MODE-Parameter kann ignoriert werden.
Das CapabilityStatement in dieser Spezifikation stellt die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Rollen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Imports-Expectation-Extension mit den möglichen Werten 'SHALL' (=MUSS) 'SHOULD' (=SOLL) 'MAY' (=KANN) 'SHOULD-NOT' (=SOLL NICHT) verwendet.

Eine Server-Instanz MUSS ihrerseits ein CapabilityStatement vom kind = instance liefern und im Element software den Namen und die Versionsnummer angeben.
Darüber hinaus MÜSSEN in CapabilityStatement.instantiates sämtliche Canonical URLs der implementierten Rollen angegeben werden.

Das CapabilityStatement der Instanz MUSS alle Funktionalitäten auflisten, die im folgenden CapabilityStatement mit SHALL gekennzeichnet sind. Das CapabilityStatement KANN darüber hinaus die mit MAY gekennzeichneten Funktionalitäten, sowie weitere Funktionalitäten auflisten, sofern diese in der Instanz implementiert wurden.

Die Verwendung der CapabilityStatement-Expectation-Extension ist im CapabilityStatement der Server-Instanz nicht erforderlich.

Das vorliegende CapabilityStatement bündelt alle Rollen die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren des Moduls 'Medikation', Bereich 'Medikationsverordnung' zu bestehen.

HISTORIE:

• 5.0.0 - Erzeugung des Akteurs-CapabilityStatement zur Bündelung der Rollen.

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diesen Akteur implementiert.

Jede Instanz eines bestätigungsrelevanten Systems MUSS an ihrem Endpunkt eine CapabilityStatement-Ressource bereitstellen. Hierzu MUSS die capabilities-Interaktion gemäß FHIR-Kernspezifikation unterstützt werden. Der MODE-Parameter kann ignoriert werden.
Das CapabilityStatement in dieser Spezifikation stellt die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Rollen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Imports-Expectation-Extension mit den möglichen Werten 'SHALL' (=MUSS) 'SHOULD' (=SOLL) 'MAY' (=KANN) 'SHOULD-NOT' (=SOLL NICHT) verwendet.

Eine Server-Instanz MUSS ihrerseits ein CapabilityStatement vom kind = instance liefern und im Element software den Namen und die Versionsnummer angeben.
Darüber hinaus MÜSSEN in CapabilityStatement.instantiates sämtliche Canonical URLs der implementierten Rollen angegeben werden.

Das CapabilityStatement der Instanz MUSS alle Funktionalitäten auflisten, die im folgenden CapabilityStatement mit SHALL gekennzeichnet sind. Das CapabilityStatement KANN darüber hinaus die mit MAY gekennzeichneten Funktionalitäten, sowie weitere Funktionalitäten auflisten, sofern diese in der Instanz implementiert wurden.

Die Verwendung der CapabilityStatement-Expectation-Extension ist im CapabilityStatement der Server-Instanz nicht erforderlich.

Das vorliegende CapabilityStatement bündelt alle Rollen die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren des Moduls 'Medikation', Bereich 'Medikationsinformation' zu bestehen.

HISTORIE:

• 5.0.0 - Erzeugung des Akteurs-CapabilityStatement zur Bündelung der Rollen.

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diesen Akteur implementiert.

Jede Instanz eines bestätigungsrelevanten Systems MUSS an ihrem Endpunkt eine CapabilityStatement-Ressource bereitstellen. Hierzu MUSS die capabilities-Interaktion gemäß FHIR-Kernspezifikation unterstützt werden. Der MODE-Parameter kann ignoriert werden.
Das CapabilityStatement in dieser Spezifikation stellt die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Rollen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Imports-Expectation-Extension mit den möglichen Werten 'SHALL' (=MUSS) 'SHOULD' (=SOLL) 'MAY' (=KANN) 'SHOULD-NOT' (=SOLL NICHT) verwendet.

Eine Server-Instanz MUSS ihrerseits ein CapabilityStatement vom kind = instance liefern und im Element software den Namen und die Versionsnummer angeben.
Darüber hinaus MÜSSEN in CapabilityStatement.instantiates sämtliche Canonical URLs der implementierten Rollen angegeben werden.

Das CapabilityStatement der Instanz MUSS alle Funktionalitäten auflisten, die im folgenden CapabilityStatement mit SHALL gekennzeichnet sind. Das CapabilityStatement KANN darüber hinaus die mit MAY gekennzeichneten Funktionalitäten, sowie weitere Funktionalitäten auflisten, sofern diese in der Instanz implementiert wurden.

Die Verwendung der CapabilityStatement-Expectation-Extension ist im CapabilityStatement der Server-Instanz nicht erforderlich.

Das vorliegende CapabilityStatement bündelt alle Rollen die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren des Moduls 'Medikation', Bereich 'Medikationsverabreichung' zu bestehen.

HISTORIE:

• 5.0.0 - Erzeugung des Akteurs-CapabilityStatement zur Bündelung der Rollen.

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diesen Akteur implementiert.

Jede Instanz eines bestätigungsrelevanten Systems MUSS an ihrem Endpunkt eine CapabilityStatement-Ressource bereitstellen. Hierzu MUSS die capabilities-Interaktion gemäß FHIR-Kernspezifikation unterstützt werden. Der MODE-Parameter kann ignoriert werden.
Das CapabilityStatement in dieser Spezifikation stellt die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Rollen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Imports-Expectation-Extension mit den möglichen Werten 'SHALL' (=MUSS) 'SHOULD' (=SOLL) 'MAY' (=KANN) 'SHOULD-NOT' (=SOLL NICHT) verwendet.

Eine Server-Instanz MUSS ihrerseits ein CapabilityStatement vom kind = instance liefern und im Element software den Namen und die Versionsnummer angeben.
Darüber hinaus MÜSSEN in CapabilityStatement.instantiates sämtliche Canonical URLs der implementierten Rollen angegeben werden.

Das CapabilityStatement der Instanz MUSS alle Funktionalitäten auflisten, die im folgenden CapabilityStatement mit SHALL gekennzeichnet sind. Das CapabilityStatement KANN darüber hinaus die mit MAY gekennzeichneten Funktionalitäten, sowie weitere Funktionalitäten auflisten, sofern diese in der Instanz implementiert wurden.

Die Verwendung der CapabilityStatement-Expectation-Extension ist im CapabilityStatement der Server-Instanz nicht erforderlich.

Das vorliegende CapabilityStatement bündelt alle Rollen die ein ISiK-konformes System unterstützen muss, um das Bestätigungsverfahren des Moduls 'Medikation', Bereich 'AMTS' zu bestehen.

HISTORIE:

• 5.0.0
  • Hinzufügen von Interaktionen für die Prozedur für den AMTS-Bereich.
  • Erzeugung des Akteurs-CapabilityStatement zur Bündelung der Rollen.

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

Das vorliegende CapabilityStatement beschreibt alle verpflichtenden Interaktionen die ein ISiK-konformes System unterstützen muss um das Bestätigungsverfahren des Moduls 'Medikation', Bereich 'Medikationsverordnung' zu bestehen.

HISTORIE:

• change Die Verbindlichkeit des Suchparameters subject wurde von SHALL auf MAY reduziert, da der Suchparameter patient für ISiK-Zwecke ausreichend ist.
• change Die Verbindlichkeit von Include und RevInclude wurde von SHALL auf MAY reduziert, außer bei den Parameter patient und encounter, da diese für ISiK-Zwecke ausreichend sind.

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

Das vorliegende CapabilityStatement beschreibt alle verpflichtenden Interaktionen die ein ISiK-konformes System unterstützen muss um das Bestätigungsverfahren des Moduls 'Medikation', Bereich 'Medikationsinformation' zu bestehen.

HISTORIE:

• change Die Verbindlichkeit des Suchparameters subject wurde von SHALL auf MAY reduziert, da der Suchparameter patient für ISiK-Zwecke ausreichend ist.
• change Die Verbindlichkeit von Include und RevInclude wurde von SHALL auf MAY reduziert, außer bei den Parameter patient und encounter, da diese für ISiK-Zwecke ausreichend sind.

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

Das vorliegende CapabilityStatement beschreibt alle verpflichtenden Interaktionen die ein ISiK-konformes System unterstützen muss um das Bestätigungsverfahren des Moduls 'Medikation', Bereich 'Medikationsverabreichung' zu bestehen.

HISTORIE:

• change Die Verbindlichkeit des Suchparameters subject wurde von SHALL auf MAY reduziert, da der Suchparameter patient für ISiK-Zwecke ausreichend ist.
• change Die Verbindlichkeit von Include und RevInclude wurde von SHALL auf MAY reduziert, außer bei den Parameter patient und encounter, da diese für ISiK-Zwecke ausreichend sind.

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

Das vorliegende CapabilityStatement beschreibt alle verpflichtenden Interaktionen die ein ISiK-konformes System unterstützen muss um das Bestätigungsverfahren des Moduls 'Medikation', Bereich 'Medikationsverordnung' zu bestehen.

HISTORIE:

• change Die Verbindlichkeit des Suchparameters subject wurde von SHALL auf MAY reduziert, da der Suchparameter patient für ISiK-Zwecke ausreichend ist.
• change Die Verbindlichkeit von Include und RevInclude wurde von SHALL auf MAY reduziert, außer bei den Parameter patient und encounter, da diese für ISiK-Zwecke ausreichend sind.

Dieses CapabilityStatement beschreibt alle Interaktionen, die ein System unterstützen MUSS, welches diese Rolle implementiert.

Die CapabilityStatements in dieser Spezifikation stellen die Anforderungen seitens der gematik dar (kind = requirements). Zur Unterscheidung von Anforderungen, die erfüllt werden MÜSSEN gegenüber jenen, die erfüllt werden KÖNNEN, wird die CapabilityStatement-Expectation-Extension mit den möglichen Werten SHALL (=MUSS) und MAY (=KANN) verwendet.

Das vorliegende CapabilityStatement beschreibt alle verpflichtenden Interaktionen, die ein ISiK-konformes System unterstützen muss, um Abfragen zum Medikament zu ermöglichen.

HISTORIE:

• 5.0.0
  • refactorals eigene Rolle initiiert