Demographics

Clinical records belong to real people — patients, practitioners, organizations. Keeping demographic data structured, versioned, and linked to health records isn't just good modeling; it's what makes queries like "show me all records for patients over 65 with this diagnosis" actually answerable.

Atomik supports the openEHR demographic model alongside the EHR model — so identity and clinical data share the same versioning, querying, and audit infrastructure.

The openEHR Architecture Overview defines demographic and EHR components as physically separable. Atomik supports both patterns: run them together in one instance for simplicity, or separate them across instances when your architecture or data governance requires it. Either way, both use the same codebase — updates apply uniformly across all instances.

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.