Implementierung des Philips Tasy Healthcare Systems

Die Philips Tasy EMR HTML5 (Tasy EMR) ist ein hochmodernes, webbasiertes System für elektronische Patientenakten (EMR), das von Philips Healthcare entwickelt wurde. Diese ausgeklügelte Software dient als Plattform für medizinische Geräte, die sowohl klinische als auch nicht-klinische Daten im Gesundheitswesen verwalten soll.

Obwohl es als eigenständiges System funktioniert, bietet es auch nahtlose Integrationsmöglichkeiten mit anderen medizinischen Systemen. Diese Flexibilität ermöglicht es mehreren Nutzern aus verschiedenen medizinischen Disziplinen, auf die Plattform zuzugreifen und sie zu nutzen, wodurch sie sehr anpassungsfähig und geeignet ist, die Effizienz und Qualität des Gesundheitswesens zu verbessern. Die Hauptaufgabe des Tasy EMR-Systems ist die präzise und sichere Dokumentation von Patienteninformationen.

Tasy EMR ist eine Multi-Tier-Anwendung, die auf der robusten Oracle-Datenbank ausgeführt wird und umfangreiche PL/SQL-Routinen nutzt. Das benutzerfreundliche HTML5-Frontend wird mit der AngularJS-Technologie erstellt. Die Kommunikation zwischen Client und Serverseite erfolgt über SOAP-/REST-Webservices.

Architektur

Diese Architektur umfasst das Tasy EMR-Gesundheitssystem.

Die wichtigsten Komponenten der Tasy EMR-Architektur sind:

  • Clientebene
    • Tasy EMR HTML5: Diese webbasierte Clientanwendung funktioniert nahtlos im Google Chrome-Browser. Es kommuniziert mit dem Tasy EMR-Webservice über REST-Anforderungen (Representational State Transfer) und verwendet eine proprietäre API.
    • Integrationen: Tasy EMR kann nahtlos in jedes Gerät integriert werden, das HL7, SOAP, REST-Anforderungen oder sogar einfache Dateiaustauschvorgänge verwendet, die in gemeinsamen Speicherorten gespeichert sind.
  • Serverlayer
    • Anwendungsserver: Tasy arbeitet mit Anwendungsservern wie Apache Tomcat und Oracle WebLogic Server zusammen, um seine Middleware-Komponenten zu hosten. Wenn Tomcat ausgewählt wird, haben Kunden die Möglichkeit, die Philips App-Manager-Plattformen zu nutzen und integrierte Anwendungscontainer auf Tomcat für verbesserte Leistung bereitzustellen.
    • Tasy EMR-Webservice: Dieser zentrale Webservice ist für den Empfang, die Verarbeitung und die Beantwortung aller Anfragen verantwortlich, die von Tasy EMR-Benutzern initiiert wurden.
    • Tasy EMR Reports-Webservice: Der Reports-Webservice wird ausschließlich mit der Erstellung von Systemberichten beauftragt. Es arbeitet in einer getrennten Umgebung und wird nur vom Tasy EMR-Webservice zur Berichterstellung aufgerufen.
    • Integrationswebservice: Dieser vielseitige Service erfüllt alle Integrationsanforderungen für Tasy EMR und bietet HL7-, SOAP-, REST- und dateibasierte Integrationen. Es verwaltet alle eingehenden und ausgehenden Nachrichten.
  • Load Balancer: Mit Oracle Cloud Infrastructure Load Balancing und zwei Servern auf Compute-Instanzen, auf denen Oracle Linux 8 ausgeführt wird, nutzt das System das HAProxy-Marktprodukt für robustes Anwendungs-Load Balancing und stellt High Availability sicher.
  • Oracle Database-Schicht: Diese Datenbank dient als Rückgrat von Tasy EMR und speichert alle Systeminformationen, einschließlich der meisten Geschäftsregeln, die in Form von PL/SQL-Objekten codiert sind. Die empfohlene und homologierte Version ist Oracle Database 19c, mit Unterstützung für 12 und 11 sowie der Aufnahme von MDS.

Hinweis:

Bei Projekten, an denen mehr als 1.500 vernetzte Nutzer beteiligt sind, rät Philips seinen Kunden dringend, mit einem seiner zugelassenen Infrastrukturpartner in Kontakt zu treten. Kontaktinformationen für diese Partner erhalten Sie bei der kaufmännischen Abteilung.

Hinweis:

