Provider Taxonomy — Patient Appointment Scheduler

A system analysis and design project.

Table of Contents

· Introduction
∘ Functional Requirements
∘ Non-Functional Requirements.
∘ Use Case Diagram
∘ Logical ER Diagram
∘ Physical ER Diagram
∘ Context Diagram
∘ Level 0 — Logical Dataflow Diagram
∘ Level 0 — Physical Dataflow Diagram
∘ Level 1- Logical Dataflow Diagram
· Design and Prototyping
∘ Architecture

Introduction

The problem of patient access to healthcare services is a major issue, with patients often struggling to find a healthcare provider that specializes in their condition and facing long wait times for appointments. Call center agents attempt to pair patients with appropriate providers at nearby locations as quickly as possible but are limited by the data available in the Electronic Health Record (EHR). To address this, call centers often create their own databases of provider data, but these are time-consuming to update and not easily accessible by other departments.

To solve these issues, we have proposed to develop a custom-built provider taxonomy application, with administrative functionality and smart searching capability for agents, that synchronizes with existing provider data and can be easily updated with new data points from the EHR. The benefits would include decreased time on the phone with patients, increased patient satisfaction with scheduling, and improved utilization of appointment schedules.

It is proposed that it synchronize both ways with existing provider data from the Enterprise Data Warehouse to facilitate maintenance of the taxonomy and to provide for secondary use of the taxonomy data by other departments. The application would have a flexible data architecture to facilitate consuming of EHR provider data as new data points are released by the vendor. Most importantly the speed would be significantly improved. Some targeted benefits would be decreased time on phone with each patient, increased patient satisfaction with the scheduling process and improved utilization of vacancies in the appointment schedule per provider.

Functional Requirements

• Care Navigation Data Administrators must be able to see a list of new providers to be able to fill out add taxonomy data for those providers.
• Care Navigation Data Administrators must be able to see a list of change requests from providers who want their taxonomy profile updated.
• Care Navigation Data Administrators must be able to see a list of providers leaving the system so those profiles can be inactivated.
• Care Navigation Call Agents must be able to see a search provider profiles by condition/body part treated, reason for visit, visit type (virtual, in person), department, Center(location), current provider practice status (taking new patients, etc.?)
• Taxonomy Datamart Users must be able to access the taxonomy DataMart for secondary use of the data.
• Medical Providers must be able to view their taxonomy profile.
• Medical Providers must be able to submit a request for changes to their taxonomy profile.
• Call center software must connect to the Taxonomy app and pass the patient id to it after a phone call from the patient is connected.

Non-Functional Requirements.

• Taxonomy Tool should have call agent functionality uptime of 99.999 during 6AM-9PM.
• Application database should update daily from EMR provider profile to ensure that the search functionality is up to date.
• Taxonomy user interface must be intuitive and easy to use.
• Taxonomy search should return within 2 seconds.

Use Case Diagram

Logical ER Diagram

Physical ER Diagram

Context Diagram

Level 0 — Logical Dataflow Diagram

Level 0 — Physical Dataflow Diagram

Level 1- Logical Dataflow Diagram

Design and Prototyping

Architecture

The software platform will be built on Node.js. The webservers will each be Windows Server 2022 running on VMs. The VMs will run on VMware installed on an ESXi host that is connected to a Pure storage array. The ESXi host will be shared between 2 VMs. Windows Server Failover Clustering will be used between the 2-web server VMs. The Node.js code will consume restful web services that connect with the database. The database will be an Oracle RAC system with 3 Linux nodes. All of this will live on-premises in an ultramodern data center that already houses the EHR (Electronic Health Record) and other patient/provider centric applications.

Availability and Reliability

The software, web servers, and database will have 24-hour monitoring and IT support teams that respond to alerts. All the infrastructure will be replicated to a Disaster Recovery Data-Center located in a different geographic region. The database logs are shipped every 5 minutes to the Disaster Recovery Database and applied to enable data redundancy and keep data in sync between both data centers.

Technical Environment

• ESXi Host: 32GB RAM, 32 core CPU. This host will have 2 web server VMs on it (each VM will have 16GB Ram and 16 CPU allocated).
• Database Servers: Linux blades (3) with 16GB RAM each and 8 core CPU.

Performance and Speed

The sizing of the web servers and database should allow up to 1000 concurrent users. The maximum expected concurrent users is 800with the average concurrent users expected to be about 300. The 3 node Oracle RAC will return data quickly so that patients don’t have to wait. Hosts can be scaled according to the concurrency requirement.

Security

Both data centers are surrounded by a “Clinical” firewall that prevents any traffic from the world wide web. Anyone connecting to the Taxonomy application will need to either be on premises or connect through the corporate VPN. Ports and IPs of the web servers and database will need to be whitelisted to allow for SQL traffic from the web servers.

Encryption and Authentication

All data will be encrypted at rest and in transit. In transit will use a TLS certificate with a 2048-bit key. Data at rest will use AES. Authentication will be through Microsoft AD (Active Directory).

Data Storage

Oracle RAC database will be connected to an existing Pure Storage array which will manage all table spaces. Pure storage delivers an extra nine level of reliability, out to 6 nines. It also does data compression and data deduplication.