Demographics

One key feature of Atomik is the support of the openEHR demographic model, alongside with the EHR model.

Though the openEHR Architecture Overview shows the demographic and EHR components as physically separated, there are certain contexts and use cases that can take advantage of having both repositories implemented in the same system.

Also consider that even both options are available inside Atomik, you can use an instance of Atomik to manage EHR data, and a different instance to manage demographic data, which will match exactly the proposed openEHR architecture, but makes a better reuse of components, since both is the same code base, so when an update is released, the update process will be exactly the same for all server instances.

Actors

Atomik supports all types of Actors (Person, Group, Organization and Agent) from the openEHR demographic model. Actors are archetypable and versionable, which means that:

  1. To be able to create an Actor, you need to upload an Operational Template that defines the internal structure of each Actor type.
  2. Once an Actor is created, if it's information changes in time, updates can be done. As any update in openEHR, the original data is not modified, but a new instance of the updated data is created and linked with the previous version.
Versioned Actors
Versioned Actor Details

Relationships

Atomik supports creating relationships between Actors. Relationships are archetypable and versionable and can contain data about the relationship.

Relationships allow to represent different things like:

  1. Family relationships like Person parent_of Person
  2. Work relationships like Person works_in Organization (e.g. a hospital or clinic)
  3. Group relationships like Person belongs_to Group (e.g. a surgery team)

Roles

Atomik supports Roles to describe how Actors act in certain contexts. For instance a Role type could be Patient or Physician.

We made a design decision for Roles, we consider a Role is a weak entity in relationship with an Actor, so Roles are created or modified when Actors are created or modified. As a consequence, Roles are versioned inside an Actor version, but not as a standalone top-level entity.

Roles are archetyped, and can contain data with different structures, depending on the context and requirements. In general, we recommend to add a coded value that describes the type of the Role.