Ansicht
Dokumentation

CL_EXM_IM_ISHMED_CONN_MEDSYS - Klasse zur BAdI-Impl.: ISHMED_CONNECT_MEDSYS2APP_SRCH

rdisp/max_wprun_time - Maximum work process run time   ABAP Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Funktionalität

Diese Beispielimplementierung zeigt wie die leistungsgesteuerte Terminsuche der Besuchsdispostion (Transaktion NR16) an das Klinische Informationssystem i.s.h.med angebunden werden kann.

Beim leistungsgesteuerten Suchen von Terminen in der Besuchsdisposition werden vorläufige Leistungen gemeinsam mit dem gefundenen Termin erzeugt. Diese vorläufigen Leistungen werden in i.s.h.med nicht unterstützt. Um Termine, die mittels leistungsgesteuerter Terminsuche (NR16) gesucht werden, in i.s.h.med korrekt zu speichern, muss für die Leistungen, für die ein Termin gefunden wurde, ein Klinischer Auftrag angelegt werden.

Diese Beispielimplementierung kann Termine und Leistungen anzeigen, die im Zuge der leistungsgesteuerten Terminsuche ausgewählt wurden, um gemeinsam mit einem Klinischen Auftrag im System zu speichern.

Sie müssen in der Implementierung ergänzen, welcher Klinische Auftragstyp, der auf dem System bereits vorhanden ist, verwendet werden soll, um Leistungen und Termine zu speichern.

Sie können dazu einen allgemeinen Klinischen Auftragstyp verwenden, mit dem alle möglichen Leistungen bei den Behandlungsstellen beauftragt werden können. Sie können aber auch abhängig von der Leistung, die mit dem Klinischen Auftrag beauftragt werden soll, unterschiedliche Auftragstypen verwenden.

Berücksichtigen Sie, dass in dem Klinischen Auftragstyp zumindest der Leistungsbaustein eingebunden sein muss.

Wenn Sie im Rahmen der leistungsgesteuerten Terminsuche für Leistungen Termine suchen, bei denen eine Bewegung erst im Rahmen der Behandlung selbst angelegt werden darf (z.B. Operationen), so sollten in dem anzulegenenden Klinischen Auftrag zwei Positionen zur Verfügung stehen.

Mit Hilfe der ersten Position kann eine vorgelagerte administrative Aufnahme des Patienten stattfinden.

In der zweiten Position stehen die Leistungen für die der Bewegungsbezug erst bei Behandlungsbeginn (z.B. OP beginnen) hergestellt wird.

Beachten Sie, dass der Klinische Auftragstyp in dem Status, indem die Anlage stattfindet, keine Mussfelder beinhaltet.

Sie können geringfügige Anpassungen vornehmen, um die Daten Ihres Systems zu übergeben. Beispielsweise geben Sie den Klinischen Auftragstypen an.

Sie können Ihre Implementierung so definieren, dass diese von der Beispielimplementierung erbt. Die Klasse der Beispielimplementierung besitzt zur Ermittlung der erforderlichen Daten für das Anlegen des Klinischen Auftrages folgende Protected Methoden:

_GET_CREATE_DATA
Sie müssen diese Methode redefinieren und an jenen, der den Klinischen Auftrag veranlasst hat, sowie die Identifikation des Klinischen Auftragstypen für die anzulegende Klinische Auftragsposition zurückgeben.

_GET_OU_FOR_CORDPOS
Die Methode erhält alle Termine, die angelegt werden. Sie müssen diese Methode redefinieren und die behandelnde Organisationseinheit der Klinischen Auftragsposition zurückgeben.

_GET_PROXY_CORDTYP
Wenn Sie im Rahmen der leistungsgesteuerten Terminsuche für Leistungen Termine suchen, bei denen eine Bewegung erst im Rahmen der Behandlung selbst angelegt werden darf (z.B. Operationen), so sollten in dem anzulegenenden Klinischen Auftrag zwei Positionen zur Verfügung stehen. Sie müssen diese Methode redefinieren und die Identifikation des Klinischen Auftragstypen für diese zweite Position zurückgeben.

Beziehungen

Beispiel

Hinweise

Weiterführende Informationen

Addresses (Business Address Services)   CPI1466 during Backup  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 3999 Date: 20240426 Time: 064051     sap01-206 ( 81 ms )