Planning a deployment
This section is aimed at helping you to outline the requirements of your deployment, navigate your options and make the decisions to satisfy the requirements of your particular circumstances. Each section below will give examples of questions that might need to be addressed in the setting up of your deployment.
This section:
- Explores some common deployment scenarios
- Considers the ideal topology for your planned deployment
- Asks you to think about the expected scope of sharing localised content
Common considerations when planning a deployment include:
- How to set up the Terminology Server (Ontoserver™)
- How you will receive updates. Are there syndication feeds that you can use (e.g., the Australian National Syndication Service (NSS))
- What the mapping between local and national terminologies will look like (using Snapper).
Goals and scope
It is always important to evaluate all the reasons you might use Ontoserver and how these reasons might align with business interests. Some questions that might be considered are detailed in the table below:
| External content | Content authoring |
|---|---|
| What content is going to be loaded from other external sources? | Will the deployment be used to author new content? If so, what sort of content? How much content will be created, and how frequently will it be released? |
| Does external content need to be transformed to FHIR? | Who will collaborate on the content? |
| How often does external content need to be loaded? | How formal do the content approval and release processes need to be? |
Different deployment decisions will have impacts on the release and publication process, particularly the gates and level of control. Key to these are:
- Whether a single read/write endpoint is being used for content authoring and use, or if separate endpoints are being used for content development and content publication/use
- Whether a syndication server is being used to take release candidate “snapshots” which are deployed separately
- Whether a staging publication endpoint is being used to test out releases prior to publication on a production endpoint
It is also important to consider how software and systems will be communicating with Ontoserver:
- Which systems will use the Ontoserver APIs?
- What sort of content and operations will they use – e.g. supporting user selection of a code by text searching, translating codes from one code system to another, validating FHIR resources etc
- Are the applications using the services at “runtime” or build time/batch processing? How critical are the services to the integrated application/s – e.g. what sort of availability of the service needs to be ensured
Infrastructure
- What sort of infrastructure does your organisation currently have/user or want to use in the future? What are its limitations?
- What sort of performance is required – largely driven by the software integrations and their needs. This drives the size and type of resources that get provisioned as well as potentially the number of instances
- What sort of high availability requirement is there? Usually this applies only to Ontoserver instances serving integrated applications
- How will backups be taken to prevent data loss?
- What sort of disaster recovery service restoration time is required (affects the sorts of backups and style of deployment)?
- How will the service be monitored for health and potential automated responses to health issues?
Security
- How fine-grained does the security need to be – is API-level read/write access sufficient or is fine-grained access control is required?
- Will Ontocloak be used for authorisation, or will something else need to be set up?
- Which identity providers will be used to authenticate users? Does identity management need to be handled in the solution or can exclusively external identity providers be used?
Operations
Other operations that will need to be considered include:
- Deploying software updates, including defining if test deployments are done first etc
- Content ingestion from external sources – may include executing transformations and loading new content through manual or semi-automated processes
- Content promotion, e.g. acceptance and deployment of authored content to production
- Monitored and service reporting
- Troubleshooting preparedness and issue escalation paths