PA Registry State Model
Contents
HL7 Administrative 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:
- 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.
- 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
- 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
- If the request is accepted the Registry Request Fulfiller returns a Master File / Registry Event Notification
- If the request is rejected:
- For Patient Administration registries 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 PersonnelManagement registries the Registry Request Fulfiller returns a return a Master File / Registry Event Notification indicates that the request was rejected by the Acknowledgement type code in the Application Acknowledgement transmission wrapper
Registration Events
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.
Currently Supported Registry 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 Registry 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 | ||
reactivate | completed / active | inactivated 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 | complete |
nullify | normal / nullify | erroneous record in registry nullified | ||
obsolete | normal / obsolete | duplicate record in registry registry replaced by newer record |
Registry with verification process
The following diagram imagines a more complex state machine for a registry.
Envision a registry that follows a two step process for adding records to the official registry. Each candidate registration must pass certain 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 satisfied 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 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 |
| active
| 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
|}