Online Health Services Company (OHSco)

(Draft Version 0.1)

 Document Purpose

This document describes the basic working of the Online Health Services
Company.

It covers the functional and non-functional requirements and the technical

architecture of the system
3

Agenda

Section
1. Project Information

1.1 Introduction

1.2 Team Information

1.3 Timelines

2. Requirements

2.1 Functional Requirements

2.2 NFRs

3. Architecture

3.1 System Context

3.2 Architecture Overview

4. Bill of Materials

4.1 SW Bill of Materials

4.2 HW Bill of Materials

4

1. Project Information

1.1. Introduction

An online application platform connecting patients with Physicians, through a computer, smart phone or
telephone, and facilitating referrals for allied medical services such as, Pharmacy, pathology,
radiology etc. This service will cover primary care and limited secondary care as other services will
not be manageable online.

In urban areas, optional home health support will be provided to ensure that services requiring physical
interaction and / or allied services can be provided.

In rural areas or poor income urban areas, Health Kiosk providing Nursing facilitation for initial vital
signs, online consultation, organizing laboratory / pharmacy will be the delivery model.

Patient Medical Record will be kept / generated electronically.

5

1.2. Team Information

Business Unit Involvement

Partner Involvement

Client Team Members

6

1.3. Tentative Project Implementation Time Lines (This is a place holder slide –
to be modified for actual timelines)

Month 1 Month 3 Month 6 Month 9

Use case Model development

A and deployment Model development

B Pre-installation Model calibration

C Physical Installation

Software implementation
and integration

D Integration

Testing and
E Testing and Commissioning commissioning
7

2. Major Functional and Non-Functional

Requirements
8

2.1. Functional Requirements

Requirement 1 Doctor Registration
Actor Doctor – Permanent Staf
Function This function creates a USER record for the doctor in the system database with required parameters and
creates a user ID in the authentication system with pre-defined login credentials and role based access control
on the system and data
Description Registration of a new doctor in the system as a practitioner with details on:
-Doctor name
-Specialization
-Gender
-Qualifications (copies of certificates uploaded)
-Years of experience
-Age/Date of Birth
-Organizations/hospitals with whom past experience
-Physical location (time zone) and address
-If available for physical visits (y/n)
-Practicing days for OHSco
-Practicing times for OHSco
-Compensation
-Days of year unavailable
-Access required to labs and pharmacy systems (by role)
-Preferred devices in use
-NTN
-Nadra issued Civil ID No
-Email ID
-Doctor is issued a userid and password
-Doctor is issued an OHSco email ID
9

2.1. Functional Requirements

Requirement 2 Doctor Registration – self service (possibly future requirement for consulting doctors)
Actor Consulting Doctor – Non-Permanent Staf
Function This function creates a USER record for the consulting doctor in the system database with required parameters
and creates a user ID in the authentication system with pre-defined login credentials and role based access
control on the system and data
Description Self service Registration of a new doctor in the system as a consultant with details on:
-Doctor name
-Specialization
-Gender
-Qualifications (copies of certificates uploaded)
-Years of experience
-Age/ Date of Birth
-Organizations/hospitals with whom past experience
-Physical location (time zone) and address
-If available for physical visits (y/n)
-Practicing days for OHSco
-Practicing times for OHSco
-Compensation /Commission
-Days of year unavailable
-Access required to labs and pharmacy systems (by role)
-Preferred devices in use
-NTN
-Nadra issued Civil ID No
-Email ID
-Doctor is issued a userid and password
-Doctor is issued an OHSco email ID
1
0

2.1. Functional Requirements

Requirement 3 Patient Registration – self service
Actor Patients
Function This function creates a USER record for the patient in the system database with required parameters and
creates a user ID in the authentication system with pre-defined login credentials and role based access control
on the system and patient’s own data
Description Self service Registration of a new patient in the system with details on:
-Patient name
-Gender
-Age / Date of Birth
-Physical Location
-Medical history records (to be uploaded if available)
-Medical conditions (if any)
-Allergy information (if available)
-Medical insurance information (if available)
-Preferred devices in use
-Payment information (credit card, m-payment, online bank tx)
-Email ID
-Patient is issued a userid and password
1
1

2.1. Functional Requirements

