SanteSuite Help Portal
  • SanteSuite Help Portal
    • Disclaimer
  • Product Overview
    • SanteSuite Products
      • Introducing SanteDB CDR
        • SanteDB Solutions
      • Master Patient Index - SanteMPI
      • Immunization Management System - SanteIMS
      • Privacy & Security - SanteGuard
    • SanteDB Versions
  • Architecture
    • SanteDB Architecture
      • SanteDB History
    • Solution Architecture
    • Software Architecture
      • Publish / Subscribe Architecture
      • New ADO (nuado)
      • Roadmap
    • Data & Information Architecture
      • Conceptual Information Model
        • Concept Dictionary
          • Data Dictionary
        • Acts
          • State Machine
          • Act Relationships
          • Mood Concepts
          • Class Concepts
          • Data Dictionary
        • Entities
          • State Machine
          • Entity Relationships
          • Determiner Codes
          • Class Codes
          • Data Dictionary
        • Null Reasons
        • Extended Data
      • Physical Model
        • Act Data Dictionary
        • Entity Data Dictionary
        • Concept Dictionary Data Dictionary
      • Data Storage Patterns
        • Master Data Storage
      • SanteDB Object Identifiers (OIDs)
    • Security Architecture
    • Privacy Architecture
    • Matching Engine
    • HIE & Interoperability
  • Installation
    • Installation
    • Releases
      • 3.0 Releases
      • Queenston Release
    • Quick Start Guide
      • Seeding ONC Patient Matching Data
    • Operationalizing SanteDB
      • Information Gathering & Analysis
      • Planning & Preparation Work
        • Pre-flight Checklist
        • Develop a Business Architecture
        • Develop an Information Architecture
          • Establishing Minimum Datasets
          • Identity Environment
        • Develop Operational Technology Architecture
        • Developing Privacy Impact Assessments
        • Develop Threat / Risk Assessments
      • Deployment
        • Pre-Flight Checklist
        • Installing Software
          • SanteDB iCDR Server
            • Installation on Virtual or Physical Environments
              • Installation on Microsoft Windows
              • Installation on Linux and Unix
            • Installation using Appliances
              • Using Docker Containers
                • Adding Sample Data
                • Feature Configuration
                • SanteDB within Instant OpenHIE
              • Using Virtual Appliances
            • Installation Qualification
              • Master Patient Index / Client Registry Qualification
                • MPI/CR Test Cases for HL7v2
                  • TEST: OHIE-CR-02-HL7v2
                  • TEST: OHIE-CR-03-HL7v2
                  • TEST: OHIE-CR-04-HL7v2
                  • TEST: OHIE-CR-05-HL7v2
                  • TEST: OHIE-CR-06-HL7v2
                  • TEST: OHIE-CR-07-HL7v2
                  • TEST: OHIE-CR-08-HL7v2
                  • TEST: OHIE-CR-09-HL7v2
                  • TEST: OHIE-CR-10-HL7v2
                  • TEST: OHIE-CR-11-HL7v2
                  • TEST: OHIE-CR-12-HL7v2
                  • TEST: OHIE-CR-13-HL7v2
                  • TEST: OHIE-CR-14-HL7v2
                  • TEST: OHIE-CR-15-HL7v2
                  • TEST: OHIE-CR-16-HL7v2
                  • TEST: OHIE-CR-17-HL7v2
                  • TEST: OHIE-CR-18-HL7v2
                  • TEST: OHIE-CR-01-HL7v2
                  • HL7v2 Test Cases Instructions
                • MPI/CR Test Cases for FHIR
                  • TEST: OHIE-CR-01-FHIR
                  • TEST: OHIE-CR-02-FHIR
                  • TEST: OHIE-CR-03-FHIR
                  • TEST: OHIE-CR-04-FHIR
                  • TEST: OHIE-CR-05-FHIR
                  • TEST: OHIE-CR-06-FHIR
                  • TEST: OHIE-CR-07-FHIR
                  • TEST: OHIE-CR-08-FHIR
                  • TEST: OHIE-CR-09-FHIR
                  • FHIR Test Cases Instructions
              • Security Administration Testing
                • Administrative Panel Validation
                  • User Management Tests
                    • TEST: SECURITY-UM-01
                    • TEST: SECURITY-UM-02
                    • TEST: SECURITY-UM-03
                    • TEST: SECURITY-UM-04
                    • TEST: SECURITY-UM-05
                    • TEST: SECURITY-UM-06
                    • TEST: SECURITY-UM-07
                    • TEST: SECURITY-UM-08
                    • TEST: SECURITY-UM-09
                    • TEST: SECURITY-UM-10
                    • TEST: SECURITY-UM-11
                    • TEST: SECURITY-UM-12
                    • TEST: SECURITY-UM-13
                    • TEST: SECURITY-UM-14
                    • TEST: SECURITY-UM-15
                    • TEST: SECURITY-UM-16
                    • TEST: SECURITY-UM-17
                    • TEST: SECURITY-UM-18
                    • TEST: SECURITY-UM-19
                    • TEST: SECURITY-UM-20
                    • TEST: SECURITY-UM-21
                    • TEST: SECURITY-UM-22
                    • TEST: SECURITY-UM-23
                    • TEST: SECURITY-UM-24
                    • TEST: SECURITY-UM-25
                    • TEST: SECURITY-UM-26
                    • TEST: SECURITY-UM-27
                    • TEST: SECURITY-UM-28
                    • TEST: SECURITY-UM-29
                    • TEST: SECURITY-UM-30
                    • TEST: SECURITY-UM-31
                    • TEST: SECURITY-UM-32
                    • TEST: SECURITY-UM-33
                    • TEST: SECURITY-UM-34
                    • TEST: SECURITY-UM-35
                    • TEST: SECURITY-UM-36
                    • TEST: SECURITY-UM-37
                  • Group/Role Management Tests
                    • TEST: SECURITY-GRM-01
                    • TEST: SECURITY-GRM-02
                    • TEST: SECURITY-GRM-03
                    • TEST: SECURITY-GRM-04
                    • TEST: SECURITY-GRM-05
                    • TEST: SECURITY-GRM-06
                    • TEST: SECURITY-GRM-07
                    • TEST: SECURITY-GRM-08
                    • TEST: SECURITY-GRM-09
                    • TEST: SECURITY-GRM-10
                    • TEST: SECURITY-GRM-11
                    • TEST: SECURITY-GRM-12
                    • TEST: SECURITY-GRM-13
                    • TEST: SECURITY-GRM-14
                    • TEST: SECURITY-GRM-15
                  • Security Policy Management Tests
                    • TEST: SECURITY-PM-01
                    • TEST: SECURITY-PM-02
                    • TEST: SECURITY-PM-03
                    • TEST: SECURITY-PM-04
                  • Device Management Tests
                    • TEST: SECURITY-DM-01
                    • TEST: SECURITY-DM-02
                    • TEST: SECURITY-DM-03
                    • TEST: SECURITY-DM-04
                    • TEST: SECURITY-DM-05
                    • TEST: SECURITY-DM-06
                    • TEST: SECURITY-DM-07
                    • TEST: SECURITY-DM-08
                    • TEST: SECURITY-DM-09
                  • Application Management Tests
                    • TEST: SECURITY-AM-01
                    • TEST: SECURITY-AM-02
                    • TEST: SECURITY-AM-03
                    • TEST: SECURITY-AM-04
                    • TEST: SECURITY-AM-05
                    • TEST: SECURITY-AM-06
                    • TEST: SECURITY-AM-07
                    • TEST: SECURITY-AM-08
          • SanteDB dCDR Instances
            • Installing Web Access Gateway
            • Installing Disconnected Gateway
            • Installing Disconnected Windows Application
            • Installing the dCDR SDK
            • User Interface App Settings
        • Configuring Privacy Controls
        • Post Deployment Tuning
        • Securing SanteDB Configuration
        • Securing SanteDB Databases
        • Securing SanteDB APIs
      • Rollout
    • Demonstration Environments
  • Operations
    • SanteDB Operations
    • Server Administration
      • Configuration Tool
        • Messaging Settings
          • HL7 Version 2 Service
          • FHIR R4 Service
          • GS1 BMS XML Service
          • Health Data Services Interface
          • Administrative Management Interface
        • Diagnostics Settings
        • Persistence Settings
          • Retention Policies
          • Resource Manager Settings
          • Database Connections
        • System Settings
        • Performance Settings
        • Security Settings
          • Data Privacy Filtering
          • Auditing Configuration
        • Operating System Settings
      • Server Configuration File
        • Service API Configuration
          • REST Service Configuration
        • Connection Strings
        • Application Service Context Configuration
        • Applet Configuration
        • Diagnostics Configuration
        • Data Quality Services
      • SanteDB iCDR Host Command
      • Backup Procedures
      • Log File Management
    • CDR Administration
      • SanteDB Administration Portal
        • Logging In
        • Managing Your Profile
        • System Administration
          • Jobs
          • Logs
          • Pub/Sub Manager
          • Server Status
          • Dispatcher Queue
          • Probes
        • Reference Data Administration
          • Place Administration
          • Facility Administration
          • Materials
          • Identity Domain Management
        • Concept Dictionary Administration
          • Concept Sets
          • Concepts
          • Code Systems
        • CDR Administration
          • Importing Data
          • Data Quality Rules
          • Extensions
          • Decision Support Library
            • View CDSS Library
            • Edit CDSS Library
          • Matching Configuration
            • Creating / Viewing Configurations
            • General Configuration
            • Blocking Configuration
            • Scoring Configuration
            • Classification Configuration
            • Testing Match Configuration
            • Match Configuration XML Definition
        • Data Warehouse
        • Reports Centre
        • Security Administration
          • Managing User Accounts
          • Managing Groups
          • Managing Policies
          • Managing Devices
          • Managing Applications
          • Reviewing Audits
      • SanteDB Administration Console
        • User Administration
        • Group / Role Administration
        • Policy Administration
        • Device Administration
        • Application Administration
    • Standard Operating Procedures
      • User Management SOPs
        • SOP: Onboarding Users
        • SOP: User Lockout
        • SOP: Deactivating Users
      • Role Management SOPs
        • SOP: Role Policy Assignment
        • SOP: Assigning Users to Roles
        • SOP: Creating New Roles
      • Device Management SOPs
        • SOP: Onboarding new HL7v2 Device
        • SOP: Onboarding new dCDR Device
      • Application Management SOPs
      • Standard Operating Procedure Template
  • User Guides & Training
    • SanteDB User Guides
    • Common User Interface Elements
    • SanteMPI
      • Getting Started with the MPI
      • SanteMPI Matches
      • SanteMPI Searching
      • SanteMPI Power Search
      • SanteMPI Patient Detail
        • Demographics Tab
          • Demographic Information Panel
          • Identifiers Panel
          • Related Persons Panel
          • Entity Relationships Panel
        • Master Data Management Tab
          • Records of Truth
        • Data Quality Tab
      • SanteMPI Dashboard
    • SanteEMR
      • EMR Administration
        • Care Pathways
        • Visit Types & Flows
        • Clinical Templates
    • SanteGuard
  • Developers
    • Extending & Customizing SanteDB
    • Getting Started
    • SanteDB XML Schemas
    • Applets
      • Applet Use and Lifecycle
      • Applet SDK Components
        • Applet Development Environment
        • SanteDB Brain Bug
        • Package Manager
        • BRE Debugger
      • Applet Structure
      • JavaScript API
      • Business Intelligence Assets
        • BI Asset Definitions
          • Data Sources
          • Parameters
          • Queries
          • Reference Data
          • Views
          • Data Marts
          • Reports
          • Indicators
        • BI Render Controls
      • Localization
      • Customization & Branding
      • Assets
        • HTML Assets
        • HTML Widgets
        • Virtual Assets
      • AngularJS
      • Clinical Decision-Support
        • CDSS Definitions
        • Legacy CDSS
      • Business Rules
      • Dataset Files
      • External Data Maps
      • Applet Solution Packages
      • JavaScript API Reference
      • Recipes
        • Adding Security Policy based on Occupation
        • Assigning a Home Facility
        • Codified Address
        • Generating ID on Registration
    • .NET Plugins
      • Plugin Libraries
      • Host Context & Lifecycle
      • Business Model Objects
      • Services & Configuration
        • Configuration
          • Configuration Panels
          • Custom Docker Feature Configuration
        • Passive Services
        • Daemon Services
        • Service Definitions
          • Ad-Hoc Cache Provider
          • Application Identity Provider
          • Audit Dispatch Service
          • Barcode Generator Provider
          • Business Rules Service
          • Care Plan Generation Service
          • CDSS Clinical Protocol Repository
          • Concept/Terminology Provider
          • Configuration Manager Service
          • Daemon Service
          • Data Archiving Service
          • Data Privacy Enforcement Provider
          • Data Signing Service
          • dCDR Subscription Definition Provider
          • dCDR Subscription Execution Provider
          • Device Identity Provider
          • Exec-Once Message Persistence
          • Freetext Search Provider
          • IDataPersistenceService{TData}
          • IDataPersistenceServiceEx{TModel}
          • IDataQualityConfigurationProviderService
          • Identity Domain Provider
          • IDispatcherQueueManagerService
          • IElevatableIdentityProviderService
          • IExtensionTypeRepository
          • IFastQueryDataPersistenceService{TEntity}
          • IFastQueryRepositoryService{TEntity}
          • IPersistableQueryRepositoryService{TEntity}
          • IPubSubManagerService
          • IRecordMergingService{T}
          • IRepositoryService
          • ISecurityRepositoryService
          • ISqlDataPersistenceService
          • IStoredQueryDataPersistenceService{TEntity}
          • ITagPersistenceService
          • ITemplateDefinitionRepositoryService
          • IThreadPoolService
          • IUnionQueryDataPersistenceService{TEntity}
          • IValidatingRepositoryService{TModel}
          • Job Management Service
          • Localization Provider
          • Mail Repository Provider
          • Name Alias Provider
          • Network Metadata Provider
          • Password Hashing Service
          • Password Validation Service
          • Policy Decision Provider (PDP)
          • Policy Enforcement Provider (PEP)
          • Policy Information Provider (PIP)
          • Primary Data Caching Provider
          • Query Result Scoring Provider
          • Record Matching Configuration Provider
          • Record Matching Provider
          • Record Merging Provider
          • Repository Service
          • Repository Service with Cancellation Support
          • Repository Service with Extended Functions
          • Repository Service with Notification Support
          • Resource Checkout/Locking Provider
          • Resource Patching Provider
          • Resource Pointer Service
          • Role Provider
          • Security Challenge Authentication Provider
          • Security Challenge Storage Provider
          • Session Authentication Provider
          • Session Storage Provider
          • Stateful Query Provider
          • Stock Management Provider
          • Symmetric Encryption Provider
          • TFA/MFA Secret Generator
          • User Identity Provider
          • User Notification Relay Provider
          • User Notification Template Filler
          • User Notification Template Repository
      • Plugin Metadata
      • Database Patching
      • Custom Match Algorithms
      • Unit Testing Framework
      • Digital Signing Requirements
      • .NET API Reference
    • Service APIs
      • OpenID Connect
        • Consent & Privacy
      • Business Intelligence Service (BIS)
      • Administration Management Interface (AMI)
      • Health Data Service Interface (HDSI)
        • HTTP Request Verbs
        • HDSI Query Syntax
          • Filter Functions
        • API Responses
        • Patching
        • MDM Extensions for HDSI
        • Synchronization API
        • Visual Resource Pointer API
      • HL7v2
        • Enabling HL7v2 Interfaces
        • HL7 Authentication
        • SanteDB HL7v2 Implementation
      • HL7 FHIR
        • Enabling FHIR Interfaces
        • SanteDB FHIR Implementation
          • FHIR Subscriptions
          • Related Persons
        • Extending FHIR Functionality
      • GS1 BMS XML
      • Examples
        • Connecting to the FHIR API
        • Obtaining A Session
    • SanteDB Software Publishers
  • Knowledgebase
    • Knowledgebase
      • SanteDB 2.1.161+ on PostgreSQL 10 returns "websearch_to_tsquery" error
      • Upgrading SanteDB iCDR with large databases
      • Upgrading Gateway to SanteDB Langley (v2.0.30+) from SanteDB Kelowna and earlier
      • When sending a National Scoped ID in PID-19 (SSN) you receive "AuthorityUuid" missing error
      • After Installing dCDR you receive an error on SecurityUser
      • When logging into the dCDR you are immediately logged back out
      • PostgreSQL connections fail with block message
      • Backing up HDSI server database
      • You receive an "out of disk space" error on the IMS server
      • Setting up the "sherlock" service
      • Diagnosing service port issues
      • You receive a certificate expired or certificate not found error on startup
      • After updating a database field the values are not reflected in the application layer
      • Diagnosing Submission Errors From Mobile Device
      • Migrating A SanteDB Server
      • Pruning and Cleaning the Database
      • Improving Download Speeds on Slow Connections
      • You receive a client already running error message
      • Resetting the configuration of the Windows & Linux Applications
      • After setting up the application data appears to be missing
      • Disconnected Client Window is Scaled Improperly
      • Fatal Error on Startup
      • Synchronization Issues on Mobile
      • Installation on Mono 4.x does not permit joining of realm
      • Creating A Public Backup
      • Installing the SanteDB Disconnected Server
    • Fixes & Patches
      • 20170721-01
      • 20170725-01
      • 20170803-01
      • 20170804-01
      • 20170913-01
      • 20171003-01
      • 20171011-01
      • 20171016-01
      • 20171023-01
      • 20171030-01
      • 20171108-01
      • 20171124-01
      • 20180126-01
      • 20180131-01
      • 20180211-01
      • 20181112-01
      • 20181113-01
      • 20190322-01
      • 20190522-01
      • 20190625-01
      • 20200105-01
  • OpenIZ
    • About OpenIZ
      • Upgrading from OpenIZ to SanteDB
    • FAQ
    • OpenIZ Demonstration Servers