Für Kunden mit mehr als 300 Workstations, die ihren Service nutzen, empfiehlt die Dokumentation von Philips eine High Availability-Infrastruktur auf allen Ebenen: Balancing, Anwendungsserver und Datenbank.


philips-tasy-diagram-oracle.zip

Diese Abbildung zeigt eine dreistufige Topologie, die aus einem Load Balancer, einer Anwendungsebene und einem Oracle Exadata Database Service zur Unterstützung einer Datenbank besteht. Alle Ressourcen werden in einer einzelnen Availability-Domain in einer OCI-Region bereitgestellt. Die Load Balancer Tier und Application Tier sind in separaten Subnetzen innerhalb eines einzelnen VCN isoliert. Netzwerksicherheitsgruppen regeln den Netzwerktraffic zu und von den Ressourcen in jeder Tier. Eine Routentabelle, die an jedes Subnetz angehängt ist, enthält Regeln zum Weiterleiten von Traffic, der für Ziele außerhalb des VCN bestimmt ist.

  • Clientanforderungen fließen über ein Internetgateway an WAF und den primären Load Balancer ein. Dieser verteilt die Anforderungen an die sekundäre Load-Balancing-Tier, die den Request an die Application Tier sendet.
  • Die Application Tier besteht aus Compute-Instanzen. Die Compute-Instanzen werden gleichmäßig auf alle Faultdomains in der Availability-Domain verteilt. Alle Compute-Instanzen in der Application Tier sind an ein privates Subnetz angehängt.
  • Die Datenbankebene besteht aus einer Oracle Exadata Database Service-Datenbank, die an ein privates Subnetz in einem separaten VCN angehängt ist.