Requirement 4 Doctors’ Diary
Actor All Doctors
Function This function creates diary function for all practicing doctors. It automatically marks any appointments
accepted by doctors as busy. In addition, it allows doctors to manually mark timeslots busy if they want.
Description Diary function for all doctors allows to:
-Automatically mark time for any appointments accepted by doctors as busy
-Allows doctors to manually mark timeslots busy if they want
-Synchronizes the calendar with doctor’s workstation and their mobile devices
-Alerts the doctor on upcoming appointments at a pre-set time (10 minutes ??) before the appointment
1
2

2.1. Functional Requirements

Requirement 5 Patient Appointment booking (with mobile app extension)
Actor Patients
Function This function allows the patient to request a timeslot for an appointment with one of the practicing doctors in
the system
Description Self service appointment request:
-Patient logs in with credentials issued at time of registration
-Selects a medical condition from a list of drop down options
-If drop down does not have condition listed, enters in a free form text field
-System recommends a doctor based on condition entered. Patient can override and select the doctor
manually
-Patients selects whether required appointment is online or physical
-System lists the timeslots (whether online or physical) available for the selected doctor
-Patient selects an available timeslot
-System confirms the appointment through an email
-System blocks the calendar for the practicing doctor for the chosen timeslot
-System sends a reminder email 4 hours (??) before the time of the appointment
-Patient can cancel the appointment more than 48 hours before the appointment
-System charges the patient when the appointment booked is less than 48 hours away (?? TBD)
1
3

2.1. Functional Requirements