Powered by GitBook
On this page
  • Writing your Operational Architecture Document
  • Summarize Software Environment
  • Describe the Physical Environment
  • Describe the Network Environment
  • Describe Service Availability Requirements
  • Describe Service Contacts and Responsibilities
  • Describe Business Continuity Procedures
  • Describe Update Procedures
  • Describe the Security Environment
  • Resources

Was this helpful?

  1. Installation
  2. Operationalizing SanteDB
  3. Planning & Preparation Work

Develop Operational Technology Architecture

PreviousIdentity EnvironmentNextDeveloping Privacy Impact Assessments

Last updated 3 years ago

Was this helpful?

An operational technology architecture differs slightly from a software requirements specification or functional design specification for software. The operational technology architecture is primarily concerned with the operational environment in which SanteDB services will be running.

Writing your Operational Architecture Document

The documentation prepared for the operational architecture should aim to:

  • Provide a high-level summary of how users interact with the system, and the purpose of the system (this is helpful for network and server operators to understand what types of operational issues may arise)

  • Document the physical architecture of the servers, virtual machines, networks, etc. of the operational deployment

  • Describe the disaster recovery options, backup requirements, and security environment (remote access requirements, etc.)

  • Enumerate the IP addresses, host names, and network infrastructure of where components of the SanteDB software is operating

  • Describe the business continuity plans

  • Describe how the SanteDB infrastructure interfaces with other local systems (peer network addresses, data formats, type of data, etc.)

  • Describe specific data configurations, concept sets, extensions, locations, etc. found in the country deployment

  • Document SanteDB server configuration settings.

