Registry

A Registry is an Application that maintains identifying/definitional data related to a specific category of objects.

See also: Master File/Registry Control Act Wrapper

Characteristics of Registries, Masterfiles & Repositories

Registry Role

Static Characteristics

• The primary purpose of a Registry Role is to help manage the registrations process.
• subject matter reflects an information management process requiring all of the Act mood completion cycle
• Registry Role supports an application:
  • that is the system-of-record for regulatory or administrative data concerning a particular (single) class of Role, Entity or Service Act.
  • whose contents are peripheral information not categorized as clinical in nature but required to operationalize clinical transactions.
• subject has at least one identifying key

Dynamic Characteristics

• accepts adds and updates
  • A Registry Role may receive Registration requests from multiple (conflicting and/or authoritative) sources.
• does NOT accept notifications from systems having like content. (A patient registry does not accept notifications from other patient registries, with the intent of incorporating that data into its own records.)
• can be a source of notification messages to other systems, some of which may be replicating the data in whole or part (e.g. as reference tables)
• may support publish & subscribe
• secure storage and maintenance
• Respond to searches using one or more pre-defined parameters in order to find and retrieve a unique occurrence of an entity.
• a Registry may be queried by Secondary Keys (to get hold of the primary key) or by the primary key of its subjects.
• a Registry will respond to queries with subject records, without any additional pre-processing; i.e. no application logic is applied to the registry subjects other that that which is related to the management of the registrations.

Masterfile Role

Static Characteristics

• table or database containing stable, commonly required information about entities or service definitions
• can be master index that points to other data sources and thus is limited to primary search keys.
• data may be subset of information from a Registry
  • Rene: I don't agree with the statement that the static scope of Master Files would be smaller than the scope for registries.
• does not track state transitions of Roles or Service Events.
• subject has at least one identifying key
• metadata (other than registration status) is of little or no importance

Dynamic Characteristics

• does NOT accept update/change requests from other systems
• may be updated via receipt of a "notification" of change in EVN mood, or else replicated and distributed as updated version.
• an authoritative source of data for other systems
• may periodically sends its contents to other systems in the form of Notifications
• can be replicated and versioned
• supports queries and typically is optimized for high throughput
• ? support for publish & subscribe
• is used when data changes infrequently and it is the most efficient for all applications to maintain a local copy of the data.
• a Master File Role has the aim of keeping Master File Trackers synchronized with the contents of the Master File Role.
• a Master File Role is queried using the primary key of its subject (even though data that might be regarded as secondary keys is present.)
• a Master File will respond to queries with subject records, without any additional pre-processing; i.e. no application logic is applied to the registry/master file subjects other that that which is related to the management of the registrations.

Other Characteristics

• can/should only be defined in terms of its dynamic behaviour
  • Rene: We may need to state something about the static model when we try to distinguish between an Registry and a Repository. At this point in time I believe that this is not required in order to distinguish bewteen a Master File and a Registry.. but I could be wrong.
• Oftentimes commercialized as marketed dataset e.g. American Medical Assn's Physician Masterfile

Repository Role

Examples

• UK central systems - - patient demographic service is a registry of patients (that also contains) participations such as next of kin and registered GP.

Static Characteristics

• subject has at least one identifying key

Dynamic Characteristics

• supports the functions of a registry, augmented by other repository functions
• a Repository will support queries which focus is on the non-registration aspects of its subjects, and where application logic will be used to combine repository contents into a response.
• does richer processing (than Registries) based on the semantics of the structures being stored, to return information that is closer to the consuming systems needs
• can be a source of notification messages to other systems, some of which may be replicating the data in whole or part (e.g. as reference tables)

Characteristics of four idealized registry types

• a RoleRegisty - the usual sort of reference application that we are all familiar with and sometimes refer to as Masterfiles.
  • Examples
    • provider, patient, client (Person entity)
    • location, facility
  • Static Characteristics
    • restricted to a single class of Entity (person, organization, place)
    • hybrid systems may contain more that one entity class, but the data is logically partitioned.

• a RoleDefinitionRegistry - a registry containing role definitions for entities of a particular kind
  • Examples
    • a registry of Medications (substance Entity playing the role of a medicine)
  • Static Characteristics
    • Entity.determinercode = KIND (never INSTANCE)

• an ActRegistry
  • Examples:
    • a registry of reference acts (e.g., Netherlands example) . . . contains key identifying features (i.e. metadata keys) of care related data as registered by individual care providers. The registry entries can be used by an healthcare provider to gain access to data as present in other providers' systems.
  • Static Characteristics
    • contains key identifying features (i.e. metadata keys)
  • Dynamic Characteristics
    • used to identify and locate service event data held in other system(s)

• an ActDefinitionRegistry - a registry describing acts in definition mood.
  • Examples
    • a registry of medical procedures, lab exam definitions, drug protocol definitions
  • Static Characteristics
    • acts in definition mood

Correspondence

(March 18, 2005)

Bob,

Two initial comments: -The Act Reference registry is just one example (probably the only one we have at the moment, although Charlie may have another one in mind) for an Act registry. -I suggested on the call that a Master File application should be defined in terms of its dynamic behaviour: if a Registry does NOT accept updates/changes from third parties, and periodically sends its contents to other systems in the form of Notifications, then its a Master File.

TTYL,

-Rene

Bob wrote: On our concall yesterday Rene made an interesting case for the symmetrical use of Act and Role registries, arguing in effect that an ActReference registry is a "Registry" because it is used in the same manner as a Role registry.

We agreed to explore this notion a bit further and see if it resolves two problems:

- are there true parallels between Act and Role registries (thereby justifying the use of common dynamic models)

- does this help us come up with suitable definitions for some key terminology? (For example, I've been struggling to come up with Masterfile/Registry definitions that characterize the static content of these applications. The results haven't been particularly useful without reference to the use/behaviour of these applications.)

During the concall we identified 4 idealized registry types that should be our basis for comparison/characterization.