Registration Act

From Wiki for HL7 Norge
Jump to: navigation, search

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:

File:RegEvnAct.png
Select thumbnail to enlarge; modified from NE2008

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:

File:RegReqAct.png
Select thumbnail to enlarge; modified from NE2008

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

  • SHALL send the 'software user identifier / login name' as assigned by the sending organization. Each software application that assigns 'user identifiers' will need to assign an OID to their own identification scheme.
  • SHOULD (additionally) send the HPR Number.

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.