Requirement 6 Patient Appointment Execution (with mobile app extension)
Actor Patients + Doctors
Function This function allows the patient and the Doctor to have the online consultation session at the pre-booked
timeslot
Description Consultation session (Doctors side):
-Doctor logs in with credentials issued at the time of registration (if not already logged in)
-Next appointment window pops up 5 minutes in advance of the appointment with text details on the patient
(name, age, gender, medical condition entered by patient at time of booking appointment with a link to
patient medical records if available.
-If doctor wants, he can click the link to patient medical records (if available)
-When the patient logs in, Doctor sees patient name in a sametime window. Doctor clicks the patient name to
open a two way video and audio communications session
-Doctor has a whiteboard app visible to patient onscreen in case doctor wants to explain something to the
patient or write something for the patient.
-For medicines requiring medical prescription, a digitally signed prescription can be emailed to the patient.
System to add and keep details of prescribed medicines in patient history.
-System can initiate a request to the online affiliated pharmacy for home delivery of prescribed drugs

-Consultation session (Patient’s side):

-Patient logs in with credentials issued at time of registration
-Patient sees a pop-up video window with the practicing doctor with two-way video and audio
communications.
-(Future Req: USB connected medical devices for weight, heart rate, blood pressure on the patient side)
-Patient communicates with the doctor and ends the session after the consultation
-Log the patient visit with details on doctor consulted, medicines prescribed, test suggested, etc
1
4

2.1. Functional Requirements

Requirement 7 Payment module
Actor Patients
Function This function allows the patient to make the online payment
Description Patient side:
-Integration with an online payment gateway for acceptance of credit cards
-Integration with m-payment systems from mobile phone operators (ezpaisa, mobicash, Upaise etc) for
payment through mobile phones
-Payment with 1link for online payment through the banks
-Patients can pay each time before the consultation visit or maintain an account with the hospital and use
from that credit
-Note: If patient credit card information is maintained in the system, consider PCI-DSS requirements for data
security.
1
5

2.1. Functional Requirements

Requirement 8 Financial Module
Actor All
Function This function covers the financial aspects of the hospital
Description This module is to cover all financial aspects of the hospital including revenue and expense management,
salaries, fixed and variable costs. It is not possible to cover all details in this section, but a pre-built module for
an existing hospital with some modifications can be used in order to simplify and address this requirement
1
6

2.1. Functional Requirements

Requirement 9 Pharmacy Integration
Actor Doctors + Partner Pharmacy
Function Medicine prescription delivery through a network of pharmacies
Description Pharmacy integration:
-Capability to push a prescription to the nearest pharmacy depending on the patient location
-If the pharmacy has an online system, this can be done through web services. If not, a push email with
patient name and address and prescription details
-System to initiate a Y/N clickable confirmation request to the patient whether medicines have been received
-Pharmacy to have a user interface where they can upload their inventory and medicine prices
-System to calculate accounts payable to every pharmacy end of every month (or week?? Depending on AP
policy)
-System to make an online payment to pharmacies based on monthly (or weekly) account payable

To be discussed
1
7

2.1. Functional Requirements

Requirement 10 Medical Labs Integration
Actor Doctors + Partner Labs
Function Prescribed tests through a network of affiliated labs
Description Lab integration:
-Capability to push a Lab test requirement to the nearest medical lab depending on the patient location
-If the Lab has an online system, this can be done through web services. If not, a push email with patient
name and address and test details
-System to initiate a Y/N clickable confirmation request to patient whether tests have been performed
-Lab to have a user interface where they can upload their list of test and charges
-System to calculate accounts payable to every Lab end of every month (or week?? Depending on AP policy)
-System to make an online payment to Labs based on monthly (or weekly) account payable
-Labs to upload medical test results to the OHSco system

To be discussed
1
8

2.1. Functional Requirements

Requirement 11 HR Module
Actor All
Function This function covers the HR part of the hospital
Description This module is to cover all HR aspects of the hospital including employee on-boarding, life cycle management,
compensation and payroll, etc. This module needs to be integrated with the financials module for HR expense
management. It is not possible to cover all details in this section, but a pre-built module for an existing
hospital with some modifications can be used in order to simplify and address this requirement
1
9

2.1. Functional Requirements

Requirement 11 Electronic Medical Records
Actor Patients + Doctors
Function Maintain electronic medical records for patients
Description System to maintain electronic medical records including:
-Patient history in text form in a relational database
-Patient medical test reports and images in a content management system tagged with patient EMR in the
database for performance reasons.
-Capability for the patient to upload their own medical records against their account
-Capability for the doctor to view medical records of patients on demand
-Conforming to HL7 International standard
2
0

2.1. Functional Requirements

Requirement 12 Telehealth Training Module
Actor Doctors
Function Train doctors on Telehealth sessions
Description System to contain a self-learning module on the functions and features of the telehealth session with a walk
through of the screen, the diferent links and buttons that are to be used for diferent functions, the etiquettes
of online virtual health care and familiarity with the online video sessions.

This module can also be used to support an instructor led training session
2
1

2.1. Functional Requirements

Requirement 13 Patient Medical History
Actor Patients + Doctors
Function View medical history of patients
Description On logging in, patients should be able to view their medical history including:
-Their medical visits
-Doctors they have seen in the past
-Medication they have been prescribed and have been taking
-Medical tests they have done and their results
Doctors should also be able to view medical history of their patients
2
2

2.1. Functional Requirements

Requirement 14 Medical session recording
Actor Hospital administrative staf
Function Review medical session for quality control
Description The system to allow recording function for the consultancy sessions in order for the hospital administrative
staf to perform random quality check on the program, and review doctor performance.

This function is also important to address any complaints filed by the patients for misbehaviour.
2
3

2.1. Functional Requirements

Additional Integration with insurance companies and corporate clients
Requirements to
be considered in
future
Actor
Function
Description
2
4

2.2. Nonfunctional Requirements

ID Non Functional Requirement Description
1 Number of Users. The total number of users for capacity planning to start with will be as under:
-Administrative users – 5
-Hospital administration – 15 (scalable to 50)
-Doctors – 100 (scalable to 500)
-Patients – 5,000 (scalable to 50,000)
2 Connectivity. Fault tolerant connectivity to connect:
-Doctors at high bandwidth connection for video sessions
-Patients at high bandwidth connection for video sessions
-(each video session estimated at 500kbps, with 100 concurrent sessions, required bandwidth ~
50Mbps for the back end video server hosts)
-A dedicated bandwidth of another 50Mbps for the EMR system for medical image viewing
-For remaining servers, a 4Gbps connection for application interface.
3 Security. The Solution will provide information security with authorization and authentication of users
through role-based access control. In addition, the servers that access the Internet must be segregated
in networks by firewalls, a DeMilitared Zone.
SSL certificates are required to authenticate a user accessing the Solution through HTTP protocol and
must be implemented on the edge of the network hosting the Solution. If credit card information is to be
stored in OHSco DB, PCI DSS compliance required.
4 Availability. The solution to provide high availability within the data center and disaster recovery outside the data
center in order to ensure continuous services
2
5

2.2. Nonfunctional Requirements

ID Non Functional Requirement Description

4 Data Retention/Lifecycle. The solution will generate large amounts of data (specifically images and
video). This data is to be retained for xxx weeks online for forensic purposes before de-staged to
nearline/offline media. The data gets retired after xx months for nearline/offline space to be reclaimed
Duration to be discussed

5 Monitoring. The main components of the Solution – portal server, application and integration server, database,
and collaboration and directory applications – will be monitored by automated tool that monitors availability of
these components and performance of critical applications.

6 User workstations/printers/scanners. OHSco user front end equipment to be provided as part of the
solution
2
6

3. Solution Design
2
7

3.1. System IT Context Diagram

Corporate clients External

DSL/3G/4G doctors
/LTE
HTTPS
HTTP/S XMPP
Web Services Telephone
Telephone email
email
HTTP/S
DSL/3G/4G Internal doctors
/LTE
Insurance company HTTP/S XMPP
Web Services Telephone
Telephone OHSco email
email

HTTPS
intranet OHSco
HTTP/S
Web Services DSL/3G/4G administrative
Telephone /LTE staf
email HTTPS HTTP/S
Partner lab XMPP Web Services
Telephone Telephone
Email email

Partner pharmacy
patients
 3.2 Architecture Overview

Directory
server
http
http cluster
Computer
firewall
pharmacy
workstation firewall Messaging/
smartphone
calendaring
App Srvr services
App Srvr Medical
Cluster (Java)
tablet Cluster (Java) labs
Integration
users services
Video firewall Corporate
firewall
services clients
platform
Insurance
Mobile
Database Cluster (dual node) Content companies
device
rendering mgmt
Backend
platform Patient records system
External
Entities
Reporting Doctor schedules Content Store (web services)
server
Appointment schedules EMRs

financials Session recodrings

HR DB Payment
Payment gateway
Cloud hosted server
infrastructure
2
9

4. Project Bill of Materials

Note on development considerations:

-Consider Java or PHP for development environment. Java scales well
and is enterprise class. Also, is supported by enterprise class web
application servers. Cost is higher
-PHP is cost efective. Does it scale well to support thousands of
concurrent users and video platform? If yes, platform of choice will be PHP
Otherwise Java
3
0

4.1. Products BOM (Software or equivalent) (draft)

ID HW/SW Description
1 SW WebSphere Application Server or Tomcat

2 SW IBM Integration Bus

3 SW IBM DB2 Enterprise Server or MySQL
4 SW Lotus Domino
5 SW Lotus Domino (SMTP Gateway)
6 SW Lotus Sametime
7 SW Tivoli Directory Server
8 SW IBM Tivoli Monitoring
9 SW SmartCloud Application Performance Monitoring
10 SW IBM HTTP Server or Apache
11 SW Cognos Enterprise
3
1

4.1. Products BOM (Software) (draft)

ID HW/SW Description
13 SW Filenet
14 SW Video services platform
15 SW SSL Certs for VPN
3
2

4.2. Products Bill of Materials (HW) (draft)

ID HW/SW Description
1 HW Server, IBM Flex System with Power and Intel nodes for the
IBM and non-IBM SW stack
(sizing to be done after volumetric information, e.g user count etc is finalized)

2 HW Storage, IBM StorWize v7000 with remote replication

(sizing to be done once volumetric information e.g duration for the video data to be
retained online/nearline

3 HW Storage, IBM TS3500 Tape Library with LTO6 Drives

(sizing to be done once volumetric information e.g duration for the video data to be
retained offline

4 HW (Network equipment (CISCO or Juniper)

(Routers, switches and firewalls as per the number of ports required by the servers
and external connections. Firewalls supporting virtualization. Consider SDN??)

5 HW Personal Workstations
(Intel based personal computers (consider thin clients with a VDI solution??))

6 HW Printers and Scanners

(Qty and specs to be finalized)
 smartphone

Virtual visit registration

Internet Web Internet

Over 3G or DSL portal Over 3G or DSL
tablet

App
schedule
appointment server

Patient
records
computer
Doctor
schedules

registration Appointment Virtual consulting

schedules

financials
Payment
Cloud hosted gateway
infrastructure External system