PAC-ID

PAC-ID in a Nutshell

A PAC-ID, which stands for Publicly Addressable Content IDentifier, is a globally unique identifier that operates independently of a central registry. It resembles a URL and serves to reference substances, devices, consumables, or measurement results.

Here is an example PAC-ID:

HTTPS://PAC.METTORIUS.COM/DEVICE/21:210263

The PAC-ID can also be represented in alternative formats, including as a QR code:

Introduction

Laboratory software needs to unambiguously refer to real world objects and data. Typically, this is achieved by assigning unique identifiers to objects and data sets. As of today, each software product creates its own proprietary identifiers. With an increasing number of software products deployed in labs, objects usually end up having multiple identifiers. This impacts usability, causes errors and increases maintenance efforts.

The Balance is known under multiple identifiers as each system issues its own.

As part of the Smart Building Blocks for Digital Labs initiative, the publicly addressable content identifier ("PAC-ID") addresses this by promoting the re-use of already existing identifiers. The identifier is augmented with information about the issuing system and is represented in standardized formats, thus making it globally unique and reusable across system borders.

All systems are using the same globally unique identifier for referring to the balance.

The PAC-ID also serves as foundation for further Smart Building Blocks that provide functionality that wouldn’t be feasible with proprietary identifiers.

Specification

Components

A PAC-ID is composed of an issuer and identifier component. It is REQUIRED that the combination of issuer and identifier is globally unique.

Name	Meaning	Technical Requirements	Example
issuer	The party which issued the identifier and knows what the identifier refers to.	MUST be a valid domain name according to RFC 1035. SHOULD be a registered and active domain name. SHOULD contain only the following characters A-Z, 0-9, -, and .	"METTORIUS.COM" (The manufacturer of the balance)
identifier	The identifier itself.	MUST consist of one or more id segments separated by /. At least one id segment MUST be non-empty. MUST not exceed 256 characters.	"DEVICE/21:210263" (An identifier for one particular balance)
id segment	The id segment is a part of an identifier that can stand on its own. Typically used to organize identifiers within an issuer.	MUST be a valid hsegment according to RFC 1738, but without * (see PAC-ID Extension). SHOULD be limited to A-Z, 0-9, and :-+ for new designs. CAN be an id segment key and id segment value pair separated by :.	"21:210263" (A id segment containing a serial number)
id segment key	The id segment key describes the meaning of the id segment value.	RECOMMENDED to be a well-known id segment key. SHOULD be limited to A-Z, 0-9, and -+.	"21" (GS1 identifier for Serial Number)
id segment value	The value corresponding to the id segment key.	SHOULD be limited to A-Z, 0-9, and -+.	"210263" (A Serial Number)

Serialization

URL Format

A PAC-ID can be represented as a text in the form of a URL as follows:

URI Component1	Value
scheme	Always "HTTPS".
host	The issuer of the PAC-ID, prefixed by "PAC.".
path	The identifier of the PAC-ID, potentially followed by * and arbitrary content. * and subsequent characters are not part of the PAC-ID and MUST be ignored (extension space, see PAC-ID Extension).

An example PAC-ID, represented as URL:

HTTPS://PAC.METTORIUS.COM/DEVICE/21:210263

It is RECOMMENDED that the URL locates a human readable web page which at least discloses information about the issuer. The URL MAY also point to a default PAC-ID Resolver that is implemented as a web application on that URL.

Transmission

PAC-ID’s MAY be transmitted by any means adequate for the serialization format (URL Format) of PAC-IDs (e.g. QR code, NDEF, iBeacon, etc.).

Visual Markers

If a PAC-ID is represented as QR code or data matrix code, a visual marker MUST be added.

The example PAC-ID HTTPS://PAC.METTORIUS.COM/DEVICE/21:210263 represented as QR code.

Placement of the Visual Marker

• The visual marker MUST be placed to the right or to the bottom of the 2D-code.
• The spacing between visual marker and the 2D-code MUST match its minimum quiet zone (yellow area, e.g. 4 modules for QR codes, 1 module for Data Matrix codes)
• Visual markers placed at the bottom SHALL start from left to right. Right to Left is allowed when surrounded by RTL languages.
• Visual markers placed at the right, SHALL start from top to bottom.

Placement of the Visual Marker

Visual Marker Design

• Each visual marker SHALL consist of marker squares (blue), which consist of 5x5 2D-code modules each.
• There MUST be one 2D code module of space (green) between the visual marker squares.
• Each visual marker square MUST have at least one of its 25 2D-code modules set (black).

Visual Marker Design

Recommendations

Identifier Encodings

If designing new systems based on existing identifiers, consider using Base36 encoded PAC-ID identifiers for maximizing efficiency when embedded in a QR Code or DataMatrix codes.²

For legacy systems it is recommended to use identifiers as is (with URL-encoding for characters that don’t comply with the character space valid for id segments).

Design Considerations for id segments

Using multiple id segments might seem like unnecessary overhead at first. Adding a few additional id segments, however considerably increases the usefulness of PAC-IDs. In conjunction with other Smart Building Blocks, especially the PAC-ID Resolver. The PAC-ID Resolver is able to provide user-handovers/routing to systems that provide information about the corresponding PAC-ID. See PAC-ID Resolver on GitHub for more info.

• Add additional id segments containing information that allows lookup in pre-existing systems (e.g. for a device, its serial number might be the only necessary id segment needed for a uniqueness perspective. However, adding the article/product/model number in addition likely allows routing to considerably more content that is relevant for this device)

• Add id segments that partition by resource type or domain. (e.g. a CDS can only provide more information about Chromatography runs, but not MS runs)

• Using the key/value syntax (id segment key : id segment value) with well-known id segment keys enables PAC-ID routing in generic contexts.

PAC-ID Extension

PAC-IDs can be extended with custom information after a * character. As stated above, the * character and subsequent characters are not part of the PAC-ID and can therefore be used for custom extensions.

A well-known extension is the T-REX.

Terminology Used

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 "Key words for use in RFCs to Indicate Requirement Levels".

FAQ

See here.

License

Shield:

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Footnotes

1. according to RFC 3986. All other URI components MUST be empty. ↩

2. When using Base36 encoding, the character set required is limited to 0–9, A–Z (upper-case only), which allows efficient encoding that for example only consumes 5 1⁄2 bits/character in a QR code. ↩