Transactions

In a simple RESTful system, resources are created/updated/deleted directly using a trust based model (usually the actions are authenticated, but the server assumes that the clients are maintaining referential and other system integrity).

However some of the transactions that may be implemented using this specification are subject to additional requirements about how the provenance of the information. Generally these requirements concern who changed the information, when and why. This kind of information isn't part of the normal content model of a resource, but may be required in order to allow the interaction to complete successfully.

To handle this requirement, this specification defines a "transaction" which is an XML element with defined content that is inserted into a create/update request as the second child element of the request (after the id), or carried as the content of a delete request. The transaction element carries this additional information required.

Not all interactions require the transaction element. In a typical system of systems, there may be a single administrative master that only accepts updates to the patient record with a fully populated transaction element, but itself pushes out changes to patient records to multiple other systems without a transaction, as these secondary systems are not performing provenance tracking.

TODO: should the transaction stuff include a transaction manager to mediate multiple post commits?

Resource Status

Every resource defines a "status" element, which contains information about the status of the resource. The contents of the status element may be linked to the transactions that are defined for the object. The resource may have defined interactions that change the status; the correct transaction may be required in order to update the resource status.

Content Model

The transaction element includes information relating to the following:

• The name of the transaction
• The real world time of the transaction
• Whether transactionFlags apply (see below)
• The person/device responsible for the real world event ("performer")
• The person/device responsible for recording the event in the information system ("recorder")
• The person with overall clinical responsibility for the event ("supervisor")
• The workflow context
• An authorization under which the event happened
• Other parties (persons, organizations, systems) who are recipients of the information
• Reason for the transaction (can be simple or complicated)
• The location at which the event happened

Whether this information applies depends on the particular transaction. As a consequence, almost all of the elements are optional for general use.

 <transaction>
   <name mand type="string">The name of the transaction</name>
   <time opt type="HumanDate">When the transaction happened</time>
   <flags opt type="boolean">Whether transaction flags are in use</flags>
   <performers> <!-- Zero+ -->
     <performer opt type="Resource(Person|Device)">The person/device 
          responsible for the real world event</performer>
   </performers>
   <recorders> <!-- Zero+ -->
     <recorder opt type="Resource(Person|Device)">The person/device 
          responsible for recording the event in the information system</recorder>
   </recorders>
   <supervisor opt type="Resource(Person)">The person with overall 
          clinical responsibility for the event</supervisor>
   <location opt type="Location">Where the event happened</location>
   <notifications>  <!-- Zero+ -->
     <notification opt type="Resource(Person|Organization|System)">Other
          parties who are notified of the event>
   </notifications>
   
   <!-- 
   todo 
    authorizations, reasons, care plans, workflows are yet to be modelled.   
   -->
 </transaction>

Notes:

• The name of the transaction can be a specifically defined name, or "create", "update", or "delete"

Transaction Flag

Some transactions require direct indication of which data has changed in an instance, and how, in addition to the general transaction element.

The transactionFlag attribute is used to mark the transaction status of particular elements. It has no meaning in regard to the data, and is only used in these particular transactions where data provenance is closely tracked. The possible values are:

The transactionFlag attribute can only be used when the transaction element specifically indicates that the transactionFlag is in use, and should not otherwise be encountered.

© 2011