Send comments on this topic. | Back to Introduction - All Topics | Help Version 17.5.11.1
An application starts a context change transaction when a user instructs the application to set the value for one or more identity subjects of a common clinical context within the user's context session. An example of this scenario would be when a clinician is selecting another patient's records for viewing. While the transaction is occurring identity and annotation subjects can be changed, added or removed. However only one transaction can be in progress at a time.
During a context change transaction, the context manager creates a transaction-specific version of context data that does not contain any context items for any subjects. When the application that instigated the transaction completes its changes to the context data with a new proposed context by setting context data item values for one or more subjects it informs the context manager. The context manager proceeds to “post-fill” the proposed context before conducting a two-phase process to coordinate making the same context changes in the other applications within the common context.
When the context manager begins the post-fill process any unchanged subject data is automatically copied to the proposed context. Next, the manager calls the mapping agents for each identity subject, if they exist, to add the additional identifiers that each real world entity or concept is known by. Annotation agents are invoked (if present) for each annotation subject to add additional information that describes or is otherwise pertinent to each context subject. Once the post-fill process is complete the context manager uses the proposed context change to begin the process of propagating the information to the other applications within the common context.
In the first phase, the context manager surveys the other applications to determine which ones can apply the new context. An application may not be able to apply the changes if it is blocked (i.e. waiting for the user to enter data) or may lose unsaved work if the changes are applied. The context manager notifies the instigating application of the survey results. If all of the applications are willing to apply the new context, then they are all instructed by the context manager to make the changes. The instigating application should ask the user to decide how to proceed if at least one application is unable or unwilling to make the proposed changes. The user should have following options:
Once a decision is made by the user the context manager notifies the context participant applications to complete the second phase of the transaction. The applications are synchronized with the current context when all of the applications are willing to apply the new context or when the user instructs the participants to apply the changes. If the user cancels the context change, the active context remains unchanged. If the user instructs the instigating application to break the link, then it is no longer synchronized with the rest of the applications and it is required to prominently display a context link indicator to indicate this fact to the user. An application that has broken the link to the common context can reconnect and apply the common context when instructed by the user at later time.
Note: The common context may change between the time the application disconnects and the time it reconnects to the common context.Within the Context Management Architecture an instigating application only needs to set the values for the context items that it wants to change and only needs to set the subject context items that it is capable of setting. Also, a participant application does not have to deal with all subjects, or all of the context data items defined for a subject. Applications are required to set the value for at least one identifier (Id) item for at least one identity subject to instigate context change transaction.
The high-level events that transpire when a user selects a patient record are summarized in the folowing figure
