Components of an Opal application
Opal applications will typically be made up of several types of components.
Opal
The core Opal framework provides you with a range of commonly required elements of clinical applications.
It contains a core data model for persisting clinical information, as well core clinical archetypes out of the box that build on many years of collaboratively modelling clinical concepts by medical domain experts.
Opal also makes it easy to integrate standard clinical reference data into your application - things like medical diagnoses, tests, drugs et cetera.
Some common functional components end up in to most clinical applications, and many of these come with Opal as "batteries included" - immediately available modular features that can be simply re-used without having to reinvent the wheel.
For example:
- Patient lists
- Search
- Authentication and Permissions
- Forms for data entry
- JSON based REST APIs for all of your models
- ... and many more...
Applications
An application is the collection of configuration and bespoke functionality that would be provided to an individual institution - it's the thing that you would look to deploy.
Example applications include elCID - a for managing infection patients, or Opal-Renal - an MDT & handover tool for Renal wards.
A hospital might have multiple clinical services running on one application, or multiple applications that integrate with one another.
Opinionated but Pluggable
Opal is an opinionated framework. It expects the developer to structure code in a certain way.
Opal expects features to be implemented as single page Angular.js applications, with the server mostly figuring as an API endpoint for reading and writing data.
That said, the technology stack of Django, Angular & Bootstrap allows the confident user a huge degree of flexibility when writing their own applications and plugins.
For instance, there is nothing to stop a developer from implementing a part of the functionality in some other Javascript framework, and simply calling the JSON API. However, by doing so, the developer will lose a large collection of pre-existing libraries, conventions et cetera. While possible, this approach is not likely to be officially supported in the medium term.