Registration Act
The Registration Act is a modeling construct used in Registries. It, and its associated classes, capture meta information about a registration of a role (e.g. patient, person) in a registry. The meta information includes such things as: who registered the role; when was the role registered and whether or not the registration is still an 'active' one (i.e. whether the Role can be used and queried for).
From a modeling perspective it forms a predefined part of the Payload of an interaction. From an implementation perspective it appears to be part of the ControlAct Wrapper (the registration act is included in the XML schema for a particular type of Controlct wrapper).
Information Model
The Registration Act occurs in multiple flavors. Each flavor is documented in a separate section below.
- RegistrationRequest: this flavor is used in a request message sent to a Registry with the intent to request that a new registration be added to that registry, or with the intent that an existing registration be updated.
- RegistrationEvent: this flavor is used to send updates (i.e. responses to requests/notifications of changes) from a Registry to a receiving software application.
RegistrationEvent
The RegistrationEvent flavor is most often used. It is used to send (responses to requests/notifications of changes) from a Registry to a receiving software application. The model is shown below:
The entry class in this model is the RegistrationEvent class. A registry assigns a unique identification to each and every registration (a different Id than the Id of the Role being registered). The registrationEvent class has the following attributes:
Class | Component | Documentation |
RegistrationEvent | classCode, moodCode | The registration activity of this set of Role-related data. @classCode contains the fixed value ‘REG’, @moodCode contains the fixed value ‘EVN’ |
id | Identifies the registration process within the Registry of a set of Role-related data. If this identifier can't be valued because the registry doesn't support it, the nullFlavor ‘UNK’ should be used.
<id nullFlavor="UNK"/> | |
statusCode | @statusCode contains the registration status of the registration. The value will be either ‘active’ (for registrations that can be actively used and queried for) or 'obsolete' (for registrations that have been replaced by other registrations, e.g. after a merge). | |
subject1 | Identifies the object that is in the registry. @typeCode contains the fixed value ‘SBJ’. | |
PayloadRole | This is a placeholder for the Role and its associated details. For example: the Generic Patient Model. |
The custodian and assignedEntity classes identify the organization responsible for the Registry. These classes contain the following attributes:
Class | Component | Documentation |
custodian | typeCode | Identifies the custodian of the registration, the organization that maintains the registry. @typeCode contains the fixed value ‘CST’. |
assignedEntity | id | Contains the identity of the organization that has the responsibility for the Registry (and this registration). This attribute uses the II datatype. |
The replacementOf, priorRegistration and the priorRegisteredRole classes are only applicable if an earlier registration is being replaced by a new one. These classes may not be used in Norwegian implementations.
Examples:
1. Registration information sent by the Role-registry when a new Role has been registered or an update has been made to an existing registration.
<registrationEvent classCode="REG" moodCode="EVN"> <id nullFlavor="UNK"/> <statusCode code="active"/> <subject1 typeCode="SBJ"> <patient classCode="PAT"> ... details not shown .. </patient> </subject1> <custodian typeCode="CST"> <assignedEntity classCode="ASSIGNED"> <id extension="408" root="2.16.578.1.34.1"/> </assignedEntity> </custodian> </registrationEvent>
Note: Any other classes/attributes not listed above, but shown in the diagram, are reserved for future use in Norway. Sending applications SHOULD not use these model elements; receiving applications SHALL nor produce an error if these model elements are present, and MAY ignore these model elements if present. |
RegistrationRequest
This Registration Act flavor is used in a request message sent to a Registry with the intent to request that a new registration be added to that registry. The model is shown below:
The entry class in this model is the RegistrationRequest class. The registrationRequest class has the following attributes:
Class | Component | Documentation |
RegistrationRequest | classCode, moodCode | The registration activity of this set of Role-related data. @classCode contains the fixed value ‘REG’, @moodCode contains the fixed value ‘RQO’ |
id | @nullFlavor contains the fixed value ‘UNK’.
<id nullFlavor="UNK"/> | |
statusCode | @statusCode contains the fixed value ‘active’ | |
subject1 | Identifies the object that is to be added to the registry. @typeCode contains the fixed value ‘SBJ’. | |
PayloadRole | This is a placeholder for the Role and its associated details. For example: the Generic Patient Model. |
The author and assignedEntity classes identify the organization responsible for the Registry. These classes contain the following attributes:
Class | Component | Documentation |
author | typeCode | Identifies the author of the registration request. @typeCode contains the fixed value ‘AUT’. |
assignedEntity | id | Contains an identifier for the person who requested the registration. This attribute uses the II datatype. As long as there is no national identifier for all employees in healthcare the sender
|
Example:
1. Request to add a patient (PAT) role to a registry. The request is authored by the person with Id 12345. In this example that Id identifies a software application user within Helse Vest.
<registrationRequest classCode="REG" moodCode="RQO"> <id nullFlavor="UNK"/> <statusCode code="active"/> <subject1 typeCode="SBJ"> <patient classCode="PAT"> .. details of the patient role not shown .. </patient> </subject1> <author typeCode="AUT"> <assignedEntity classCode="ASSIGNED"> <id extension="12345" root="2.16.578.1.34.3.1"/> </assignedEntity> </author> </registrationEvent>
Note: Any other classes/attributes not listed above, but shown in the diagram, are reserved for future use in Norway. Sending applications SHOULD not use these model elements; receiving applications SHALL nor produce an error if these model elements are present, and MAY ignore these model elements if present. |