Die Architektur umfasst die folgenden Komponenten:

  • Mandantenfähigkeit

    Ein Mandant ist eine sichere und isolierte Partition, die Oracle in Oracle Cloud einrichtet, wenn Sie sich für Oracle Cloud Infrastructure registrieren. Sie können Ihre Ressourcen in Oracle Cloud in Ihrem Mandanten erstellen, organisieren und verwalten. Ein Mandant ist gleichbedeutend mit einem Unternehmen oder einer Organisation. Normalerweise verfügt ein Unternehmen über einen einzelnen Mandanten und spiegelt seine Organisationsstruktur in diesem Mandanten wider. Ein einzelner Mandant ist in der Regel mit einem einzelnen Abonnement verknüpft, und ein einzelnes Abonnement hat in der Regel nur einen Mandanten.

  • Region

    Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center enthält, das als Availability-Domain bezeichnet wird. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder sogar Kontinente).

  • Compartment

    Compartments sind regionsübergreifende logische Partitionen in einem Oracle Cloud Infrastructure-Mandanten. Mit Compartments können Sie Ihre Ressourcen in Oracle Cloud organisieren, den Zugriff auf die Ressourcen kontrollieren und Nutzungs-Quotas festlegen. Um den Zugriff auf die Ressourcen in einem bestimmten Compartment zu kontrollieren, definieren Sie Policys, mit denen angegeben wird, wer auf die Ressourcen zugreifen kann und welche Aktionen sie ausführen können.

  • Availability-Domains

    Availability-Domains sind eigenständige, unabhängige Data Center innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz sicherstellt. Availability-Domains haben keine gemeinsame Infrastruktur wie Stromversorgung oder Kühlung oder das interne Availability-Domainnetzwerk. Es ist daher unwahrscheinlich, dass der Fehler in einer Availability-Domain sich auf die anderen Availability-Domains in der Region auswirkt.

  • Faultdomains

    Eine Faultdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain umfasst drei Fehlerdomänen mit unabhängiger Stromversorgung und Hardware. Wenn Sie Ressourcen auf mehrere Faultdomains verteilen, können Ihre Anwendungen physische Serverausfälle, Systemwartungen und Stromausfälle innerhalb einer Faultdomain tolerieren.

  • Virtuelles Cloud-Netzwerk (VCN) und Subnetze

    Ein VCN ist ein anpassbares, benutzerdefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten können. Wie herkömmliche Data Center-Netzwerke erhalten Sie mit VCNs vollständige Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.

  • Servicegateway

    Das Servicegateway ermöglicht den Zugriff von einem VCN auf andere Services, wie Oracle Cloud Infrastructure Object Storage. Der Traffic vom VCN zum Oracle-Service durchläuft die Oracle-Netzwerkstruktur und nie das Internet.

  • Cloud Guard

    Mit Oracle Cloud Guard können Sie die Sicherheit Ihrer Ressourcen in Oracle Cloud Infrastructure überwachen und verwalten. Cloud Guard verwendet Detektorrezepte, die Sie definieren können, um Ihre Ressourcen auf Sicherheitslücken zu untersuchen und Operatoren und Benutzer auf riskante Aktivitäten zu überwachen. Wenn eine Fehlkonfiguration oder unsichere Aktivität erkannt wird, empfiehlt Cloud Guard Korrekturmaßnahmen und unterstützt Sie bei der Ausführung dieser Aktionen basierend auf Responder-Rezepten, die Sie definieren können.

  • Object Storage

    Mit dem Objektspeicher können Sie schnell auf große Mengen an strukturierten und unstrukturierten Daten eines beliebigen Inhaltstyps zugreifen, darunter Datenbankbackups, analytische Daten und umfangreiche Inhalte, wie Bilder und Videos. Sie können Daten sicher und geschützt speichern und dann direkt aus dem Internet oder aus der Cloud-Plattform abrufen. Sie können den Speicher nahtlos skalieren, ohne die Performance oder Servicezuverlässigkeit zu beeinträchtigen. Verwenden Sie Standardspeicher für "Hot Storage", auf den Sie schnell, sofort und häufig zugreifen müssen. Verwenden Sie Archivspeicher für "Cold Storage", den Sie über lange Zeiträume beibehalten möchten und auf den Sie nur selten zugreifen.

  • Dynamisches Routinggateway (Dynamic Routing Gateway, DRG)

    Das DRG ist ein virtueller Router, der einen Pfad für privaten Netzwerktraffic zwischen VCNs in derselben Region zwischen einem VCN und einem Netzwerk außerhalb der Region bereitstellt, wie ein VCN in einer anderen Oracle Cloud Infrastructure-Region, einem On-Premise-Netzwerk oder einem Netzwerk in einem anderen Cloud-Provider.

  • FastConnect

    Mit Oracle Cloud Infrastructure FastConnect können Sie ganz einfach eine dedizierte, private Verbindung zwischen Ihrem Data Center und Oracle Cloud Infrastructure herstellen. FastConnect bietet Optionen mit höherer Bandbreite und ein zuverlässigeres Netzwerk als bei internetbasierten Verbindungen.

  • Exadata Database Service

    Mit Oracle Exadata Database Service können Sie die Vorteile von Exadata in der Cloud nutzen. Sie können flexible X8M- und X9M-Systeme bereitstellen, mit denen Sie dem System Datenbank-Compute-Server und Speicherserver je nach Bedarf hinzufügen können. X8M- und X9M-Systeme bieten RDMA over Converged Ethernet-(RoCE-)Networking für Module mit hoher Bandbreite und geringer Latenz, persistente Speichermodule (PMEM) und intelligente Exadata-Software. Sie können X8M- und X9M-Systeme mit einer Ausprägung bereitstellen, die einem Quarter-Rack-System X8 und X9M entspricht. Anschließend können Sie nach dem Provisioning jederzeit Datenbank- und Speicherserver hinzufügen.

    Oracle Exadata Database Service on Dedicated Infrastructure stellt Oracle Exadata Database Machine als Service in einem Oracle Cloud Infrastructure-(OCI-)Data-Center bereit. Die Oracle Exadata Database Service on Dedicated Infrastructure-Instanz ist ein Virtual-Machine-(VM-)Cluster, das sich auf Exadata-Racks in einer OCI-Region befindet.

    Oracle Exadata Database Service on Cloud@Customer stellt Oracle Exadata Database Service bereit, das in Ihrem Data Center gehostet wird.

  • Sicherheitsliste

    Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die Quelle, Ziel und Typ des Traffics angeben, der in und aus dem Subnetz zulässig sein muss.

  • Block-Volume

    Mit Blockspeicher-Volumes können Sie Speicher-Volumes erstellen, anhängen, verbinden und verschieben und die Volume-Performance entsprechend Ihrer Speicher-, Performance- und Anwendungsanforderungen ändern. Nachdem Sie ein Volume an eine Instanz angehängt und damit verbunden haben, können Sie es wie eine herkömmliche Festplatte verwenden. Sie können ein Volume auch trennen und an eine andere Instanz anhängen, ohne Daten zu verlieren.

