Implement the Philips Tasy Healthcare System
The Philips Tasy EMR HTML5 (Tasy EMR) is a cutting-edge, web-based electronic medical records (EMR) system developed by Philips Healthcare. This sophisticated software serves as a medical device platform designed to manage both clinical and non-clinical data within healthcare settings.
While it functions as a standalone system, it also offers seamless integration capabilities with other medical systems. This flexibility allows multiple users from various healthcare disciplines to access and utilize the platform, making it highly adaptable and suitable for enhancing healthcare efficiency and quality. The primary mission of the Tasy EMR system is to ensure the precise and secure documentation of patient information.
Tasy EMR is a multi-tier application, running on the robust Oracle database, with extensive utilization of PL/SQL routines. Its user-friendly HTML5 front-end is built using AngularJS technology. Communication between the client and server sides occurs through SOAP/REST web services.
Architecture
This architecture features the Tasy EMR healthcare system.
Key components of the Tasy EMR architecture are:
- Client layer
- Tasy EMR HTML5: This web-based client application operates seamlessly within the Google Chrome browser. It communicates with the Tasy EMR web service through representational state transfer (REST) requests, employing a proprietary API.
- Integrations: Tasy EMR can seamlessly integrate with any equipment that uses HL7, SOAP, REST requests, or even simple file exchanges stored in shared locations.
- Server layer
- Application server: Tasy collaborates with application servers such as Apache Tomcat and Oracle WebLogic Server to host its middleware components. When Tomcat is chosen, customers have the option to utilize the Philips app-manager platforms, providing integrated application containers built on Tomcat for enhanced performance.
- Tasy EMR web service: This pivotal web service is responsible for receiving, processing, and responding to all requests initiated by Tasy EMR users.
- Tasy EMR Reports web service: The Reports web service is exclusively tasked with generating system reports. It operates in a segregated environment and is only called upon by the Tasy EMR web service for report generation.
- Integration web service: Handling all integration requirements for Tasy EMR, this versatile service accommodates HL7, SOAP, REST, and file-based integrations. It manages all incoming and outgoing messages.
- Load balancers: Utilizing Oracle Cloud Infrastructure Load Balancing in tandem with two servers on compute instances running Oracle Linux 8, the system employs the HAProxy market product for robust application load balancing, ensuring high availability.
- Oracle Database layer: Serving as the backbone of Tasy EMR, this database stores all system information, including the majority of business rules encoded in the form of PL/SQL objects. The recommended and homologated version is Oracle Database 19c, with support for 12 and 11, along with the inclusion of MDS.
Note:
For projects involving more than 1,500 connected users, Philips strongly advises customers to engage with one of its approved infrastructure partners. Contact information for these partners can be obtained from the commercial department.Note:
For customers with more than 300 workstations consuming its service, Philips's documentation recommends high availability infrastructure at all layers: balancing, application servers, and database.
philips-tasy-diagram-oracle.zip
This image shows a three-tier topology consisting of a load balancer, application tier, and an Oracle Exadata Database Service to support a database. All the resources are deployed in a single availability domain in an OCI region. The load balancer tier and application tier are isolated in separate subnets within a single VCN. Network security groups regulate the network traffic to and from the resources in each tier. A route table attached to each subnet contains rules to direct traffic destined for targets outside the VCN.
- Client requests flow in through an internet gateway to WAF and primary load balancer, which distributes the requests to the secondary load balance tier, which sends the request to the application tier.
- The application tier consists of compute instances. The compute instances are distributed evenly across all the fault domains in the availability domain. All the compute instances in the application tier are attached to a private subnet.
- The database tier consists of an Oracle Exadata Database Service database attached to a private subnet in a separate VCN.
The architecture has the following components:
- Tenancy
A tenancy is a secure and isolated partition that Oracle sets up within Oracle Cloud when you sign up for Oracle Cloud Infrastructure. You can create, organize, and administer your resources in Oracle Cloud within your tenancy. A tenancy is synonymous with a company or organization. Usually, a company will have a single tenancy and reflect its organizational structure within that tenancy. A single tenancy is usually associated with a single subscription, and a single subscription usually only has one tenancy.
- Region
An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
- Compartment
Compartments are cross-region logical partitions within an Oracle Cloud Infrastructure tenancy. Use compartments to organize your resources in Oracle Cloud, control access to the resources, and set usage quotas. To control access to the resources in a given compartment, you define policies that specify who can access the resources and what actions they can perform.
- Availability domains
Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.
- Fault domains
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.
- Virtual cloud network (VCN) and subnets
A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.
- Service gateway
The service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet.
- Cloud Guard
You can use Oracle Cloud Guard to monitor and maintain the security of your resources in Oracle Cloud Infrastructure. Cloud Guard uses detector recipes that you can define to examine your resources for security weaknesses and to monitor operators and users for risky activities. When any misconfiguration or insecure activity is detected, Cloud Guard recommends corrective actions and assists with taking those actions, based on responder recipes that you can define.
- Object storage
Object storage provides quick access to large amounts of structured and unstructured data of any content type, including database backups, analytic data, and rich content such as images and videos. You can safely and securely store and then retrieve data directly from the internet or from within the cloud platform. You can seamlessly scale storage without experiencing any degradation in performance or service reliability. Use standard storage for "hot" storage that you need to access quickly, immediately, and frequently. Use archive storage for "cold" storage that you retain for long periods of time and seldom or rarely access.
- Dynamic routing gateway (DRG)
The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.
- FastConnect
Oracle Cloud Infrastructure FastConnect provides an easy way to create a dedicated, private connection between your data center and Oracle Cloud Infrastructure. FastConnect provides higher-bandwidth options and a more reliable networking experience when compared with internet-based connections.
- Exadata Database Service
Oracle Exadata Database Service enables you to leverage the power of Exadata in the cloud. You can provision flexible X8M and X9M systems that allow you to add database compute servers and storage servers to your system as your needs grow. X8M and X9M systems offer RDMA over Converged Ethernet (RoCE) networking for high bandwidth and low latency, persistent memory (PMEM) modules, and intelligent Exadata software. You can provision X8M and X9M systems by using a shape that's equivalent to a quarter-rack X8 and X9M system, and then add database and storage servers at any time after provisioning.
Oracle Exadata Database Service on Dedicated Infrastructure provides Oracle Exadata Database Machine as a service in an Oracle Cloud Infrastructure (OCI) data center. The Oracle Exadata Database Service on Dedicated Infrastructure instance is a virtual machine (VM) cluster that resides on Exadata racks in an OCI region.
Oracle Exadata Database Service on Cloud@Customer provides Oracle Exadata Database Service that is hosted in your data center.
- Security list
For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.
- Block volume
With block storage volumes, you can create, attach, connect, and move storage volumes, and change volume performance to meet your storage, performance, and application requirements. After you attach and connect a volume to an instance, you can use the volume like a regular hard drive. You can also disconnect a volume and attach it to another instance without losing data.
Recommendations
- VCN
When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.
Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.
After you create a VCN, you can change, add, and remove its CIDR blocks.
When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.
- Cloud Guard
Clone and customize the default recipes provided by Oracle to create custom detector and responder recipes. These recipes enable you to specify what type of security violations generate a warning and what actions are allowed to be performed on them. For example, you might want to detect Object Storage buckets that have visibility set to public.
Apply Cloud Guard at the tenancy level to cover the broadest scope and to reduce the administrative burden of maintaining multiple configurations.
You can also use the Managed List feature to apply certain configurations to detectors.
- Security Zones
For resources that require maximum security, Oracle recommends that you use security zones. A security zone is a compartment associated with an Oracle-defined recipe of security policies that are based on best practices. For example, the resources in a security zone must not be accessible from the public internet and they must be encrypted using customer-managed keys. When you create and update resources in a security zone, Oracle Cloud Infrastructure validates the operations against the policies in the security-zone recipe, and denies operations that violate any of the policies.
- Network security groups (NSGs)
You can use NSGs to define a set of ingress and egress rules that apply to specific VNICs. We recommend using NSGs rather than security lists, because NSGs enable you to separate the VCN's subnet architecture from the security requirements of your application.
- Load balancer bandwidth
While creating the load balancer, you can either select a predefined shape that provides a fixed bandwidth, or specify a custom (flexible) shape where you set a bandwidth range and let the service scale the bandwidth automatically based on traffic patterns. With either approach, you can change the shape at any time after creating the load balancer.
- Block volumes backup policy
Configure a policy to take backups of the block volumes as frequently as necessary to meet your RPO.
- Data Guard
Oracle Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to remain available without interruption. Oracle Data Guard maintains these standby databases as copies of the production database. Then, if the production database becomes unavailable because of a planned or an unplanned outage, Oracle Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage.
Considerations
When design the topology, consider the following factors.
- Performance
To get the best performance, choose the correct compute shape with appropriate bandwidth.
- Security
Use policies to restrict who can access the OCI resources that your company has, and how they can access them. Encryption is enabled for OCI Object Storage by default and can’t be turned off.
- Availability
Consider using a high-availability option based on your deployment requirements and region. Options include using multiple availability domains in a region and using fault domains.
- Disaster recovery
It is recommended that customers that use more than 300 workstations consuming its service create a disaster recovery environment using cross region volume replication (see Explore More) and using Oracle Data Guard.
- Cost
An Oracle Exadata Database Service instance provides the necessary CPU power for a higher cost. Evaluate your requirements to choose a way to use CPU scale up and scale down (change on hot, without down time).
- Sizing tips
Below is the sizing used, based on a customer reference case, and presented for informational purposes only. Remember that all sizing and architecture must be created together with teams approved by Philips Healthcare.
| Sessions | Size | Env | Role | # VMs | # OCPUs | # MEM (GB) | # Disk (GB) | VM Shape | Total OCPU | Total MEM (GB) | Total Disk (GB) | Nodes (Single/RAC) | # OCPU DB | Total OCPUs DB | # Disk (GB) DB | Flexible Load Balancing |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 100 Users | S | PROD | Philips-App-Manager | 2 | 4 | 48 | 150 | VM.Standard.E4.Flex | 8 | 96 | 300 | 1 | 4 | 4 | 712 | 1 |
| 300 Users | M | PROD | Philips-App-Manager | 2 | 4 | 48 | 150 | VM.Standard.E4.Flex | 8 | 96 | 300 | 1 | 6 | 6 | 968 | 1 |
| 500 Users | L | PROD | Philips-App-Manager | 4 | 4 | 48 | 150 | VM.Standard.E4.Flex | 16 | 192 | 600 | 1 | 8 | 8 | 1736 | 1 |
| 700 Users | XL | PROD | Philips-App-Manager | 6 | 4 | 48 | 150 | VM.Standard.E4.Flex | 24 | 288 | 900 | 2 | 10 | 20 | 2760 | 1 |
| 1000 Users | 2XL | PROD | Philips-App-Manager | 8 | 4 | 48 | 150 | VM.Standard.E4.Flex | 32 | 384 | 1200 | 2 | 10 | 20 | 5320 | 1 |
| 1200 Users | 3XL | PROD | Philips-App-Manager | 12 | 4 | 48 | 150 | VM.Standard.E4.Flex | 48 | 576 | 1800 | 2 | 12 | 24 | 10440 | 1 |
| 1500 Users | 4XL | PROD | Philips-App-Manager | 14 | 4 | 48 | 150 | VM.Standard.E4.Flex | 56 | 672 | 2100 | 2 | 14 | 28 | 16584 | 1 |
| 100 Users | S | PROD | Tomcat Integration WSI | 1 | 4 | 4 | 150 | VM.Standard.E4.Flex | 4 | 4 | 150 | -- | -- | -- | -- | -- |
| More than 100 users | -- | PROD | Tomcat Integration WSI | 1 | 8 | 32 | 150 | VM.Standard.E4.Flex | 8 | 32 | 150 | -- | -- | -- | -- | -- |
| 100 Users | S | PROD | Integration TIE | 1 | 4 | 4 | 150 | VM.Standard.E4.Flex | 4 | 4 | 150 | -- | -- | -- | -- | -- |
| More than 100 users | -- | PROD | Integration TIE | 1 | 8 | 32 | 150 | VM.Standard.E4.Flex | 8 | 32 | 150 | -- | -- | -- | -- | -- |
| 100 Users | S | QA | Philips-App-Manager | 1 | 4 | 48 | 150 | VM.Standard.E4.Flex | 4 | 48 | 150 | 1 | 4 | 4 | 712 | -- |
| 100 Users | S | QA | Tomcat Integration Web Service | 1 | 4 | 16 | 150 | VM.Standard.E4.Flex | 4 | 16 | 150 | -- | -- | -- | -- | -- |
Note:
Use the scroll bar at the bottom of this table to view hidden columns.Explore More
Learn more about the features of this architecture.
Review these additional resources:
- Best practices framework for Oracle Cloud Infrastructure
- Oracle Cloud Infrastructure Documentation
- Oracle Cloud Cost Estimator
- Replicating a Volume
- Deploy Oracle Exadata Database Service with Data Guard in a single region
- Best practices for protecting your cloud topology against disasters
- Configure cross-region private connectivity between tenancies
- Deploy a highly available web application