As of version OpenMRS v1.5 most objects/tables have a UUID property. This property is automatically filled in for every row and is 99.9% guaranteed to be unique across the universe. The primary reason for uuids is to support the Sync Module and allow for identifying objects that are identical across different OpenMRS installations.

The uuid value will be hexidecimal hexadecimal digits in the form of 8chars-4-4-4-12chars (e.g 0febc204-bca1-11de-913d-0010c6dffd0f). Depending on whether mysql or java generates these (see below), the uuid could be in version 1 or version 4 respectively.

...

All uuid columns can hold up to 38 character to accommodate MSSQL server's desire to put a curly brace ({}) at the beginning and end of the 36 chars.

Primary Key Argument

The UUID is used as a normal property of every object instead of a primary key for several reasons:

...

The API uses the Java UUID class randomUUID() generation method (and so will be UUID v4 reference above).

OpenMRS UUIDs

There are some UUIDs shared across all OpenMRS implementations for metadata that are common across all implementations.

Concept Datatype UUIDs

Tables without UUIDs

There are many tables without the uuid property because they are either helper tables, mapping tables, or just used for business logic by other libraries used within openmrs.

• cohort_member
• concept_complex (extends concept table and shares uuids with that)
• concept_derived
• concept_name_tag_map (1 to many mapping from tags to names)
• liquibasechangelog (externally used by liquibase library)
• liquibasechangeloglock (created by liquibase library)
• location_tag_map
• notification_alert_recipient
• role_privilege
• role_role
• scheduler_task_config_property
• patient (extends person table and shares uuids with that...might change for 1.6)
• user (extends person table and shares uuids with that...might change for 1.6)
• user_role

See Also

• Online UUID Generator