PA Registry State Model

Return to PA_Interdependent_Registries project page

HL7 Administrative Registry Dynamic Model

Registration vs. Registry Record

The events in a registry can be mapped to state changes in a Registration Act. Note that for consistency the Registration Act is located in a common Control Act wrapper while the content of the registry (identified person, patient, service delivery location, provider, identified organization) is a Role class defined in the content domain. Both the Registration Act and registry record (Role) can have "state". Current specifications do not clarify the relationship between Registration status and Registry Record status.

Currently Supported Registry Dynamic Model

The current HL7 V3 messaging standards for administrative registries are based on a (more or less) common dynamic model consisting of three basic patterns:

1. Simple Notification
   • A Registry Informer sends information to one or more Registry Tracker application roles whenever a registry record is added or changed. The receivers have no stated responsibilities.
   • The Master File / Registry Event Notification RMIM describes the Registration Event for this interaction.
2. Query and Response
   • A Registry Query Placer sends a set of parameters to a Registry Query Fulfiller application role that is responsible for returning all records that match the parameters.
   • The Query by Parameter control act RMIM describes the query placement
   • The Registry Query Response RMIM describes how the matching Registration Events are returned
3. Request and Fulfillment
   • A Registry Request Placer sends a request for action to a Registry Request Fulfiller application role that is responsible for accepting or rejecting the request and informing the requestor of the result or reason for rejection.
   • The Master File / Registry Request Control Act RMIM describes the Registration Request
   • For Patient Administration registries:
     • If the request is accepted the Registry Request Fulfiller returns a Master File / Registry Event Notification
     • If the request is rejected the Registry Request Fulfiller returns the original request Master File / Registry Request Control Act with the reason for the rejection in the Detected Issue class
   • For Personnel Management registries:
     • The Registry Request Fulfiller returns a return a Master File / Registry Event Notification indicating whether the request was rejected or accepted using the Acknowledgement type code in the Application Acknowledgement transmission wrapper

Currently Supported Registration Events

As of 2010 the HL7 administrative registry domains include notification messages for the following registration events:

State Transition	From / To	Business Event
activate	null / active	active record added to registry
revise	active / active	active record revised in registry
nullify	normal / nullify	erroneous record in registry nullified
obsolete	normal / obsolete	duplicate record in registry registry replaced by newer record

The following diagram represents these actions as state transitions of a Registration Act.

Additional Registration Events to Consider

A more comprehensive description of registry behavior would include the ability to set records in the registry as either temporarily or permanantly inactive. Here is that more comprehensive set of registration events:

State Transition	From / To	Business Event
activate	null / active	active record added to registry
complete	active / completed	active record is inactivated (closed)
revise	completed / completed	inactive (closed) record is revsied
reactivate	completed / active	inactivated (closed) record is reactivated
revise	active / active	active record revised in registry
suspend	active / suspended	active record is temporarily inactivated
resume	suspended /active	temporarily inactivated reacord is made active again
complete	suspended / completed	temporarily inactivated record is made permanatly inactive
revise	suspended / suspended	temporariy inactivated record is revised
complete	null / complete	inactive (closed) record is added to the registry
nullify	normal / nullify	erroneous record in registry nullified
obsolete	normal / obsolete	duplicate record in registry registry replaced by newer record

The following diagram represents these actions as state transitions of a Registration Act.

Registry with Verification Events

One could envision a more complex registry that employs a two step process for adding records. Each candidate registration would be subjected to business processes such as duplicate checking or credentials verification before it is processed into the official registry. The new, held, cancelled states can represent this:

State Transition	From / To	Business Event
create	null / new	pending record is submited to registry
activate	new / active	pending record satisfis business rules and is added as an active record to the registry
hold	new / held	pending record is pulled back from vetting process for exceptional processing
release	held /new	exceptional processing is completed and pending record returned to normal vetting process
cancel	new / cancelled	pending record processing is stopped because the record failed the vetting process
cancel	held / cancelled	pending record rejected during exceptional processing
revise	new / new	pending record is revised

The following diagram represents this more complex state machine for a registry.

Questions

If the state transitions listed above reflect real events in (some) registry then we must decide which state transitions represent:

• Information that should be the subject of a notification message
• A state transition could be requested by an external application