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.

In it's canonical form, a uuid value will be 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.

The uuid can really be any unique string within the table, but to follow conventions, all OpenMRS uuids should be 36 characters in length.  (Ideally, all OpenMRS uuids would be in the canonical form, but the uuids in the MVP dictionary, which were created manually, don't follow the 8chars-4-4-4-12chars convention, though they are all 36 characters in length.)  Certain modules, such as the HTML Form Entry module, operate under the assumption that a uuid is 36 characters long, so if you are manually creating uuids for some reason, you should follow this convention.

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:

1. Using long string uuids reduces performance. Its much faster to use smaller integers for PKs
2. The uuid is a long ugly 36 character string that would not look good in urls

Initial Column Values

When upgrading a current installation of openmrs, all rows will get a uuid generated for them. If you are using mysql, then openmrs uses the uuid() method during the update to do something like:

If you are using a DB other than mysql, most likely it also has a function to create a uuid.  If not, then there is a java routine that runs and uses the java implementation of UUID generation. This is considerably slower.

There have been issues with mysql on windows and not getting unique uuids [1] . To find those duplicates, you can run this sql:

UUIDs and the OpenMRS API

Also in OpenMRS 1.5 there came a number of base abstract classes to define common metadata on objects. One of these objects was the OpenmrsObject. If an object extends this class and gets passed through an API method of the form of "save*(OpenmrsObject obj)", then the uuid property is automatically generated and saved along with the object. See API Save Handlers for more information about that magic.

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

Role UUIDs

HL7 Source UUIDs

Location UUIDs

Patient Identifier UUIDs

Concept Class Identifier UUIDs

Relationship Type UUIDs

Encounter Types UUIDs

Person Attribute Types UUIDs

Field Types 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