Since Atomik is heavily based on the openEHR specifications, to make an effective use of Atomik, it's recommended to udnerstand some basic openEHR concepts.
openEHR is an open standard that develops and maintains several specifications (documents) that help develop better Health Information Systems. openEHR has a vibrant community and it's adoption level has increased in the last years, though it's specifications date from more than 20 years.
openEHR captures several requirements, patterns and good practices, and help understand the complexities of Health Information Systems and health-related information definition and management.
For instance, openEHR does the distinction between EHR-related information and demographic information, and provides specifications for both models. In openEHR, the EHR Information Model includes the definition and management procedures for these entities:
The openEHR Demographic Model does the same with these entities:
Even though openEHR defines two separate models, and suggests to use two separate repositories for each kind of information, in Atomik we wanted to provide the possibility of managing both kinds of information. The first reason is for simplificy, so in one system you have both repositories so for fast prototyping you don't need extra components to manage each type of information. The other reason is maintainability, since managing both kinds of information share a lot of common processes it would be more complex to maintain two code bases. Either way you can have one Atomik instance to manage only EHR data, and another Atomik instance to manage demographic data. That way we comply with the openEHR recommendations.
In the classic Software Engineering approach, domain entities and relationships are embedded into the software, at the database level, at the user interface level, at the logic level, etc. So when modifications on the data are needed, developers need to touch an update each level in the software, which creates systems that are difficult and costly to be maintained.
The openEHR specifications propose a different approach: the software components implement generic information artifacts, and the domain data is managed outside the software, that means the domain entities are not longer embedded into the software. In this approach, when a change in the data is needed, the software is untouched, only the data definitions are modified, which are managed outside the software. This generate highly maintainable systems that are less comlpex and less constly to maintain.
There is a huge adantage of the openEHR methodology: the modeling process and information elements are all standardized, which allows to increase the quality of the information definitions and formally manage those definitions in the long term. With the classic approach of engineering these kinds of health systems, in 3 to 5 years with the system being maintained in an ad-hoc way, generates poor quality data management characteristics including: data duplication, inconsistencies and fragmentation.
This separation of data from app is possible due the openEHR dual-modeling approach, which is composed by two sets of specifications: Archetype Model and Reference Information Model.
The openEHR Archetype Model describes the artifacts used to define, manage and share definitions of health information. These definitions include: structure, constraints and terminology. These definitions allow you to express any kind of information you want to store and manage in a health information system, and all definitions use the same standardized elements (Archetypes and Templates) to create complex data structures. This flexibility comes from the underlying Reference Information Model, because all the elements used in these definitions come from it.
The Reference Information Model is mainly composed by the specifications mentioned above (EHR and Demographic), and defines generic data structures that can be configured in different ways to express any kind of data structure. That "configuration" of the Information Model is done by Archetypes and Templates.
These are openEHR models used to describe information structures. The openEHR recommendation is for these models to be created by Domain Experts, yes these are clinicans not IT people. There are some positive consequences of this recommendation. First, clinical information is defined and managed by professionals that actually know what they are talking about. Second, we, IT people, can rely con these Domain Experts for the information definitions, while we focus on solving pure engineering problems (dealing with clinical knowledge is not one of them).
Domain Experts will use modeling tools to create, manage and share Archetypes and Templates. There are plenty of modeling toos available and the learning curve is not so steep. We offer a training course specifically to learn about Clinical Information Modeling with openEHR, that includes the methodology and tools needed to create your own models.
When Domain Experts create these information models, they first start creating all required Archetypes which define the basic structures that will be reusable parts in different documents, like Blood Pressure, Pulse, Body Temperature, Medication Order, Procedure, etc. Each of those concepts will have their associated data structures in one Archetype each.
Another option, instead of creating all Archetypes from scratchs is to grab the ones that are available in the international Clinical Knowledge Manager (CKM). An interesting characteristic of Archetypes is that, since they include terminology about the concept that Archetype represents, you can translate an Archetype to different languages, so your document definitions can be in several languages. Many Archetypes in the CKM are already translated, and if you need to use an Archetype form there that is not translated to a specific languages, you can contribute with the translation. This is how the Clinical Modeling Community works: by contributions.
Finally when you have all the Archetypes needed by certain document, those Archetypes are combined in a Template. An openEHR Template is basically a huge Archetype that represents a clinical document. Note we use the term "clinical" in a very loose way here, since in an openEHR Template you can represent records that contain many concepts (Archetypes) but might not be for a strictly "clinical" context, for instance, a Template could define the data structures needed to record Exercise Tracking, Procedure Consents, basic Administrative data, etc.
So the output of the Clinical Modeling process executed by Domain Experts is a Template in a form that can be consumed by software systems. That final form is called Operational Template (OPT). The OPT is just an XML file that contains all the structure definitions, data constraints and terminology from all the Archetypes referenced by the Template. OPTs are actually what the Clinical Modelers will handle the IT team to implement the corresponding user interface, application logic and persistence that will allow a software system to store and retrieve data defined by the OPT.
Since Atomik is an openEHR-based system, it follows that process: you need to upload the OPTs used by your applications so it knows how the data will look like, then Atomik will know how to process and store it when your application commits data to Atomik.
One final thing to know about openEHR is that knowledge models (Archetypes and Templates) and data stored based on those models, are all versionable. Let's say you have an Archetype, for instance Blood Pressure, that will be the first version of the Archetype. Then in the future some extra requirement about Blood Pressure is needed, then you modify the Archetype and release the second version of the Archetype. From now on, all Blood Pressure data will follow the v2 Archetype, while current data follows v1. That is normal in healthcare systems, but most systems don't have this requirement formally defined. Then when data about Blood Pressure is queried and retrieved, data recorded for v1 and v2 of the Archetype will be returned.
Then data itself is versionable. That means, when a modification, amendment or even deleting existing data is needed, in openEHR the current data won't be modified, but a new version of the data will be created and linked with the previous version. This maintains a cohered audit log of all the changes done to the data, creating a history that can be navigated, and each item in the data history has an audit log including the type of change, timing, reason and the responsible for the change, answering all the basic questions for an audit log system.
At CaboLabs we provide formal training on different aspects of openEHR, from understanding the specifications, to implementation, including clinical modeling for domain experts. You can find more at our education website.