Summarize Software Environment

The operational architecture documentation should summarize the software environment in which the SanteDB server is being operationalized (in the example document, note the summarization of the software components).

The operational documentation should keep discussion of software components and business processes to a brief overview (the majority of your software modifications and flows should be captured in a FDS).

Consider, for example, the software architecture for the Demoland example.

You will note that the software summary is concerned about the overall deployment of the software components onto various server infrastructure, and illustrating how data is shared and flows between these components.

The operational architecture of your SanteDB deployment will be highly variable, based on the intended goals and current ground truth (availability of internet, local system capabilities, clinics, workflows, etc.)

Describe the Physical Environment

The operational architecture should describe the operational environment on which the SanteDB software solution will be running. Regardless if the system is hosted in an on-premise data centre, as a managed service, in cloud or as Software-as-a-Service (SaaS), system administrators will still require detailed descriptions of the physical environment in order to manage the system.

The system description should include a server deployment diagram (see below for an example), or if using cloud services, how those services are deployed. If the solution is deployed in clinics with special software or hardware, those deployments should also be documented. The goal is the clearly illustrate how the software is deployed so the operators can maintain the system.

Additionally, any hardware specifications or network specifications should be clearly enumerated in the operational documentation. This includes:

  • The brand name of any equipment being used (example: Lenovo ThinkServer ST550) - this helps maintainers understand how to get support for the hardware.

  • The configuration of the equipment including any options which were configured (example: 2x Intel Xeon Silver 4220 , 128 GB RAM, 1 PCIe nVME Boot Drive, 2x GBe NIC, etc.). This helps maintainers understand the scope and size of the deployment, as well as providing a concrete list of parts which can (or need) to be reordered in case of failure.

  • The software environment of the physical equipment such as any operating systems, Security Information and Event Management (SIEM) or Application Performance Management (APM) software, antivirus configuration, etc. This helps maintainers understand the third party software in use in the operational deployment.

