An Invitation is a communication from one user to another that authorizes a predetermined action. The most common invitation is when someone registers as a Tolven user. Most invitations involve an email notification. Most invitations, especially those involving protected health information, avoid revealing information through email. Rather, they rely on the parties involved being logged into Tolven.
Consider a simple clinical scenario where the system communicates to a user: When an urgent result is received from the lab for a certain patient, the clinician responsible for that patient wants to be notified. The system could simply send an email with the pertinent information. But that would most likely create a privacy risk and be in violation of security requirements. Instead, the pertinent information is stored in an invitation and the email notification will only refer to that invitation. The receiver must then be logged in to see the details.
This scenario occurs between two users in the same account: One clinician may want another clinician to review a specific patient’s record (or some part of the record). One account user creates an invitation referring to the patient and sends it to the other account user. The invitation carries not only the reference to the patient but also any notes associated with the invitation. However, it is usually best to avoid writing notes in the invitation and rather put the notes in a clinical document stored with the patient. In other words, the invitation is simply referring directly into a document stored in the patient’s record. This approach is the most secure and provides the best audit trail.
A third scenario has a user inviting the system to perform some activity.
An invitation is not a free-pass: The user must be authorized to perform the invited action.
An invitation begins life an entry in the invitation table.
an XML JMS message which is sent to the invitation queue.
The invitation queue then sends the invitation email using the instructions provided in the XML. A record of the invitation is created in the database.
Control remains within the invitation system until one of two events occurs:
- The invitation id is presented to the system for execution. In other words, the recipient has returned with the invitation.
- A followup timeout occurs.