Empfehlungen

Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt. Ihre Anforderungen können von der hier beschriebenen Architektur abweichen.
  • VCN

    Wenn Sie ein VCN erstellen, bestimmen Sie die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen, die Sie an Subnetze im VCN anhängen möchten. Verwenden Sie CIDR-Blöcke innerhalb des standardmäßigen privaten IP-Adressraums.

    Wählen Sie CIDR-Blöcke aus, die sich nicht mit anderen Netzwerken (in Oracle Cloud Infrastructure, Ihrem On-Premise-Data Center oder einem anderen Cloud-Provider) überschneiden, für die Sie private Verbindungen einrichten möchten.

    Nachdem Sie ein VCN erstellt haben, können Sie dessen CIDR-Blöcke ändern, hinzufügen und entfernen.

    Berücksichtigen Sie beim Entwerfen der Subnetze den Trafficfluss und die Sicherheitsanforderungen. Hängen Sie alle Ressourcen innerhalb einer bestimmten Tier oder Rolle an dasselbe Subnetz an, das als Sicherheitsgrenze dienen kann.

  • Cloud Guard

    Klonen und passen Sie die von Oracle bereitgestellten Standardrezepte an, um benutzerdefinierte Detektor- und Responder-Rezepte zu erstellen. Mit diesen Rezepten können Sie angeben, welcher Typ von Sicherheitsverletzungen eine Warnung generiert und welche Aktionen für sie ausgeführt werden dürfen. Beispiel: Sie möchten Objektspeicher-Buckets ermitteln, deren Sichtbarkeit auf "Öffentlich" gesetzt ist.

    Wenden Sie Cloud Guard auf Mandantenebene an, um den größten Geltungsbereich abzudecken und den Verwaltungsaufwand für die Verwaltung mehrerer Konfigurationen zu reduzieren.

    Sie können auch das Feature "Verwaltete Liste" verwenden, um bestimmte Konfigurationen auf Detektoren anzuwenden.

  • Sicherheitszonen

    Für Ressourcen, für die maximale Sicherheit erforderlich ist, empfiehlt Oracle die Verwendung von Sicherheitszonen. Eine Sicherheitszone ist ein Compartment, das mit einem von Oracle definierten Rezept von Sicherheits-Policys verknüpft ist, die auf Best Practices basieren. Beispiel: Die Ressourcen in einer Sicherheitszone dürfen nicht über das öffentliche Internet zugänglich sein und müssen mit vom Kunden verwalteten Schlüsseln verschlüsselt werden. Wenn Sie Ressourcen in einer Sicherheitszone erstellen und aktualisieren, validiert Oracle Cloud Infrastructure die Vorgänge anhand der Policys im Rezept der Sicherheitszone und lehnt Vorgänge ab, die eine der Policys verletzen.

  • Network Security Groups (NSGs)

    Mit NSGs können Sie ein Set von Ingress- und Egress-Regeln definieren, die für bestimmte VNICs gelten. Wir empfehlen die Verwendung von NSGs anstelle von Sicherheitslisten, da NSGs es Ihnen ermöglichen, die Subnetzarchitektur des VCN von den Sicherheitsanforderungen Ihrer Anwendung zu trennen.

  • Load-Balancer-Bandbreite

    Beim Erstellen des Load Balancers können Sie entweder eine vordefinierte Ausprägung auswählen, die eine feste Bandbreite bereitstellt, oder eine benutzerdefinierte (flexible) Ausprägung angeben, in der Sie einen Bandbreitenbereich festlegen und der Service die Bandbreite automatisch basierend auf Trafficmustern skalieren lässt. Mit beiden Methoden können Sie die Ausprägung jederzeit ändern, nachdem Sie den Load Balancer erstellt haben.

  • Block-Volumes-Backup-Policy

    Konfigurieren Sie eine Policy so, dass Backups der Block-Volumes so häufig wie erforderlich erstellt werden, um das RPO zu erfüllen.

  • Data Guard

    Oracle Data Guard bietet ein umfassendes Set von Services, mit denen Sie mindestens eine Standbydatenbank erstellen, verwalten und überwachen können, damit Oracle-Produktionsdatenbanken ohne Unterbrechung verfügbar bleiben können. Oracle Data Guard verwaltet diese Standbydatenbanken als Kopien der Produktionsdatenbank. Wenn die Produktionsdatenbank dann aufgrund eines geplanten oder ungeplanten Ausfalls nicht mehr verfügbar ist, kann Oracle Data Guard jede Standbydatenbank auf die Produktionsrolle umstellen und die mit dem Ausfall verbundene Ausfallzeit minimieren.

Hinweise