SanteSuite documentation examples refer to POSE and VOSE, which is the Microsoft Licensing nomenclature for Physical Operating System Environment and Virtual Operating System Environment respectively.

Sizing a Server Environment

The sizing of your physical environment will depend heavily on a variety of factors such as the type of use of the SanteDB product, whether offline mode is leveraged, how many users and systems are connecting to the system, etc.

As a general rule, when deploying SanteDB on a physical environment the iCDR components can be computed as:

Component
SIzing
Example

iCDR Server CPU

20 concurrent clients = 5 VCPU minimum

iCDR Server RAM

4GB - 8GB

PostgreSQL Server CPU

5 VCPU on iCDR = 10 VCPU

PostgreSQL RAM

10 VCPU = 5 GB RAM minimum (more is better to tune max_work_mem)

PostgreSQL Disk

As fast as possible

Additional hints for sizing a physical environment:

  • Buy two of everything instead of one physical server, buy two smaller ones - this is beneficial because:

    • It provides load balancing opportunities

    • It provides a failover environment when the hardware fails

  • Always purchase SSD or NVMe based storage for your database servers (as opposed to spinning/spindle disk types)

  • Always run your storage in a redundant mode (i.e. run in RAID1, RAID1+0, RAID5+0 or RAID6)

  • Where possible use PostgreSQL streaming replication on the primary CDR database to balance queries and writes

  • Where possible use a Storage Area Network with the highest possible Input/Output Operations (IOPS) ratings for throughput

    • If using a SAN ensure the storage network is on a different NIC than other network traffic

    • A SAN allows hypervisors to move Virtual Machines (VMs) between hosts to balance load or to provide rapid failover (using technologies such as VMotion)

  • Always buy spare parts (disks, RAM, network cards, etc.) matching the configuration of the hardware in the original equipment (this provides quick replacement for failed hardware)

