Moderne Patient:innenabrechnung und Datenkommunikation on FHIR (MOPED)
0.1.0 - ci-build
Moderne Patient:innenabrechnung und Datenkommunikation on FHIR (MOPED) - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Official URL: http://example.org/OperationDefinition/MOPED.Patient.Aufnehmen | Version: 0.1.0 | |||
Draft as of 2024-11-19 | Responsible: Example Publisher | Computable Name: MOPED_Patient_Aufnehmen |
Wer ruft diese Operation in welchem Zusammenhang auf?
Die Operation wird vom Akteur Krankenhaus (KH) aufgerufen. Die $aufnehmen Operation wird aufgerufen, wenn ein(e) Patient*in in das Krankenhaus aufgenommen wird.
Voraussetzungen für den Aufruf
Detaillierte Business-Logik
$verlegen
für Neufaufnahme:
true
Validierung / Fehlerbehandlung
Weitere Hinweise
Annahmen an das BeS
system
des Parameters falldaten
.encounter.identifier dem GDA entspricht, der die Operation aufruft. Somit ist sichergestellt, dass nur eigene Fälle aufgenommen werden können.Generated Narrative: OperationDefinition MOPED.Patient.Aufnehmen
URL: [base]/Encounter/$aufnehmen
Use | Name | Scope | Cardinality | Type | Binding | Documentation |
IN | falldaten | 1..1 | Resource (MOPED Aufnahme Bundle) | Der falldaten Parameter beinhält die nötigen Elemente um die Details zum Fall zu beschreiben die bei Patientenaufnahme bekannt sind, inklusive Patient, Encounter und Coverage. | ||
IN | freigeben | 1..1 | boolean | Mit Hilfe des freigeben Parameters wird angegeben, ob es sich bei der Patienten-Aufnahme um vollständige Daten handelt und somit eine Validierung erfolgen soll (freigeben = true), oder ob lediglich unvollständige Daten zwischengespeichert werden (freigeben = false). | ||
IN | verdachtArbeitsSchuelerunfall | 0..1 | code | Verdacht auf Arbeits- oder Schuelerunfall ValueSet (Required) | Mit Hilfe des verdachtArbeitsSchuelerunfall Parameters wird festgehalten, ob es bei der Patienten-Aufnahme einen Verdacht auf einen Schüler- oder Arbeitsunfall gibt. Wird dieser Parameter mitgegeben, ist im Account das entsprechende Feld zu befüllen. | |
IN | verdachtFremdverschulden | 0..1 | boolean | Mit Hilfe des verdachtFremdverschulden Parameters wird festgehalten, ob es bei der Patienten-Aufnahme einen Verdacht auf Fremdverschulden gibt. Wird dieser Parameter mitgegeben, ist im Account das entsprechende Feld zu befüllen. | ||
IN | physischeAnwesenheit | 0..1 | boolean | Der physischeAnwesenheit Parameter definiert ob der Patient physisch anwesend ist oder nicht. | ||
IN | funktionscode | 1..1 | string | Der funktionscode Parameter definiert auf welchen Funktionscode die Neuaufnahme stattfindet. | ||
IN | funktionssubcode | 1..1 | string | Der funktionssubcode Parameter definiert auf welchen Funktionssubcode die Neuaufnahme stattfindet. | ||
OUT | return | 1..1 | Resource (OperationOutcome) | Der return Parameter gibt Auskunft über den Erfolg der Operation. Wenn der modus Parameter auf 'freigeben' gesetzt war, ist die Operation erfolgreich, wenn die Daten validiert wurden und abgespeichert werden konnten. Wenn der modus Parameter auf zwischenspeichern gesetzt war, ist für eine erfolgreiche Durchführung der Operation lediglich ein erfolgreiches Speichern vorausgesetzt. Schlägt die Operation fehl, wird eine entsprechende Meldung ausgegeben. |
TBD: möchten wir zusätzlich zur GDA-Referenz einen Input-Parameter, der gleich sein muss? Um in einem Extra-Schritt zusätzlich auf Gleichheit mit der Referenz in falldaten.MOPEDEncounter.serviceProvider prüfen zu können?; Frage an Architektur: gibt es Möglichkeiten, einen solchen Input-Parameter (GDA als Kontext) automatisiert auf einem anderen Sicherheits-Level zu befüllen als der Inhalt des Transaction Body?; Check, wo version-specific References nötig sind - ggf. relevant für Account.subject, Account.owner und Account.coverage sobald Modus auf freigeben. Überlegen, für was der Status Aufnahme in Arbeit tatsächlich nützlich ist und wenn dieser wirklich nötig ist, was passiert, wenn diese Operation mehrfach aufgerufen wird (speziell mit dem Einbringen von Hauptversicherten im Zuge der Speicherung von Coverages, das Anlegen von MOPEDTransfer Encounters via $verlgen ect.)