Berücksichtigen Sie beim Entwurf der Topologie die folgenden Faktoren:

  • Performance

    Um die beste Performance zu erzielen, wählen Sie die richtige Compute-Ausprägung mit der entsprechenden Bandbreite aus.

  • Sicherheit

    Verwenden Sie Policys, um einzuschränken, wer auf die OCI-Ressourcen Ihres Unternehmens zugreifen kann und wie diese darauf zugreifen können. Die Verschlüsselung ist standardmäßig für OCI Object Storage aktiviert und kann nicht deaktiviert werden.

  • Verfügbarkeit

    Sie sollten eine High Availability-Option verwenden, die auf Ihren Deployment-Anforderungen und Ihrer Region basiert. Die Optionen umfassen die Verwendung mehrerer Availability-Domains in einer Region und die Verwendung von Faultdomains.

  • Disaster Recovery

    Es wird empfohlen, dass Kunden, die mehr als 300 Workstations verwenden, die ihren Service nutzen, eine Disaster-Recovery-Umgebung mit regionsübergreifender Volume-Replikation erstellen (siehe "Weitere Informationen") und Oracle Data Guard verwenden.

  • Kostenfaktor

    Eine Oracle Exadata Database Service-Instanz stellt die erforderliche CPU-Leistung zu höheren Kosten bereit. Bewerten Sie Ihre Anforderungen, um eine Möglichkeit zur vertikalen und horizontalen CPU-Skalierung zu wählen (Änderung bei Hot und ohne Ausfallzeit).

  • Größen-Tipps

    Im Folgenden finden Sie die verwendete Größe, die auf einem Kundenreferenzfall basiert und nur zu Informationszwecken dargestellt wird. Denken Sie daran, dass alle Größen und Architekturen zusammen mit von Philips Healthcare genehmigten Teams erstellt werden müssen.

Sessions Schriftgrad Umg. Rolle Anzahl VMs # OCPUs ANZAHL MEM (GB) Anzahl Datenträger (GB) VM-Ausprägungen OCPU gesamt MEM gesamt (GB) Gesamter Datenträger (GB) Knoten (Single/RAC) ANZ. OCPU DB OCPUs-DB gesamt Anzahl DB-Datenträger (GB) Flexibles Load Balancing
100 Benutzer S PROD Philips-App-Manager 2 4 48 150 VM.Standard.E4.Flex 8 96 300 1 4 4 712 1
300 Benutzer M PROD Philips-App-Manager 2 4 48 150 VM.Standard.E4.Flex 8 96 300 1 6 6 968 1
500 Benutzer L PROD Philips-App-Manager 4 4 48 150 VM.Standard.E4.Flex 16 192 600 1 8 8 1736 1
700 Benutzer XL PROD Philips-App-Manager 6 4 48 150 VM.Standard.E4.Flex 24 (288) 900 2 10 20 2760 1
1000 Benutzer 2XL PROD Philips-App-Manager 8 4 48 150 VM.Standard.E4.Flex 32 384 1200 2 10 20 5320 1
1200 Benutzer 3XL PROD Philips-App-Manager 12 4 48 150 VM.Standard.E4.Flex 48 (576) (1800) 2 12 24 10440 1
1500 Benutzer 4XL PROD Philips-App-Manager 14 4 48 150 VM.Standard.E4.Flex (56) (672) (2100) 2 14 28 16584 1
100 Benutzer S PROD Tomcat-Integration - WSI 1 4 4 150 VM.Standard.E4.Flex 4 4 150 -- -- -- -- --
Mehr als 100 Benutzer -- PROD Tomcat-Integration - WSI 1 8 32 150 VM.Standard.E4.Flex 8 32 150 -- -- -- -- --
100 Benutzer S PROD Integrations-TIE 1 4 4 150 VM.Standard.E4.Flex 4 4 150 -- -- -- -- --
Mehr als 100 Benutzer -- PROD Integrations-TIE 1 8 32 150 VM.Standard.E4.Flex 8 32 150 -- -- -- -- --
100 Benutzer S Fragen und Antworten Philips-App-Manager 1 4 48 150 VM.Standard.E4.Flex 4 48 150 1 4 4 712 --
100 Benutzer S Fragen und Antworten Tomcat-Integrationswebservice 1 4 16 150 VM.Standard.E4.Flex 4 16 150 -- -- -- -- --

Hinweis:

Verwenden Sie die Bildlaufleiste am Ende dieser Tabelle, um ausgeblendete Spalten anzuzeigen.

Bestätigungen

Authors: Diego Mariano, Lucas Fernandes

Contributors: Guilherme Teló, John Sulyok