Describe the Network Environment

Your operational documentation should describe the networking environment used in the deployment. This includes:

  • IP addresses and host names of each POSE and VOSE in use in your deployment

  • All ports which are opened on the operating system firewalls (if any) including their port number, protocol and type of data flowing through the port (including if they are secured or not)

  • Any remote access ports which are opened for system administration. This could include SSH access points, Microsoft Remote Desktop, VNC, or even VPN settings which will be used to access the console or host operating systems.

Describe Service Availability Requirements

SanteDB often acts as an integration point for many different systems and often plays vital roles in a health system. What happens, however, when that infrastructure is not available?

It is fact of life that servers fail, networks are unreachable, or other any other combination of issues can arise. The operational architecture should at least identify how this will impact business users. For each component in your deployment, the availability section should describe:

  • The observed impact of an outage of the particular component (for example: how does the system behave when the database server is offline?)

  • Mitigations that can be taken to prevent or recover from the outage condition

  • Descriptions of what the business impact of a component being absent would have on users (example: If the one of the SanteMPI host servers is unavailable, what impact would it have on users? What options are there to continue doing business?)

Describe Service Contacts and Responsibilities

Large deployments often involve a large number of staff, companies, agencies and ministries. It is important that a clear set of responsibilities be established for each. This is important as it allows readers of the operational architecture to understand:

  • Which partner in the deployment is responsible for which maintenance or corrective activities?

  • What are the hours of operation (or expected availability) of each partner?

  • What are the escalation procedures and tiers for supporting the deployment?

