Data Provider Infrastructure Basics and Security
Providing an endpoint for accessing data using the FHIR standard, the recommended solution is to use Interweave Connect. This FHIR server fully implements the standard and is proven in practice. The architecture includes a 3-tier application that stores FHIR resources and audit trails, running on Postgres or MSSQL with Dockerized Node.js. Security is based on three layers: Firewalls, TLS, and Messaging, with specific requirements for outbound credentials and SSL termination. Environments range from testing to deployment with various stages for testing, development, and production.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Contents The Requirement The Basics Security Environments Example Test Systems Installation Example Live Installation
The Requirement The requirement is to provide an endpoint for accessing data using the FHIR standard. This standard includes both: a) Data Format b) Messaging Behaviours The recommended solution is to use the free Interweave Connect implementation o This is a FHIR server available as a dockerised application* for all programme participants to download for free. (Also known as the FHIR Appliance ) o This fully implements the FHIR standard and is already proven in practice by other organisations who have connected to the Interweave Exchange. The remaining slides in this pack outline the infrastructure and networking needed to implement this * Note: If you use the Intersystems integration engine then an equivalent Interweave Connect implementation is available as an add-on for that. Whilst most of the principles are the same, some details of the infrastructure are slightly different please get in touch for further specifics.
The Basics The architecture is a standard 3-tier application Stores (1) FHIR Resources and (2) Audit trail Need a user and empty database / schema. (Tables are auto-created) Runs on Postgres, or MSSQL 2016 upwards Dockerised Node.js application Listens on up to two ports (external and internal) Runs on Linux (eg Ubuntu 18.04 LTS) or Windows Server 2019 DMZ and Web Proxy layer (eg IIS, NGINX, etc). Performs SSL termination and routing Could be existing infrastructure Internet Internal DMZ FHIR Web Proxy Appliance (Provided) Database Outbound (PIX registration) Patching Integration Engine (Existing) Other Systems (Existing)
Security Security is based on three layers: (1) Firewalls (2) TLS (3) Messaging Outbound credentials (Care Record issued certs and password) SSL termination - using Care Record issued certificates Mutual authentication restrict trust to Care Record SSL Root CA 3 2 JWT verification using Care Record IAM Root CA API Key Internet Internal DMZ FHIR HTTPS HTTP(S) Web Proxy Appliance (Provided) Database HTTP(S) Incoming fixed IP address, for firewall whitelisting Fixed IP address, for configuration of message routing. (Messages are routed by IP, not DNS) Integration Engine (Existing) Other Systems (Existing) 1 Outbound fixed IP address, for central firewall whitelisting (PIX)
Environments Preparing for testing, plus contributing data for others to test against SoS Sandpit Initial testing and development Staging Production Final confirmation with Live data and rollout Deployment rehearsal and formal signoff UAT Test Production Provider Data Synthetic Data Synthetic Data Live Data An initial environment where project teams can play and develop their system Reduced security controls, and no validation against PDS Representative sample data from each data provider, using the defined bank of test patients Potentially imperfect/volatile test environment Data Providers must ensure their Sandpit implementation is permanently available for Data Consumers to test against More stable sample datasets for final pre- live assurance and clinical safety testing Full security controls and PDS validation Logically separate, although might share infrastructure with the Sandpit test environment Data Providers must ensure their Staging implementation is permanently available for Data Consumers to test against The production environment containing live patient data Full security controls and PDS validation Resilient technical infrastructure Has the ability to pre-release live data in a restricted mode for final clinical safety testing
Example Test Systems Installation Typically low volume, focus on cost minimisation and reuse Opportunities to share Web Proxy and Database servers, if desired Opportunity to install both FHIR Appliance instances on one server, if desired Typically minimal load and small servers (see Appendix) Preferably virtualised, so easy to tune Internet Internal DMZ Web Proxy Server(s) FHIR Appliance (Sandpit) Database Sandpit site Sandpit DB FHIR Staging DB Appliance (Staging) Staging site (Other test DBs?) (Other test sites?) Integration Engine (TEST)
Example Live Installation Volume will be use-case specific, focus on security, performance, and reliability Standard web-proxy farm front-end (not necessarily specific to this app) Load balanced mid-tier FHIR Appliance (at least 2 for resilience, with option to scale horizontally) Database, following standard DBA best-practices for failover, back up etc (consider also characteristics of FHIR Store vs Audit trail) Sizing is highly dependant on use-case. However see Appendix for minimum server specs. Virtualisation allows for monitoring and scaling if required Internet Internal DMZ Web Proxy Farm FHIR Appliance (Live 1) Load Balancing Database Live DB Live site VIP FHIR (Other live sites?) Appliance (Live 2) (Backups and Archive) Integration Engine (TEST)
Appendix: Minimum Server Specifications These minimum server specifications provide a starting point based on previous experience however the responsibility remains to test and confirm for your own use case. Virtualisation is recommended where possible, to allow for ongoing monitoring and scaling Suggested minimum specification for any server is: 2 core 8GB Ram. A live server should be minimum 2 core 16GB Ram anticipating growth to 4 core 32GB Ram as service demand grows. These figures apply to proxy server, HTTPS servers and database servers. Disk space for databases should allow for 20kb per patient per resource type per year of data (excluding documents).
Appendix: Bandwidth Estimates Bandwidth estimates are highly dependant on the pace of rollout and extent of usage, and this is difficult to predict. Indicative figures and the assumptions they are based upon are therefore shared below Assumptions (a) (b) (c) (d) (e) (f) (g) (h) (i) Typical size of FHIR Structured dataset for 1 patient Number of clinicians accessing the regional record at peak periods, at full rollout Average activity as a percentage of peak Average number of records retrieved from Interweave by a clinician per hour Seconds in one hour Fraction of these requests relevant to any one Data Provider Pace of rollout coverage in 2 years Pace of rollout coverage in 5 years Convert KB to Mbits (* 8 bits per byte / 1000 KB in MB) 50KB 60,000 25% 12 3600 10% 10% 100% 0.008 Calculations In 2 years (*g) 20 requests / second In 5 years (*h) 200 requests / second Peak rates of query to each Data Provider (b * d * f / e) Average rates of query to each Data Provider (b * d * f / e) * c Peak bandwidth for FHIR Structured data (b * d * f / e) * a * i 5 requests / second 50 requests / second 10Mbits/sec 100Mbits/sec Average bandwidth for FHIR Structured data (b * d * f / e) * a * i * c 2.5Mbits/sec 25Mbits/sec NB: Only structured data (not documents) are included in the above estimates. Documents would need to be added based on an assessment of the number and size of documents being shared. Documents themselves are not transferred by default, only a list of metadata as part of the structured dataset. Actual document content is only transferred if the user specifically selects it.