In general, we recommend using information technology service management frameworks and best practices published by organizations such as ITIL, ITSM and COBIT to establish a Service Desk process and supporting tools for the ongoing support of the end-users of your solution.

Describe Business Continuity Procedures

When an issue is detected that impacts business users, they will often need to continue doing their work (even though the software is unavailable). Your operational architecture document should include a business continuity plan. The continuity plan should identify:

  • What should users do when the system is unavailable? (use a paper based process? replace devices? change sites to a backup installation? etc.)

  • How should users report their issues when they experience an outage? (Is there a helpdesk? A bug tracker? A support line to call? etc.)

  • What are the RPO, RTO and MTO values for the deployment? (see below)

  • What are the procedures (for each component) to recover from a failure condition?

RPO, RTO and MTO

  • Recovery Time Objective (RTO) – The maximum amount of time that could be tolerated between unexpected failure and the resumption of normal service. (i.e. How long can clinics operate without the system?). RTO dictates the goal for recovering the service operation.

  • Recovery Point Objective (RPO) – The maximum period of time which data might be lost if service unexpectedly fails. (i.e. How far back can you fail without being a catastrophic loss to business?). RPO usually informs the frequency of your backups and impacts the cost of your backup infrastructure.

  • Maximum Tolerable Outage (MTO) – The maximum amount of time that the business can tolerate complete outage of the system during normal business days before it becomes impossible to continue doing work.

Describe Update Procedures

Software is a living product and evolves over time and it is important to ensure that operating systems, clinical systems, antivirus software, firewalls, etc. are regularly updated to ensure that the latest security and features are present in the environment.

Typically, updates require organizational planning to ensure that maintenance windows do not overlap with business operations, and that any special processes (like backups, snapshots, service stop/start, upgrades, etc.) are done in a particular order.

The operational architecture should describe all of these impacts on the environment, as well as any special procedures that must be followed. For example:

Prior to updating the SanteDB dCDR software in clinics, ensure:

  • Any OpenMRS servers are shut down and users logged out.

  • The SanteDB dCDR synchronization center indicates no conflicts and no remaining upload data (in the outbox)

  • The backup job is run to produce a recent copy of data in the dCDR

Describe the Security Environment

Your operational architecture document should describe the security environment which is being used in your deployment. This should include:

  • How are new devices or applications integrated into the SanteDB infrastructure? What approvals are required and/or sign offs?

  • How are new users added to the SanteDB infrastructure? What groups are they assigned to? What access controls do they have over the solution and hardware?

  • What firewalls are in place and/or configured?

  • How is data encrypted in transit between systems and at rest, including via intermediaries? (example: How are the HL7v2 messages encrypted between a Hospital Information System and the SanteDB iCDR?)

  • How are systems and users authenticated? What are the policies in the deployment for password and account expiration?

  • What are the custom policies applied or configured in the operational environment?

Resources

The SanteDB team has prepared a template which may be helpful for organizing your Operational Architecture. The document contains instructions and a limited example of content for Demoland to get writers started in authoring operational architectures.

How load balancers, SSL termination, or application firewalls are to be configured to handle traffic (example: external host https://mpi.gov.demoland.com:8443 is routed to http://mpi-prod:8080) Tip: offloading encryption to a dedicated endpoint can free application server resources -- for more information see

As always, please refer to the .

nvcpu=nclients4n_{vcpu} = \frac{n_{clients}}{4} nvcpu​=4nclients​​
nvcpu=icdrvcpu∗2n_{vcpu} = icdr_{vcpu}* 2nvcpu​=icdrvcpu​∗2
nram=nvcpu∗512MBn_{ram}=n_{vcpu} * 512{MB}nram​=nvcpu​∗512MB
https://www.nginx.com/blog/nginx-ssl/
Disclaimer
337KB
Operational Architecture - Template - Public.docx
Demoland Operational System Architecture
Demoland Production Server Environment