IDS7 DevelopersGuide - DesktopSync
IDS7 DevelopersGuide - DesktopSync
This developer's guide is intended for developers of health care applications that are to integrate with
the "IDS7 Desktop Synchronization" interface.
The desktop synchronization interface makes it possible for IDS7 and other applications to exchange
information about the current examination, so that all applications automatically switch to the same
examination. Synchronization can also be performed on the current patient, which is useful for applications
without the notion of current examination. The interface also provides means for the applications to
exchange information about the user currently logged on, so that the user is automatically logged on in
all applications when the user logs on in IDS7.
This guide contains tutorials and recommendations for how to integrate an application with the IDS7
Desktop Synchronization interface, as well as a reference specification of the interface.
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Related documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 How this document is organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Assumptions about the reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Conventions used in this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4 Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 What you need to use this SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 About the IDS7 Desktop Synchronization SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Setting up the Visual Studio project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4 An example project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5 Development guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1 General guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 Commands endpoint guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 CurrentCase endpoint guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4 Login endpoint guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6 Interface reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2 Common interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3 CurrentCase endpoint interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.4 Commands endpoint interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.5 Login endpoint interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.6 Data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7 SDK Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.1 CommandsProxy class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2 CurrentCaseProxy class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.3 LoginProxy class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.4 UserIdentifierFactory class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
This guide provides the necessary information for you to integrate your application and IDS7 using the
"IDS7 Desktop Synchronization" interface. The following sections describe how to read this document.
If you are new to IDS7 and the concept of desktop synchronization, it is recommended that you start
by reading chapter 2 About desktop synchronization to get an introduction of the functionality at user
level. An introduction to the design of the interface is then given in chapter 3 About the desktop
synchronization interface. Full understanding of the concepts introduced in these chapters is required
for the remaining chapters.
The guides in chapter 5 Development guides describe how the interface is intended to be used in various
scenarios. The guides do generally not go into details about each interface methods used. This level of
details is provided in chapter 6 Interface reference.
You should ideally also have basic knowledge about Windows Communication Foundation (WCF). If you
do not have any prior experience of WCF, it is highly recommended that you get a textbook on the
subject and get acquainted with the WCF fundamentals, before you start implementing the desktop
sync integration with IDS7.
Method names, parameter names and type names are written in bold font, when used inside ordinary
paragraphs. Alternatively a method or type name is written as a link to the reference documentation.
Example: ICurrentCase.Connect
Note: This marking designates a note, i.e. information that the reader should be aware of, but is peripheral
to the subject described in the nearby text.
Important: This marking designates important information that may not be immediately obvious to the reader.
■ Single log on
This chapter contains an introduction to desktop synchronization from a user's perspective. This chapter
also contains a very brief introduction to the IDS7 workstation, just to give you an idea about how the
application is organized.
IDS7 is designed for usage on computers with multiple monitors and has multiple full-screen main
windows, as depicted in the figure below.
The information window (1) gives the user an overview of the information in the PACS. Here the user
can search for patients (and/or examinations) and read requests and reports. The information window
also contains the user's worklists, each worklist being a dynamically updated set of examinations currently
of interest.
A central concept of the IDS7 workstation is the current examination, the examination that the user is
currently viewing. The current examination is marked with a green arrow and green background in the
patient history list inside the information window.
The matrix window (2) is used for defining how the images for the current examination should be
presented. The definition of a presentation states how many image windows the presentation comprises
and which image to display in which image window.
The image windows (3), finally, are used for clinical review of the images.
The information window and the matrix window are displayed on the primary monitor, while the image
windows are displayed on the additional monitors. If required by the presentation, also the primary
monitor will be used to display an image window.
Normally IDS7 synchronizes with one HIS or RIS client, but it is possible for IDS7 to synchronize with
multiple applications simultaneously.
The synchronization is either automatic or manual. Automatic sync is when the application automatically
sends a sync message to the other applications as soon as the user changes current case. The other
applications are then expected to change current case accordingly, without taking the focus from the
current application. That is, the receiving applications are expected not to activate their windows or to
change the window z-order on the desktop.
Manual sync is when the user actively selects a command in the application to synchronize the current
case to the other application. IDS7 has three different commands for manually synchronizing the current
case to the other applications, as shown in the figure below.
Each command specifies a different view for the other application to show. The other application is
expected to switch to the specified case, open the specified window or view and to activate and bring
the window to the front of the desktop.
IDS7 has support for the other applications to manually sync the current case, requesting IDS7 to bring
the information, matrix or image windows to the front.
Note: IDS7 has also a fourth command: Windows->Current RIS Window. This command only requests the
other application to activate its main window and to bring it to the front on the desktop, without
synchronizing any case.
When IDS7 receives synchronization (manual or automatic) from another application, then IDS7 always
creates a temporary worklist, named Sync Results, which matches the synchronized examination or
patient. If an examination has been synchronized, it is set as the current examination of IDS7. If the
synchronized examination or patient cannot be found in the PACS, then the Sync Results worklist will
not match anything and no patient or examination will be shown in IDS7.
The idea for the single logon feature is that when the user logs on to IDS7, the user will also be
automatically logged on in the other synchronized applications. If any of the other applications does
not accept the user, the user will not be logged on in IDS7 either. The general idea is that the same user
should either be logged on in all applications or not logged on at all.
Note: IDS7 can only initiate single log on. It will not accept single log on from other applications.
The applications also synchronize when the user is logged off in any application, so that all applications
are logged off.
A special feature of single log on regards applications that implement some mechanism to automatically
log off when the user has been idle for some time. Having this in mind, the applications must notify
each other about the user being active in any of the applications. One would for instance not want IDS7
to log off due to inactivity while the user is writing a long report in the RIS.
This chapter describes the overall design of the IDS7 Desktop Synchronization interface and introduces
the central concepts of the design.
IDS7, Version 24.1, March 2022 About the desktop synchronization interface 7
Context Manager transactions 3.2
The figure shows that the Context Manager interface is designed to synchronize IDS7 with multiple
other applications simultaneously. The normal scenario is however that there is only one RIS or HIS
client.
It should be noted that the Context Manager WCF service is hosted in a different application domain
than the IDS7 workstation application and that IDS7 communicates with the Context Manager over
the same WCF interface as the other applications. From the view of the Context Manager, there is no
difference between IDS7 and the other applications.
An application may connect to one of the endpoints or it can connect to multiple endpoints
simultaneously. Each connection is handled independently by the Context Manager.
All endpoints are bidirectional, i.e. a connecting application must implement a callback interface that
will be used by the Context Manager.
We also recognized that if IDS7 has started changing current case and the RIS fails to follow, then it
may be difficult for IDS7 to revert back to the state it had before starting to change current case. We
assume that other applications have the same difficulties to revert to a previous state.
This is the rationale for using a transaction-based communication scheme. The idea is that all applications
should vote about performing an action before any application starts doing anything, so that there will
be no need to roll back any actions.
IDS7, Version 24.1, March 2022 About the desktop synchronization interface 8
Context Manager transactions 3.2
The following sections contain examples that describe the transaction call pattern quite thoroughly,
since it is so central to the design of the Context Manager interfaces.
Important: Note that the term "transaction" used in this document has nothing to do with the built-in support for
transactions in WCF; the Context Manager transactions are just an uniform application-level call pattern
of our own design.
Note: The method names in the following examples are "generic", since the same call patterns are used both
for synchronization of current case and for single log on.
The examples show the call patterns when IDS7 synchronizes with two other applications, since this
illustrate the more general aspect of the call patterns. The normal scenario would however be that
IDS7 synchronizes with only one application.
It should also be noted that there is no difference between IDS7 and the other applications from the
point of view of the Context Manager. This means that IDS7 could be any of the applications in the
examples.
1. The scenario is started by some user input in the "initiating application". It could for instance, be
that the user selects a new current case or that the user clicks on the logout button. The initiating
application calls the Context Manager to start a transaction of the type corresponding to the user
action. Note that this is done before the initiating application starts to change current case (or
whatever the user action is).
2. The Context Manager requests the other applications to vote if they agree to perform the suggested
action or not.
IDS7, Version 24.1, March 2022 About the desktop synchronization interface 9
Context Manager transactions 3.2
3. The "listening" applications evaluate if they can perform the suggested action. A reason to deny
would for instance be that the application has unsaved data entered by the user. It is important that
the applications perform this evaluation without requiring any user input (for instance by opening
a pop-up message box).
4. The Context Manager waits for all queried applications to register their votes.
The Context Manager informs the initiating application that the transaction has been approved,
since all voting applications have approved the transaction.
5. The initiating application notifies the Context Manager that the transaction should be "committed"
(that is, the action suggested by the transaction should be performed).
The initiating application then starts to perform the action, which for instance could be to change
current case.
6. The Context Manager notifies all "listening" applications that the transaction should be committed.
7. The "listening" applications perform the suggested action and notify the Context Manager when
they have finished.
8. The Context Manager waits for all applications to report that they have finished "committing" the
transaction and then it notifies all applications that the transaction has finished successfully.
1. The scenario is started by some user input in the "initiating application". It could for instance be
that the user selects a new current case. The initiating application calls the Context Manager to start
a transaction of the type corresponding to the user action. Note that this is done before the initiating
application starts to change current case.
2. The Context Manager requests the other applications to vote if they agree to perform the suggested
action or not.
IDS7, Version 24.1, March 2022 About the desktop synchronization interface 10
Context Manager transactions 3.2
3. The "listening" applications evaluate if they can perform the suggested action. In this scenario,
application #1 has an unsaved report and votes against the transaction. It states a rationale along
with the denying vote. The rationale could be: "There is an unsaved report. Save the report and try
again."
4. The Context Manager waits for all queried applications to register their votes.
5. Since the Context Manager has received a denying vote, it notifies all applications that the transaction
was cancelled by voting. The notification contains information about which application that voted
against the transaction and the rationale given by the application.
6. The initiating application informs the user that the action could not be performed. The message
given to the user contains both the name of the denying application and the rationale given by the
denying application.
1. The scenario is started by some user input in the "initiating application". The initiating application
calls the Context Manager to start a transaction of the type corresponding to the user action.
2. The Context Manager requests the other applications to vote if they agree to perform the suggested
action or not.
3. The listening applications evaluate if they can perform the suggested action.
4. The Context Manager waits for all queried applications to register their votes. If all votes approve,
then the Context Manager informs the initiating application that the transaction has been approved.
5. Now the initiating application for some reason decides not to go through with the action that it
initially suggested. It notifies the Context Manager that the transaction should be cancelled.
IDS7, Version 24.1, March 2022 About the desktop synchronization interface 11
Context Manager transactions 3.2
6. The Context Manager notifies all applications that the transaction has been cancelled.
1. The scenario is started by some user input in the "initiating application". The initiating application
calls the Context Manager to start a transaction of the type corresponding to the user action.
2. The Context Manager requests the other applications to vote if they agree to perform the suggested
action or not.
3. The "listening" applications evaluate if they can perform the suggested action.
4. The Context Manager waits for all queried applications to register their votes. In this scenario, all
votes are approving and the Context Manager informs the initiating application that the transaction
has been approved.
5. The initiating application notifies the Context Manager that the transaction should be committed
and then starts to perform the suggested action.
6. The Context Manager notifies all "listening" applications that the transaction should be committed.
7. In this scenario, "listening" application #1 encounters an error while performing the action that was
suggested by the transaction. It notifies the Context Manager and supplies a descriptive error message.
IDS7, Version 24.1, March 2022 About the desktop synchronization interface 12
Context Manager transactions 3.2
8. The Context Manager waits for all applications to report that they have finished committing the
transaction.
The Context Manager notifies all applications that the transaction failed, since one application has
reported an error in the commit phase. The notification contains the name of the failing application
as well as the error message given by the application.
9. All applications notify the user that an error has occurred and that the applications now may be out
of sync. It is important that this notification is done in a non-blocking way. It could for instance be
a message and an icon on the application's status bar. There should be no pop-up message boxes
that require the user to click OK.
1. The scenario is started by some user input in the "initiating application". The initiating application
calls the Context Manager to start a transaction of the type corresponding to the user action.
2. The Context Manager requests the other applications to vote if they agree to perform the suggested
action or not.
3. The "listening" applications start to evaluate if to approve or deny the transaction. "Listening"
application #1 encounters an error and notifies the Context Manager with a descriptive error message.
4. The Context Manager waits for all queried applications to register their votes. Since one application
has reported an error, it notifies all applications that the transaction failed. The notification contains
the name of the failing application as well as the error message given by the application.
5. The initiating application notifies the user that the action cannot be performed.
6. All applications notify the user that an error has occurred and that the applications now may be out
of sync. It is important that this notification is done in a non-blocking way. It could for instance be
a message and an icon on the application's status bar. There should be no pop-up message boxes
that require the user to click OK.
IDS7, Version 24.1, March 2022 About the desktop synchronization interface 13
Callback interface considerations 3.3
This design pattern becomes apparent if you study the call graph examples for the Context Manager
transactions. See section 3.2 Context Manager transactions.
• It increases the performance of the desktop sync, since more work is done in parallel.
The proxy classes provided in the SDK implement asynchronous scheduling of callbacks and should
preferably be used. See chapter 7 SDK Reference.
Assume, for instance, that the Context Manager requests your application to vote about changing current
case and your application have an unsaved document. Your application should not open a pop-up dialog
box, asking the user if the document should be saved or not. The application should instead just vote
not to change current case, providing the context manager a descriptive rationale. The application that
requested the change of current case will show the rationale to the user.
If your application encounters an unexpected error while processing a callback, it should not open a
pop-up error message box. It should instead call ITransactedService.ReportTransactionError on the
Context Manager.
The reason for these recommendations is that your application may not be on top on the desktop while
processing the callbacks, so a pop-up dialog will not be visible to the user. It just appears to the user as
if the applications have locked.
1
ILoginCallback.GetCurrentUser is an exception to the general rule of no data returned by callbacks.
IDS7, Version 24.1, March 2022 About the desktop synchronization interface 14
Callback interface considerations 3.3
Exception to the rule above is if your application has initiated a transaction as a direct result of user
input to your application. Your application is then of course allowed to show message boxes to report
if the transaction was denied or failed.
Assume that your application has approved to change current case in the voting phase of a transaction.
Assume further that the user starts editing a report before the transaction enters the commit phase. Now
it is not possible to change current case any more and the commit phase will fail.
One way to prevent user interaction would be to pop-up a modal dialog while the transaction is in
progress and to automatically close the dialog when the transaction has finished.
IDS7 uses a progress dialog to prevent user interaction while processing a transaction.
Other situations where the user must be made aware of errors are, for instance, if your application
unexpectedly loses contact with the Context Manager. Or, if your application encounters an error while
processing a callback and it then fails to call ITransactedService.ReportTransactionError to report the
error to the Context Manager.
In IDS7, we have designed a warning icon on the toolbar of all windows. The icon becomes visible when
a desktop sync error is detected and it is automatically hidden when the next successfully committed
transaction has been performed. The user can click the icon to obtain details of the error in a balloon
tip. The important feature is that the icon and the balloon tip do not block the application.
IDS7, Version 24.1, March 2022 About the desktop synchronization interface 15
Callback interface considerations 3.3
IDS7, Version 24.1, March 2022 About the desktop synchronization interface 16
4 Getting started
■ An example project
This chapter gives a practical introduction on how to get started integrating with the IDS7 Desktop
Synchronization interface. Topics covered are instructions on how to set up the Visual Studio project
and how to use the IDS7 Desktop Synchronization SDK (software development kit).
Along with the development environment, and this document, you will need the source code (and/or
binaries) included in the SDK that you need to incorporate in your application (see section 4.2 About
the IDS7 Desktop Synchronization SDK). The provided source code is written for Microsoft .NET 4.0
and the binaries have been compiled for Microsoft .NET 4.0. In order to be able to compile .NET 4.0
code you need Microsoft Visual Studio 2010 or newer.
To be able to test the integration, you will need access to a running instance of the IDS7 workstation.
The SDK source code is also provided in compiled format; in the .NET assembly
Sectra.Client.ContextManager.Proxy.dll.
The most important file in the SDK is ContextManagerContracts.cs, which contains the service and
data contracts of the Context Manager WCF service. The documentation of the content in this file is
available in chapter 6 Interface reference.
The other files contain client-side utilities for establishing a connection to the Context Manager. The
content of these files is documented in chapter 7 SDK Reference.
See section 4.3 Setting up the Visual Studio project for instructions on how to include the SDK in your
application.
Note: It is not necessary to use the SDK in order to integrate with the Context Manager WCF service. The
Context Manager supports metadata exchange over endpoint
net.pipe://localhost/SectraContextManager/MEX, so it is possible to let Visual Studio import the
metadata and generate proxies. Note that it is necessary to enable the MEX endpoint in the advanced
configuration for the Context Manager in IDS7 (see System Administrator's Guide Sectra Healthcare
System [2]). This is however not recommended since you will then miss some utility features included
in the SDK.
Copy the following files from the SDK to the newly created "SyncSDK" subdirectory.
In the Visual Studio solution explorer, right-click on the "SyncSDK" folder and select Add->Existing
Item.... Browse to the copied files and add them to the project.
In the Visual Studio solution explorer, right-click on the References node in your project and select
Add Reference…. Click the Browse... button in the Add Reference dialog and navigate to the source
code directory of the project. Select Sectra.Client.ContextManager.Proxy.dll and add it.
The example is a Windows application that connects to the Commands endpoint of the Context Manager
(see section 6.4 Commands endpoint interfaces). The application implements the following features:
• The GUI of the application contains a button, labeled PACS, that requests IDS7 to bring the
information window to the front.
The example is simplified and, for instance, error handling is more or less left out. The purpose is just
to give a brief overview of how a connection to the Context Manager could be established. The same
pattern, as used in the example, is also valid for connecting to the CurrentCase endpoint (see section 6.3
CurrentCase endpoint interfaces) or the Login endpoint (see section 6.5 Login endpoint interfaces).
Add references to the .NET framework WCF assemblies, as described in section 4.3.1 Adding references
for WCF support.
Include the IDS7 Desktop synchronization SDK source files, as described in section 4.3.2 Including the
SDK in the project.
Add a button to Form1. Name the button "activatePACSButton" and set the Text property of the
button to "PACS".
Double-click on the button in order to add an event handler to the Click-event of the button. For now,
we leave the body of the event handler empty.
Open Form1.cs in the source code editor. Make Form1 inherit from ICommandsCallback and let
Visual Studio generate stubs implementing the interface. For now, we leave the interface method stubs
empty.
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.ServiceModel;
using Sectra.Client.ContextManager;
namespace CommandsTest {
public partial class Form1 : Form, ICommandsCallback {
...
#endregion
#endregion
}
}
...
}
catch {
// Ignore the error - abort the connection in the next step
}
}
Add a CommandsProxy instance as a private field of Form1 and override From.OnShown so that the
Context Manager connection is initialized when the test application is started.
Override Form.OnClosing so that the test application disconnect from the Context Manager gracefully.
this.myProxy = ConnectToCommandsEndpoint(this);
if (this.myProxy == null) {
// Here we should really start a reoccurring task
// trying to connect to the Context Manager if/when
// it comes online. That is, however, outside the scope
// of this example.
MessageBox.Show(this, "Failed to connect to the Context Manager.");
}
}
...
It should be noted that Windows do not allow an application to spontaneously bring its windows to the
front and to take over the input focus if the application is not already active. If we do not do something
about it, the result when the PACS button is clicked will be that the IDS7 item on the windows task
bar begins to flash while the test application remains active.
To get around this problem, the test application must explicitly tell windows that it allows other
applications to "steal" the input focus. This is done by calling the Win32 function
AllowSetForegroundWindow(...) before ICommands.ShowView is called.
public partial class Form1 : Form, ICommandsCallback {
...
[System.Runtime.InteropServices.DllImport("user32.dll")]
private static extern bool AllowSetForegroundWindow(int dwProcessId);
...
Start and log on to IDS7. Make sure that desktop sync is enabled (see System Administrator's Guide
Sectra Healthcare System [2]). If desktop sync was not already enabled, you should restart IDS7 and log
on again.
Start the example application. If you click the RIS button on the IDS7 toolbar, the example application
will be brought to the front on the screen. If you click the PACS button in the example application, the
IDS7 information window will be brought to the front.
This chapter contains step-by-step guides for how to perform various specific tasks with the IDS7
Desktop Synchronization interface. Before reading these guides you are encouraged to read chapter 3
About the desktop synchronization interface to get a thorough understanding of the basic concepts of
the interface.
• Call LoginProxy.CreateMarshallingProxy to connect to the Login endpoint. The proxy exposes the
service interface, ILogin, of the endpoint.
The CreateMarshallingProxy(...) method takes two parameters; the base address of the Context
Manager service and an reference to the object that implements the callback interface. The base address
of the Context Manager service is by default "net.pipe://localhost/SectraContextManager".
The example given in section 4.4 An example project contains example code for how to connect to a
Context Manager endpoint.
Note that you should not call the Disconnect(...) method if you are disconnecting due to a
ICommonCallback.ServiceIsClosing callback from the Context Manager.
The example given in section 4.4 An example project contains example code for how to disconnect from
a Context Manager endpoint.
• IDS7 can request the synchronized application to bring its main window to the front on the desktop.
• The synchronized application can request IDS7 to bring one of its windows to the front.
The example given in section 4.4 An example project describes how to interact with the Commands
endpoint.
The communication pattern of the CurrentCase endpoint follows the general transaction-based call
pattern, see section 3.2 Context Manager transactions.
Do also read section 3.3 Callback interface considerations regarding general recommendations for how
to implement the Context Manager callback interfaces. Take special notice about the sections regarding
error handling.
Step 1: Initialization
The first thing that happens when the user changes current case (current examination and patient) in
IDS7 is that the Context Manager calls ICurrentCaseCallback.VoteForCurrentCase in your application.
There are two variants of this method, one that specifies which case IDS7 is about to change to and one
that is called when the new case is not known at the current time.
Step 2: Voting
In response to the ICurrentCaseCallback.VoteForCurrentCase callback, your application should evaluate
if it agrees to change current case or not. A reason to deny would be that the application has unsaved
changes on the current case and that these changes would be lost if the current case is changed. Note
that this evaluation should be performed without prompting the user for input (i.e. no dialog "Do you
want to save...?"). Do also note that your application should not begin to change current case in this
phase, it should just tell the Context Manager if it would be possible perform the suggested action or
not.
The patient and examination is known to your application. Display the patient and examination.
The current examination belongs to the current patient.
The patient is known to your application, but the There are two options:
examination is unknown.
1. Clear the user interface from all patient and related
data.
The patient is known to your application. No examination Display the patient, but do not select or highlight any
is provided. This means that synchronization is performed examination related information. This is important in
on patient only. order to prevent the applications from displaying different
examinations.
The patient is unknown to your application. Clear the user interface from all patient and examination
data.
Neither patient nor examination is provided. Clear the user interface from all patient and examination
data.
The current examination does not belong to the current Report an error by calling
patient. ITransactedService.ReportTransactionError.
Your application should call ITransactedService.CommitCompleted when it has finished switching case.
If any unexpected error occurs while switching case, your application should instead call
ITransactedService.ReportTransactionError to notify the Context Manager about the problem.
Step 1: Initialization
Before doing anything in response to user input to change current case (current examination or patient),
your application should initiate a Context Manager transaction and wait for IDS7 (and other applications)
to approve or deny the suggested action.
If your application has no notion of examinations, a transaction can be initiated on patient ID only.
Synchronization on patient ID is also applicable if it is possible to select a patient without selecting any
examination in your application.
If any of the other applications have denied the transaction, the Context Manager will instead call
ITransactedCallback.TransactionCompleted. In this case, your application should display a message
box with the information given by the parameters of ITransactedCallback.TransactionCompleted and
cancel further processing of the initial user input.
The communication pattern of the Login endpoint follows the general transaction-based call pattern,
see section 3.2 Context Manager transactions.
Do also read section 3.3 Callback interface considerations regarding general recommendations for how
to implement the Context Manager callback interfaces. Take special notice about the sections regarding
error handling.
If the call returns null, then there is no user currently logged on in IDS7. Your application should then
wait for a user to be logged on in IDS7, as described in section 5.4.2 Responding to synchronized log
on from IDS7.
If the ILogin.GetCurrentSession call returns an LoginSession instance, your application should validate
it (see section 5.4.3 Validating an UserIdentifier instance) and login accordingly.
Step 1: Initialization
The Context Manager will call ILoginCallback.VoteForLogin in your application when the user has
supplied user name and password to IDS7 and IDS7 has validated the given credentials.
Step 2: Voting
In response to the ILoginCallback.VoteForLogin callback, your application should decide whether it
agrees to log on the user specified by the given UserIdentifier or not.
• The given UserIdentifier is not valid (see section 5.4.3 Validating an UserIdentifier instance).
• The user is not known to this system or do not have permissions to log on.
Your application should call ITransactedService.CommitCompleted when it has logged on. If any
unexpected error occurs while logging on, your application should instead call
ITransactedService.ReportTransactionError to notify the Context Manager about the problem.
The main assumption is that the user databases in all synchronized systems are consistent; that is that
each user has the same login name in all user databases. The main property of the UserIdentifier data
container is hence the UserIdentifier.UserId property.
Note: To enable synchronized log on for AD users both systems are required to authenticate their users
against the same AD domain.
The data container has additional properties to make it possible for the synchronized applications to
verify that the identifier really originates from IDS7 and to verify that it has not been tampered with.
The additional properties are:
• UserIdentifier.FullName - This property holds the full name of the user. You could optionally check
that this name is consistent with the full user name configured in your database. This as an extra
precaution to avoid user mix-ups due to an IDS7 user having the same login name as another user
in your system. Note that the formatting of the full name is not standardized and may differ between
Sectra Healthcare System installations.
• UserIdentifier.TimeStamp - This is the time for when SHS created this identifier. The purpose of
the timestamp is to prevent malicious software from intercepting user identifiers and storing them
for later use. You should check that the timestamp does not differ more than reasonably from the
current time. Note that the identifier is created on the SHS server, so there may be some clock-skew
in comparison to the local computer time.
The timestamp is given in UTC time (Greenwich Mean Time, no daylight saving time) and formatted
as an ISO 8601 conformant string, that is "<yyyy>-<MM>-<dd>T<HH>:<mm>:<ss>".
• UserIdentifier.HashCode - This property contains a hash code so that it can be verified that this
identifier really originates from IDS7 and that it has not been tampered with. Details on how to use
the hash code is given below.
To enable user authentication via an UserIdentifier instance, both Sectra Healthcare System and your
system must be configured with a secret "single log on password" (or "system password"). This password
is used when calculating the value for UserIdentifier.HashCode and
UserIdentifier.CustomAuthenticationData which serves as the "shared secret" between Sectra Healthcare
System and your system.
2. Convert the concatenated string into a byte-array using UTF-16 encoding with little-endian byte
order, no byte order mark and no terminating null-character.
When your system receives an UserIdentifier with a UserIdentifier.HashCode that matches the hash
code or a UserIdentifier.CustomAuthenticationData that matches the security token that you get if you
calculate it using the "system password" configured in your system, then you know that the sender of
the identifier has been trusted to know the secret "system password" and hence can be trusted.
The SDK contains code for validating an UserIdentifier, see section 7.4.2
UserIdentifierFactory.ValidateIdentifier static method.
Class AssignmentInfo, just like class UserIdentifier (see section 5.4.3 Validating an UserIdentifier
instance), contains a hash code that enables the consumer of the data to ensure that the data really
originates from IDS7 and that it has not been tampered with.
2. Convert the concatenated string into a byte-array using UTF-16 encoding with little-endian byte
order, no byte order mark and no terminating null-character.
The SDK contains code that validates a UserIdentifier, including any contained AssignmentInfo. See
section 7.4.2 UserIdentifierFactory.ValidateIdentifier static method.
To prevent IDS7 from attempting to log off automatically, your application should call
ILogin.RegisterUserActivity on the Context Manager when it receives user input. For the sake of
performance, some mechanism should be implemented to prevent the application from calling
ILogin.RegisterUserActivity more often than, say, every 20 seconds.
If your application implements the same kind of automatic log off feature as IDS7, then it should call
ILogin.LastRegisteredActivity before attempting to do an automatic logout. ILogin.LastRegisteredActivity
returns a timestamp for the last user activity received by IDS7. If the timestamp is recent enough, then
it is not yet time to perform an automatic log off.
Step 1: Initialization
The Context Manager will call ILoginCallback.VoteForLogout in your application when the user has
selected to log off from IDS7.
Step 2: Voting
In response to the ILoginCallback.VoteForLogout callback, your application should decide whether it
agrees to log off or not.
A reason to deny log off could be that there is unsaved data in your application that would be lost if the
user is logged off. Note that the application should not require any user input while evaluating whether
to agree on logging off or not. (That is, no "Do you want to save...?" dialog boxes.)
Step 1: Initialization
Before doing anything in response to user input to log off, your application should initiate a Context
Manager transaction and wait for IDS7 (and other applications) to approve or deny the suggested action.
If any of the other applications have voted against the transaction, the Context Manager will instead call
ITransactedCallback.TransactionCompleted. In this case your application should display a message box
with the information given by the parameters of ITransactedCallback.TransactionCompleted and cancel
further processing of the initial user input.
Your application should call ITransactedService.CommitCompleted when it has logged off. If any
unexpected error occurs while logging off, your application should instead call
ITransactedService.ReportTransactionError to notify the Context Manager about the problem.
■ Common interfaces
■ Data types
This chapter contains reference documentation for the service and data contracts of the Context Manager
WCF service. The reference documentation focuses on interface details. Please see chapter 3 About the
desktop synchronization interface for an overview of the interface design and chapter 5 Development
guides for descriptions of how the interfaces are intended to be used.
The information in this chapter is based on the version of the service and data contracts that is provided
in ContextManagerContracts.cs in the IDS7 Desktop Synchronization SDK.
Note: If service and data contracts for the Context Manager WCF service are extracted via meta data
exchange, then the service contracts will be represented by flattened interfaces and the data contracts
will be lacking some of the utility features implemented in ContextManagerContracts.cs. The
comparison-by-value implementation of ContextTransactionIdentifier will for instance be missing.
6.1 Overview
The Context Manager WCF service has three independent endpoints:
• The Commands endpoint for forwarding of commands between applications. The service contract of
the endpoint is interface ICommands and the callback contract is interface ICommandsCallback.
• The CurrentCase endpoint for synchronization of the current case (current examination and patient)
between applications. The service contract of the endpoint is interface ICurrentCase and the callback
contract is interface ICurrentCaseCallback.
• The Login endpoint for synchronization of the user logging on and off. The service contract of the
endpoint is interface ILogin and the callback contract is interface ILoginCallback.
The endpoint interfaces implemented by the Context Manager (2) inherit from common base interfaces
(1), as described by the figure above.
For each endpoint interface there is a callback interface, designated (4) in the figure below, that is
implemented by the application that connects to the endpoint. Also the callback interfaces have common
base interfaces (3).
See also
• section 6.4 Commands endpoint interfaces
Namespace: Sectra.Client.ContextManager
Syntax
public interface ICommonCallback
See also
• section 3.3 Callback interface considerations
Syntax
[OperationContract(Name = "CommonCB_LostContact")]
void LostContact(
List<string> applicationNames
)
Parameters
• applicationNames - Contains the user-friendly names of the applications that the Context Manager
unexpectedly has lost contact with.
Remarks
Since the Context Manager unexpectedly has lost contact with one or more of the connected applications,
there is an obvious risk that the applications no longer are in sync. Your application should make the
user aware of this in a non-blocking way. It could for instance place a warning message on the status
bar.
Syntax
[OperationContract(Name = "CommonCB_Ping")]
void Ping()
Remarks
Your application is not expected to do anything as a response to this call. The Context Manager will
detect a bad connection by exceptions thrown by the WCF framework.
Syntax
[OperationContract(Name = "CommonCB_ServiceIsClosing", IsOneWay=true)]
void ServiceIsClosing()
Remarks
Your application should immediately close the connection to the Context Manager as a response to this
callback.
See also
• section 5.1.2 Disconnecting from a Context Manager endpoint
Namespace: Sectra.Client.ContextManager
Syntax
[ServiceContract(CallbackContract = typeof(ICommonCallback))]
public interface ICommonService
See also
• section 5.1 General guides
Syntax
[OperationContract(Name = "CommonService_Ping")]
void Ping()
Remarks
The Context Manager service does not do anything in response to this call, but the call will fail with
the usual WCF exceptions if the connection to the service is not OK. You should then close the current
connection and schedule a reoccurring task attempting to establish a new connection to the Context
Manager.
See also
• section 5.1 General guides
Namespace: Sectra.Client.ContextManager
Syntax
public interface ITransactedCallback : ICommonCallback
Remarks
The ITransactedCallback interface inherits from interface ICommonCallback.
See also
• section 3.2 Context Manager transactions
Syntax
[OperationContract(Name = "TransactedCB_TransactionApproved")]
void TransactionApproved(
ContextTransactionIdentifier transactionId
)
Parameters
• transactionId - A ContextTransactionIdentifier identifying the transaction that this call concerns.
Remarks
If your application is the initiator of a transaction, then the Context Manager will call
TransactionApproved when all other applications have registered approving votes for the transaction.
If any application has registered a denying vote, the Context Manager will instead call
ITransactedCallback.TransactionCompleted with a status indicating that the transaction was denied.
After the Context Manager have called TransactionApproved on your application, your application is
expected to either cancel the transaction or to start the commit phase of the transaction.
See also
• section 6.2.4.1 ITransactedService.CancelApprovedTransaction method
Syntax
[OperationContract(Name = "TransactedCB_TransactionCompleted")]
void TransactionCompleted(
ContextTransactionIdentifier transactionId,
ContextTransactionResult result
)
Parameters
• transactionId - A ContextTransactionIdentifier identifying the transaction that this call concerns.
Remarks
The Context Manager calls TransactionCompleted on all connected applications when a transaction
has finished, not just the applications that have participated in the transaction. The reason for this is to
notify applications that have connected while the transaction was in progress (and hence not participants
in the transaction), that the state of the Context Manager now has changed.
Namespace: Sectra.Client.ContextManager
Syntax
[ServiceContract(CallbackContract = typeof(ITransactedCallback))]
public interface ITransactedService : ICommonService
Remarks
The ITransactedService interface inherits from interface ICommonService.
See also
• section 3.2 Context Manager transactions
Syntax
[OperationContract(Name = "TransactedService_CancelApprovedTransaction")]
[FaultContract(typeof(ServiceClosingException))]
[FaultContract(typeof(TransactionStateException))]
void CancelApprovedTransaction(
ContextTransactionIdentifier transactionId
)
Parameters
• transactionId - A ContextTransactionIdentifier identifying the transaction that this call concerns.
Exceptions
FaultException<TransactionStateException> The given transaction identifier is not valid, or the transaction is not
in a state in which this call is applicable.
Remarks
This method should only be called as a response to the Context Manager calling
ITransactedCallback.TransactionApproved, which the Context Manager calls on the application that
has initiated a transaction when all other applications have registered approving votes.
Syntax
[OperationContract(Name = "TransactedService_CommitCompleted")]
[FaultContract(typeof(ServiceClosingException))]
[FaultContract(typeof(TransactionStateException))]
void CommitCompleted(
ContextTransactionIdentifier transactionId
)
Parameters
• transactionId - A ContextTransactionIdentifier identifying the transaction that this call concerns.
Exceptions
FaultException<TransactionStateException> The given transaction identifier is not valid, or the transaction is not
in a state in which this call is applicable.
Remarks
Your application should call this method when it has successfully performed the actions implied by the
commit phase of a transaction. The Context Manager will wait for the participating applications to
complete the commit actions and then notify all applications that the transaction has finished by calling
ITransactedCallback.TransactionCompleted.
If your application encounters an error while processing the commit actions, it should call
ITransactedService.ReportTransactionError instead of calling CommitCompleted.
Syntax
[OperationContract(Name = "TransactedService_RegisterApprovingVote")]
[FaultContract(typeof(ServiceClosingException))]
[FaultContract(typeof(TransactionStateException))]
void RegisterApprovingVote(
ContextTransactionIdentifier transactionId
)
Parameters
• transactionId - A ContextTransactionIdentifier identifying the transaction that this call concerns.
Exceptions
FaultException<TransactionStateException> The given transaction identifier is not valid, or the transaction is not
in a state in which this call is applicable.
Remarks
This method should only be called as a response to the Context Manager requesting your application
to vote about a transaction that has been initiated by another application. The Context Manager will
wait for all connected applications to register their votes and then notify your application whether the
transaction is cancelled or should be committed.
See also
• section 6.2.4.4 ITransactedService.RegisterDenyingVote method
Syntax
[OperationContract(Name = "TransactedService_RegisterDenyingVote")]
[FaultContract(typeof(ServiceClosingException))]
[FaultContract(typeof(TransactionStateException))]
void RegisterDenyingVote(
ContextTransactionIdentifier transactionId,
string rationale
)
Parameters
• transactionId - A ContextTransactionIdentifier identifying the transaction that this call concerns.
• rationale - The rationale for your application to deny the transaction. This string will be shown to
the user in the GUI of the application that initiated the transaction.
Exceptions
FaultException<TransactionStateException> The given transaction identifier is not valid, or the transaction is not
in a state in which this call is applicable.
Remarks
This method should only be called as a response to the Context Manager requesting your application
to vote about a transaction that has been initiated by another application. The Context Manager will
wait for all connected applications to register their votes and then notify all applications that the
transaction was denied.
See also
• section 6.2.4.3 ITransactedService.RegisterApprovingVote method
Syntax
[OperationContract(Name = "TransactedService_ReportTransactionError")]
[FaultContract(typeof(ServiceClosingException))]
[FaultContract(typeof(TransactionStateException))]
void ReportTransactionError(
ContextTransactionIdentifier transactionId,
string errorMessage
)
Parameters
• transactionId - A ContextTransactionIdentifier identifying the transaction that this call concerns.
• errorMessage - Information about the encountered error. This string will be shown to the user in
the GUI of the application that initiated the transaction.
Exceptions
FaultException<TransactionStateException> The given transaction identifier is not valid, or the transaction is not
in a state in which this call is applicable.
Remarks
This method should be called in response to an unexpected callback from the Context Manager regarding
any transaction. It should also be called if your application encounters an error during the commit phase
of a transaction. The context manager will then fail the transaction and notify all applications about the
error by calling ITransactedCallback.TransactionCompleted.
See also
• chapter 3 About the desktop synchronization interface
An application that connects to the CurrentCase endpoint is required to implement callback interface
ICurrentCaseCallback.
Namespace: Sectra.Client.ContextManager
Syntax
[ServiceContract(CallbackContract = typeof(ICurrentCaseCallback))]
public interface ICurrentCase : ITransactedService
Remarks
The ICurrentCase interface inherits from interface ITransactedService.
See also
• section 3.2 Context Manager transactions
Syntax
[OperationContract(Name = "CurrentCase_CommitApprovedTransaction")]
[FaultContract(typeof(ServiceClosingException))]
[FaultContract(typeof(TransactionStateException))]
void CommitApprovedTransaction(
ContextTransactionIdentifier transactionId,
CurrentCaseContext newContext
)
Parameters
• transactionId - A ContextTransactionIdentifier, identifying the transaction that this call concerns.
• newContext - A CurrentCaseContext, specifying which case that the applications should switch
to.
Exceptions
FaultException<TransactionStateException> The given transaction identifier is not valid, or the transaction is not
in a state in which this call is applicable.
Remarks
This method should only be called as a response to the Context Manager calling
ITransactedCallback.TransactionApproved, which the Context Manager calls on the application that
has initiated a transaction when all other applications have registered approving votes.
The initiating application should, after calling CommitApprovedTransaction, start switching current
case (as stated in the current case context) and then notify the Context Manager that it has successfully
finished switching current case by calling ITransactedService.CommitCompleted. If some unexpected
error occurs while switching current case, the application should instead call
ITransactedService.ReportTransactionError.
When all applications have finished performing the commit phase of the transaction, the Context
Manager will notify all applications that the transaction has finished by calling
ITransactedCallback.TransactionCompleted.
If the CurrentCaseContext specifies that one of the other applications should open a specific view and
bring the window to the front on the desktop (see section 6.6.5.5 CurrentCaseContext.ViewIdentifier
property), then it is vitally important that your application calls the Win32 API method
AllowSetForegroundWindow(-1) before calling CommitApprovedTransaction. If your application
fail to do so, Windows will not allow the target application to move its window to the front and to take
input focus.
Syntax
[OperationContract(Name = "CurrentCase_Connect")]
[FaultContract(typeof(ServiceClosingException))]
void Connect(
string applicationName,
string applicationId
)
Parameters
• applicationName - The full (user-friendly) name of the registering application. This name will be
displayed to the user in various dialogs, so it should be the name that user recognizes the application
by.
applicationId - An identifier of the application for configuration and debug/trace purposes. This
identifier should not be localized into the selected GUI language of the user.
Exceptions
See also
• section 6.3.1.3 ICurrentCase.Disconnect method
Syntax
[OperationContract(Name = "CurrentCase_Disconnect")]
[FaultContract(typeof(ServiceClosingException))]
void Disconnect()
Exceptions
See also
• section 6.3.1.2 ICurrentCase.Connect method
Syntax
[OperationContract(Name = "CurrentCase_GetContext")]
[FaultContract(typeof(ServiceClosingException))]
[FaultContract(typeof(TransactionStateException))]
CurrentCaseContext GetContext()
Return value
Returns a CurrentCaseContext, describing which case the applications connected to the Context Manager
should display. Returns null if no transaction has been performed since the Context Manager was started
or if the last transaction failed.
Exceptions
Syntax
[OperationContract(Name = "CurrentCase_StartCurrentCaseTransactionNoContext")]
[FaultContract(typeof(ServiceClosingException))]
[FaultContract(typeof(TransactionStateException))]
ContextTransactionIdentifier StartCurrentCaseTransaction()
[OperationContract(Name = "CurrentCase_StartCurrentCaseTransactionWithContext")]
[FaultContract(typeof(ServiceClosingException))]
[FaultContract(typeof(TransactionStateException))]
ContextTransactionIdentifier StartCurrentCaseTransaction(
CurrentCaseContext newContext
)
Parameters
• newContext - A CurrentCaseContext, specifying which case that the applications should switch
to.
Return value
Returns a ContextTransactionIdentifier, identifying the newly created transaction.
Exceptions
Remarks
There are two variants of this method. The first takes no parameters and the second takes a
CurrentCaseContext, describing the case your application is about to switch to. You should preferably
use the second variant since the given CurrentCaseContext will be passed to the other applications in
the voting phase of the transaction, giving them more information to base the voting decision on.
The variant taking no parameters should only be used in situations where your application is about to
change current case, but it will not know what the new current case will be until after it has started
switching case.
Note that your application should not change current case after calling StartCurrentCaseTransaction.
It should wait for all the other applications to approve the transaction before doing anything. The
application will be notified that the transaction has been approved by the Context Manager calling
ITransactedCallback.TransactionApproved.
Syntax
[OperationContract(Name = "CurrentCase_GetConnectedApplicationIds")]
[FaultContract(typeof(ServiceClosingException))]
string[] GetConnectedApplicationIds();
Return value
Returns a list of application identifiers.
Exceptions
Namespace: Sectra.Client.ContextManager
Syntax
public interface ICurrentCaseCallback : ITransactedCallback
Remarks
The ICurrentCaseCallback interface inherits from interface ITransactedCallback.
See also
• section 3.2 Context Manager transactions
Syntax
[OperationContract(Name = "CurrentCaseCB_CommitCurrentCase")]
void CommitCurrentCase(
ContextTransactionIdentifier transactionId,
CurrentCaseContext newContext
)
Parameters
• transactionId - A ContextTransactionIdentifier identifying the transaction that this call concerns.
• newContext - A CurrentCaseContext specifying the case that the application should switch to.
Remarks
As a response to this callback your application is expected to switch current case according to the given
CurrentCaseContext. Your application is then expected to call ITransactedService.CommitCompleted
when it has successfully switched current case.
Note that it should not be regarded as an error if the specified case is not known to your application.
Your application should in that situation select no current case and show no patient-related information.
Syntax
[OperationContract(Name = "CurrentCaseCB_VoteForCurrentCaseNoContext")]
void VoteForCurrentCase(
ContextTransactionIdentifier transactionId
)
[OperationContract(Name = "CurrentCaseCB_VoteForCurrentCaseWithContext")]
void VoteForCurrentCase(
ContextTransactionIdentifier transactionId,
CurrentCaseContext newContext
)
Parameters
• transactionId - A ContextTransactionIdentifier identifying the transaction that this call concerns.
• newContext - A CurrentCaseContext specifying the case that the transaction suggests to switch
to.
Remarks
There are two variants of this method. Which of them that the Context Manager calls depends on
whether the application that initiated the transaction specified a CurrentCaseContext or not when the
transaction was initiated.
As a response to this callback your application is expected to register a vote whether it agrees to perform
the suggested action or not. A vote is registered by calling ITransactedService.RegisterApprovingVote
or ITransactedService.RegisterDenyingVote.
A rationale for denying the transaction could be that your application is locked in editing mode or that
it has an active modal dialog waiting for user input.
If your application does not recognize the suggested case, then it should still vote to approve the
transaction. It should then, in the commit phase, switch to no current case and clear the GUI from
patient data.
Note that your application should not request any user input while deciding how to vote for a transaction.
It should for instance not ask the user if unsaved changes should be saved. Instead it should just register
a denying vote with rationale "There are unsaved changes. Save or discard the changes and try to change
current case again.".
See also
• section 6.3.1.5 ICurrentCase.StartCurrentCaseTransaction method
See also
• chapter 3 About the desktop synchronization interface
An application that connects to the Commands endpoint is required to implement callback interface
ICommandsCallback.
Namespace: Sectra.Client.ContextManager
Syntax
[ServiceContract(CallbackContract = typeof(ICommandsCallback))]
public interface ICommands : ICommonService
Remarks
The ICommands interface inherits from interface ICommonService.
See also
• section 5.2 Commands endpoint guides
Syntax
[OperationContract(Name = "Commands_Connect")]
[FaultContract(typeof(ServiceClosingException))]
void Connect(
string applicationName,
string applicationId
)
Parameters
• applicationName - The full (user-friendly) name of the registering application. This name will be
displayed to the user in various dialogs, so it should be the name that user recognizes the application
by.
applicationId - An identifier of the application for configuration and debug/trace purposes. This
identifier should not be localized into the selected GUI language of the user.
Exceptions
See also
• section 6.4.1.2 ICommands.Disconnect method
Syntax
[OperationContract(Name = "Commands_Disconnect")]
[FaultContract(typeof(ServiceClosingException))]
void Disconnect()
Exceptions
See also
• section 6.4.1.1 ICommands.Connect method
Syntax
[OperationContract(Name = "Commands_ShowView")]
[FaultContract(typeof(ServiceClosingException))]
void ShowView(
string applicationId,
string viewId
)
Parameters
• applicationId - The registered application id (see parameter applicationId in method
ICommands.Connect) of the application that should receive the ICommandsCallback.ShowView
callback. If applicationId is empty or null, then all other applications will receive the callback.
• viewId - Identifier for the view that the target application(s) should bring to front. This value is
forwarded to the target application(s) as parameter viewId in the ICommandsCallback.ShowView
callback.
Exceptions
Remarks
The show view command requests the target application(s) to bring the specified window or view to the
front on the desktop. IDS7 recognizes the following identifiers:
IDS7CloseImageAndMatrixWindows Closes the matrix and image windows if they are open.
For the target application to be able to bring the specified window to the front it is vitally important
that your application calls the Win32 API method AllowSetForegroundWindow(-1) before calling
ShowView. If you fail to do so, Windows will not allow the target application to move its window to
the front and to take input focus.
See also
• section 6.4.2.1 ICommandsCallback.ShowView method
Namespace: Sectra.Client.ContextManager
Syntax
public interface ICommandsCallback : ICommonCallback
Remarks
The ICommandsCallback interface inherits from interface ICommonCallback.
See also
• section 3.3 Callback interface considerations
Syntax
[OperationContract(Name = "CommandsCB_ShowView")]
void ShowView(
string viewId
)
Parameters
• viewId - Identifier of the view that should be opened and/or brought to the front on the desktop.
Remarks
If the given view identifier is recognized by your application, then it should open and bring the specified
view to the front on the desktop. If the identifier is not recognized, then your application should do
nothing in response to the ShowView callback.
<Empty string> The user selects the Current RIS Window command in IDS7. The target application
is expected to bring its current window to the front.
See also
• chapter 3 About the desktop synchronization interface
An application that connects to the Login endpoint is required to implement callback interface
ILoginCallback.
Namespace: Sectra.Client.ContextManager
Syntax
[ServiceContract(CallbackContract = typeof(ILoginCallback))]
public interface ILogin : ITransactedService
Remarks
The ILogin interface inherits from interface ITransactedService.
See also
• section 3.2 Context Manager transactions
Syntax
[OperationContract(Name = "Login_CommitApprovedTransaction")]
[FaultContract(typeof(ServiceClosingException))]
[FaultContract(typeof(TransactionStateException))]
LoginSession CommitApprovedTransaction(
ContextTransactionIdentifier transactionId
)
Parameters
• transactionId - A ContextTransactionIdentifier, identifying the transaction that this call concerns.
Return value
Returns the LoginSession that should be applied in the commit phase of the transaction. The UserId
property of the returned object will be null if the current transaction is logging off the current user.
Exceptions
FaultException<TransactionStateException> The given transaction identifier is not valid, or the transaction is not
in a state in which this call is applicable.
Remarks
This method should only be called as a response to the Context Manager calling
ITransactedCallback.TransactionApproved, which the Context Manager calls on the application that
has initiated a transaction when all other applications have registered approving votes.
The initiating application should, after calling CommitApprovedTransaction, start logging the user
on or off and then notify the Context Manager that it has successfully finished the operation by calling
ITransactedService.CommitCompleted. If some unexpected error occurs while logging on or off, the
application should instead call ITransactedService.ReportTransactionError.
When all applications have finished performing the commit phase of the transaction, the Context
Manager will notify all applications that the transaction has finished by calling
ITransactedCallback.TransactionCompleted.
Syntax
[OperationContract(Name = "Login_Connect")]
[FaultContract(typeof(ServiceClosingException))]
void Connect(
string applicationName,
string applicationId
)
Parameters
• applicationName - The full (user-friendly) name of the registering application. This name will be
displayed to the user in various dialogs, so it should be the name that user recognizes the application
by.
applicationId - An identifier of the application for configuration and debug/trace purposes. This
identifier should not be localized into the selected GUI language of the user.
Exceptions
See also
• section 6.5.1.3 ILogin.Disconnect method
Syntax
[OperationContract(Name = "Login_Disconnect")]
[FaultContract(typeof(ServiceClosingException))]
void Disconnect()
Exceptions
See also
• section 6.5.1.2 ILogin.Connect method
Syntax
[OperationContract(Name = "Login_GetCurrentSession")]
[FaultContract(typeof(ServiceClosingException))]
[FaultContract(typeof(TransactionStateException))]
[FaultContract(typeof(ReentrancyException))]
LoginSession GetCurrentSession()
Return value
Returns the LoginSession that was created by the last login transaction. Returns null if there is no
current login session.
Exceptions
FaultException<ReentrancyException> The calling application is the initiator of the current login session,
there should be no need for this application to call
GetCurrentSession.
Remarks
Normally the UserId property of the returned LoginSession should hold a valid UserIdentifier. The
UserId property may under exceptional circumstances however be null. It could for instance be that the
application that started the session has disconnected from the Context Manager without performing a
logout transaction (and thereby terminating the transaction).
Your application should react on this situation in the same way as if there was no current login session.
Syntax
[OperationContract(Name = "Login_LastRegisteredActivity")]
[FaultContract(typeof(ServiceClosingException))]
DateTime LastRegisteredActivity()
Exceptions
Remarks
This method should be used if your application implements functionality to automatically log the user
off when the user have not been active for a certain time.
When an "user inactivity timeout" occurs in your application, it should before initiating a logout, call
LastRegisteredActivity to check if the user is active in any of the other applications. If the returned time
stamp is recent enough, your application should not perform the logout.
Syntax
[OperationContract(Name = "Login_RegisterUserActivity")]
[FaultContract(typeof(ServiceClosingException))]
void RegisterUserActivity()
Exceptions
Remarks
If your application participate in a Context Manager login session, it should call RegisterUserActivity
when it receives user input. This is to prevent other applications from logging out due to user inactivity
while the user is active in your application.
A delay should be implemented in the application so that RegisterUserActivity don't get called more
often than, say, every 20 seconds.
See also
• section 6.5.1.5 ILogin.LastRegisteredActivity method
Syntax
[OperationContract(Name = "Login_StartLoginTransaction")]
[FaultContract(typeof(ArgumentNullException))]
[FaultContract(typeof(ServiceClosingException))]
[FaultContract(typeof(TransactionStateException))]
ContextTransactionIdentifier StartLoginTransaction(
UserIdentifier user
)
Parameters
• user - A UserIdentifier, identifying the user that has been authenticated by the application that calls
StartLoginTransaction.
Return value
Returns a ContextTransactionIdentifier, identifying the newly created transaction.
Exceptions
Remarks
Your application should authenticate the user (using user name and password or other means) before
creating an UserIdentifier instance and calling StartLoginTransaction. To create a UserIdentifier
without having authenticated the user would be a breach of the understanding established between the
applications connected to the Context Manager Login endpoint.
Note that your application should not log on the user after calling StartLoginTransaction. It should
wait for all the other applications to approve the transaction before doing anything. The application
will be notified that the transaction has been approved by the Context Manager calling
ITransactedCallback.TransactionApproved.
See also
• section 5.4.3 Validating an UserIdentifier instance
Syntax
[OperationContract(Name = "Login_StartLogoutTransaction")]
[FaultContract(typeof(ArgumentException))]
[FaultContract(typeof(ServiceClosingException))]
[FaultContract(typeof(TransactionStateException))]
ContextTransactionIdentifier StartLogoutTransaction(
LoginSessionIdentifier sessionId
)
Parameters
• sessionId - A LoginSessionIdentifier, identifying the login session to be terminated.
Return value
Returns a ContextTransactionIdentifier, identifying the newly created transaction.
Exceptions
Remarks
Note that your application should not log off the user after calling StartLogoutTransaction. It should
wait for all the other applications to approve the transaction before doing anything. The application
will be notified that the transaction has been approved by the Context Manager calling
ITransactedCallback.TransactionApproved.
See also
• section 6.5.1.7 ILogin.StartLoginTransaction method
Namespace: Sectra.Client.ContextManager
Syntax
public interface ILoginCallback : ITransactedCallback
Remarks
The ILoginCallback interface inherits from interface ITransactedCallback.
See also
• section 3.2 Context Manager transactions
Syntax
[OperationContract(Name = "LoginCB_CommitLogin")]
void CommitLogin(
ContextTransactionIdentifier transactionId,
LoginSession session
)
Parameters
• transactionId - A ContextTransactionIdentifier identifying the transaction that this call concerns.
Remarks
As a response to this callback your application is expected to log on the user specified by the given
LoginSession. Your application is then expected to call ITransactedService.CommitCompleted when
it has successfully logged on.
If CommitLogin is called unexpectedly or if your application encounters an error while logging on, it
should call ITransactedService.ReportTransactionError instead of
ITransactedService.CommitCompleted.
Syntax
[OperationContract(Name = "LoginCB_CommitLogout")]
void CommitLogout(
ContextTransactionIdentifier transactionId,
LoginSessionIdentifier sessionId
)
Parameters
• transactionId - A ContextTransactionIdentifier identifying the transaction that this call concerns.
Remarks
As a response to this callback your application is expected to log off. Your application is then expected
to call ITransactedService.CommitCompleted when it has successfully logged off.
If CommitLogout is called unexpectedly or if your application encounters an error while logging off,
it should call ITransactedService.ReportTransactionError instead of
ITransactedService.CommitCompleted.
Syntax
[OperationContract(Name = "LoginCB_GetCurrentUser")]
[FaultContract(typeof(TransactionStateException))]
UserIdentifier GetCurrentUser(
LoginSessionIdentifier sessionId
)
Parameters
• sessionId - A LoginSessionIdentifier, identifying the login session that this query concerns.
Exceptions
Remarks
The Context Manger may call GetCurrentUser on the application that initiated the current login
session in order to get a fresh UserIdentifier with an updated time stamp.
As an response to this callback your application should create an UserIdentifier instance for the user
currently logged on in the application.
See also
• section 5.4.3 Validating an UserIdentifier instance
Syntax
[OperationContract(Name = "LoginCB_VoteForLogin")]
void VoteForLogin(
ContextTransactionIdentifier transactionId,
UserIdentifier userId
)
Parameters
• transactionId - A ContextTransactionIdentifier identifying the transaction that this call concerns.
• userId - A UserIdentifier, identifying the user that has been authenticated by the application that
initiated the transaction.
Remarks
As a response to this callback your application is expected validate the given UserIdentifier (see
section 5.4.3 Validating an UserIdentifier instance) and to decide whether it accepts to log the suggested
user on or not. The application should register its vote in the Context Manager by calling
ITransactedService.RegisterApprovingVote or ITransactedService.RegisterDenyingVote.
Note that your application should not request any user input while deciding how to vote for a transaction.
Your application should not start to log the suggested user on as a response to the VoteForLogin
callback. It should not do anything until all other applications have agreed to log the user on. The
Context Manager will notify your application about this by calling ILoginCallback.CommitLogin.
See also
• section 5.4.3 Validating an UserIdentifier instance
Syntax
[OperationContract(Name = "LoginCB_VoteForLogout")]
void VoteForLogout(
ContextTransactionIdentifier transactionId,
LoginSessionIdentifier sessionId
)
Parameters
• transactionId - A ContextTransactionIdentifier identifying the transaction that this call concerns.
Remarks
As a response to this callback your application is expected to check if it is in a state where it can log off
or not. The application should register its vote in the Context Manager by calling
ITransactedService.RegisterApprovingVote or ITransactedService.RegisterDenyingVote.
Note that your application should not request any user input while deciding how to vote for a transaction.
It should for instance not ask the user if unsaved changes should be saved.
Your application should not start to log off as a response to the VoteForLogout callback. It should not
do anything until all other applications have agreed to log off. The Context Manager will notify your
application about this by calling ILoginCallback.CommitLogout.
See also
• section 6.5.2.4 ILoginCallback.VoteForLogin method
Syntax
[DataContract]
public class CaseIdentifier
Remarks
When your application receives a CaseIdentifier from the Context Manager, it should in addition to
checking the accession and examination numbers also verify that the accession number group identifier
is valid. See property CaseIdentifier.AccessionNumberGroupId for further info.
Syntax
public string AccessionNumber { get; }
Syntax
public string AccessionNumberGroupId { get; }
Remarks
Sectra Healthcare Server (and thereby IDS7) may be connected to several WISE servers, each connected
to a separate RIS system. Each RIS may generate accession numbers from its own running number
sequence. This makes it possible that the same accession number is used by more than one RIS system,
identifying a different examination in each RIS system.
The consequence is that it is not enough to just use the accession and examination numbers to identify
an examination. The identity of the RIS system that has created the accession number must also be
specified. This is the role of the Accession number integration ID defined in the Accession Number
Group. See System Administrator's Guide Sectra Healthcare System [2] for further information.
Syntax
public CaseIdentifier(
string accessionNumberGroupId,
string accessionNumber,
string examinationNumber
)
Parameters
• accessionNumberGroupId - The accession number group identifier. See property
CaseIdentifier.AccessionNumberGroupId for further information.
Syntax
public string ExaminationNumber { get; }
Syntax
public override string ToString()
Namespace: Sectra.Client.ContextManager
Syntax
[DataContract]
public class ContextTransactionIdentifier
Remarks
If you are using the class definition provided in the IDS7 Desktop Synchronization SDK, then you
should regard an instance of this class as an oblique and immutable object. The comparison operators
of the class have been overridden to provide comparison by value.
If you have generated your own class definition, using the metadata exchange endpoint of the Context
Manager, then you must access the contained Guid data member to perform comparison of two identifiers.
Syntax
public override bool Equals(
object obj
)
Parameters
• obj - The object to compare with this instance.
Return value
Returns true if obj is a ContextTransactionIdentifier that has the same value as this instance.
Syntax
public override int GetHashCode()
Syntax
public static ContextTransactionIdentifier NewIdentifier { get; }
Syntax
public static bool operator ==(
ContextTransactionIdentifier lhs,
ContextTransactionIdentifier rhs
)
Parameters
• lhs - A ContextTransactionIdentifier object.
Return value
Returns true if the value of lhs equals the value of rhs.
Syntax
public static bool operator !=(
ContextTransactionIdentifier lhs,
ContextTransactionIdentifier rhs
)
Parameters
• lhs - A ContextTransactionIdentifier object.
Return value
Returns true if the value of lhs differs from the value of rhs.
Syntax
public override string ToString()
Namespace: Sectra.Client.ContextManager
Syntax
[DataContract]
public class ContextTransactionResult
See also
• section 6.2.3.2 ITransactedCallback.TransactionCompleted method
Syntax
public ContextTransactionResult(
ContextTransactionStatus status,
string failingApplication,
string failingRationale
)
Parameters
• status - A ContextTransactionStatus indicating the finishing status of the transaction.
• failingApplication - The user-friendly name of the application that made the transaction fail. May
be null if the transaction was committed successfully.
• failingRationale - A rationale given by the application that made the transaction fail. May be null
if the transaction was committed successfully.
Syntax
public string FailingApplication { get; }
Remarks
Only valid if the ContextTransactionResult.Status property is CanceledByVoting or TransactionError.
Syntax
public string FailingRationale { get; }
Remarks
Only valid if the ContextTransactionResult.Status property is CanceledByVoting or TransactionError.
Syntax
public ContextTransactionStatus Status { get; }
Property Value
The returned ContextTransactionStatus indicates the finishing status of the transaction.
Namespace: Sectra.Client.ContextManager
Syntax
public enum ContextTransactionStatus
Members
CanceledByVoting At least one of the applications has voted against the transaction. No application has
started to perform the commit actions of the transaction.
CanceledByInitiator All applications have voted to accept the transaction, but the application that initiated
the transaction has decided to cancel the transaction before the commit phase of
the transaction was started. No application has started to perform the commit actions
of the transaction.
CommitSuccessful All applications have successfully performed the commit actions of the transaction.
TransactionError At least one application has encountered an error while processing the transactions.
The applications might now be out of sync with each other.
contains an identifier for the current case as well as an optional identifier for the application view that
should be opened.
Namespace: Sectra.Client.ContextManager
Syntax
[DataContract]
public class CurrentCaseContext
See also
• section 6.3 CurrentCase endpoint interfaces
Syntax
The four variants of this constructor applies to the four different scenarios that are valid for current case
synchronization.
Constructor to be used when the current patient and examination should be cleared, i.e. no patient or
examination should be selected in the synchronized applications:
public CurrentCaseContext()
Parameters
• viewIdentifier - Identifier of the view that the sending application wants the other applications to
open and bring to the front. See CurrentCaseContext.ViewIdentifier for further information.
• indexOfCurrentCase - Index of the item in relatedCases that is the current case. See
CurrentCaseContext.IndexOfCurrentCase for further information.
• relatedCases - A list of CaseIdentifier items, specifying the current case and optionally a number
of cases that are related to the current case. See CurrentCaseContext.RelatedCases for further
information.
• forceRefresh - Forces a refresh of the Sync Results worklist regardless of the refresh settings in the
advanced configuration of IDS7 (see System Administrator's Guide Sectra Healthcare System [2]).
Syntax
public PatientIdentifier CurrentPatient { get; }
Property value
The returned value is a PatientIdentifier object. The value is null if synchronization is performed on
examination basis only (CurrentCaseContext.RelatedCases is set), or if no patient should be selected
(CurrentCaseContext.RelatedCases is not set).
Syntax
public int IndexOfCurrentCase { get; }
Property value
The returned value is a zero-based index, referencing an item in the list returned by
CurrentCaseContext.RelatedCases. Is -1 if the list is empty or if no item in the list should be used as
the current case.
Syntax
public List<CaseIdentifier> RelatedCases { get; }
Property value
The returned list contains the identifier for the current case and, optionally, additional identifiers for
cases that are related to the current case. The value of property CurrentCaseContext.IndexOfCurrentCase
gives the index of the identifier that specifies the current case. The list is empty if the application that
created this instance of CurrentCaseContext did not have a currently active case or if synchronization
is performed on current patient only.
Remarks
The rationale for an application to specify additional cases, related to the current case, is to let the other
applications know which other cases currently are of interest in the context of the sending application.
Receiving applications could for instance use this information to provide means for the user to easily
navigate to the related cases. The additional related cases may belong to other patients than the current
case.
When IDS7 receives a CurrentCaseContext that contains multiple identifiers, it creates temporary
worklist so that commands Previous Case and Next Case will navigate between the specified cases.
Syntax
public string ViewIdentifier { get; }
Remarks
If your application receives a CurrentCaseContext with a ViewIdentifier that it recognizes, it should
then open the specified view and bring the window to the front on the desktop. If the ViewIdentifier
is not recognized or empty, your application should keep showing the same view as before and not alter
the desktop state of the window. (It should of course still change current case as specified.)
IDS7 sends the following ViewIdentifier values, in order to bring the RIS to the front.
RISRequestView The user selects the RIS Request Window command in IDS7.
RISExamView The user selects the RIS Examination Window command in IDS7.
RISReportView The user selects the RIS Report Window command in IDS7.
IDS7 recognizes the following ViewIdentifier values when receiving a CurrentCaseContext from
another application.
IDS7CloseImageAndMatrixWindows Closes the matrix and image windows if they are open.
Syntax
public bool ForceRefresh { get; }
Syntax
public override string ToString()
Namespace: Sectra.Client.ContextManager
Syntax
[DataContract]
public class LoginSession
See also
• section 6.5 Login endpoint interfaces
Syntax
public LoginSession(
LoginSessionIdentifier sessionId,
UserIdentifier userId
)
Parameters
• sessionId - A LoginSessionIdentifier, uniquely identifying this login session.
• userId - A UserIdentifier, containing the identity of the user that this logged on in this session.
Syntax
public LoginSessionIdentifier SessionId { get; }
Property value
A LoginSessionIdentifier, uniquely identifying this login session.
Syntax
public override string ToString()
Syntax
public UserIdentifier UserId { get; }
Property value
A UserIdentifier, containing the identity of the user that is logged on in this session.
Namespace: Sectra.Client.ContextManager
Syntax
[DataContract]
public class LoginSessionIdentifier
Remarks
If you are using the class definition provided in the IDS7 Desktop Synchronization SDK, then you
should regard an instance of this class as an oblique and immutable object. The comparison operators
of the class have been overridden to provide comparison by value.
If you have generated your own class definition, using the metadata exchange endpoint of the Context
Manager, then you must access the contained Guid data member to perform comparison of two identifiers.
Syntax
public override bool Equals(
object obj
)
Parameters
• obj - The object to compare with this instance.
Return value
Returns true if obj is a LoginSessionIdentifier that has the same value as this instance.
Syntax
public override int GetHashCode()
Syntax
public static LoginSessionIdentifier NewIdentifier { get; }
Syntax
public static bool operator ==(
ContextTransactionIdentifier lhs,
ContextTransactionIdentifier rhs
)
Parameters
• lhs - A LoginSessionIdentifier object.
Return value
Returns true if the value of lhs equals the value of rhs.
Syntax
public static bool operator !=(
ContextTransactionIdentifier lhs,
ContextTransactionIdentifier rhs
)
Parameters
• lhs - A LoginSessionIdentifier object.
Return value
Returns true if the value of lhs differs from the value of rhs.
Syntax
public override string ToString()
Syntax
[DataContract]
public class PatientIdentifier
Remarks
When your application receives a PatientIdentifier from the Context Manager, it should in addition
to checking the patient ID also verify that the patient ID issuer is valid. See property
PatientIdentifier.PatientIdIssuer for further info.
Syntax
public PatientIdentifier(
string patientId,
string patientIdIssuer
)
Parameters
• patientId - The patient ID.
• patientIdIssuer - The issuer of the patient ID. See property PatientIdentifier.PatientIdIssuer for
further information.
Syntax
public string PatientId { get; }
Syntax
public string PatientIdIssuer { get; }
Remarks
The patient ID (or Medical Record Number) is not by itself necessarily unique. To make sure that all
applications show the correct patient, the patient ID is combined with the MRN integration ID
In Sectra Healthcare System, the concept Medical Record Number Group is used to define groups of
unique patient identifiers. When IDS7 creates a PatientIdentifier, it will use the MRN integration
ID defined in the Medical Record Number Group of which the patient ID belongs. See System
Administrator's Guide Sectra Healthcare System [2] for further information.
Syntax
public override string ToString()
Namespace: Sectra.Client.ContextManager
Syntax
[DataContract]
public class UserIdentifier
See also
• section 6.5 Login endpoint interfaces
Syntax
public AssignmentInfo Assignment { get; }
Property value
The value of this property is an AssignmentInfo instance, which describes the purpose of the current
session. This information is typically used to determine what patient data the user should be allowed to
access during the session.
See also
• section 6.6.10 AssignmentInfo class
Syntax
public string FullName { get; }
Property value
The value of this property is a string, containing the full name of the user. The formatting of the user
name is not standardized and may differ between sites.
See also
• section 5.4.3 Validating an UserIdentifier instance
Syntax
public byte[] HashCode { get; }
Property value
The value of this property is an array of bytes, containing the hash code for verification of the authenticity
of this instance.
See also
• section 5.4.3 Validating an UserIdentifier instance
Syntax
public List<CustomAuthenticationData> CustomAuthenticationData { get; }
Property value
The value of this property is a list of CustomAuthenticationData, containing the hash code for verification
of the authenticity of this instance.
See also
• section 5.4.3 Validating an UserIdentifier instance
Syntax
public string TimeStamp { get; }
Property value
The value of this property is the time stamp (UTC time) for the creation on this instance, formatted as
an ISO 8601 compliant string.
See also
• section 5.4.3 Validating an UserIdentifier instance
Syntax
public override string ToString()
Syntax
public string UserId { get; }
Property value
The value of this property is a string, containing the login name of the user.
See also
• section 5.4.3 Validating an UserIdentifier instance
Syntax
public UserIdentifier(
string timeStamp,
string userId,
string fullName,
byte[] hashCode,
List<CustomAuthenticationData> customAuthenticationData,
AssignmentInfo assignment
)
Parameters
• timeStamp - An ISO 8601 compliant string representing the UTC time for the creation of this
instance.
• userId - A string, containing the login name of the authenticated user. For AD users the login name
is followed by the AD domain, e.g. <user_login>@<domain_id>.
• hashCode - An array of bytes, containing a hash code for the receiver of a UserIdentifier to verify
the authenticity of the given instance.
• assignment - A description of the purpose of the current session. This parameter is optional and
may be null.
See also
• section 6.6.10 AssignmentInfo class
Namespace: Sectra.Client.ContextManager
Syntax
[DataContract]
public class AssignmentInfo
See also
• section 6.5 Login endpoint interfaces
Syntax
public AssignmentInfo(
string careUnitIdIssuer,
string careUnitId,
string assignmentId,
byte[] hashCode
)
Parameters
• careUnitIdIssuer - The issuer of the care unit and assignment identifiers that the user is assigned
to during the session.
• careUnitId - An identifier for the care unit that the user is assigned to during the session.
• assignmentId - An identifier that describes the purpose (assignment type) of the current session.
• hashCode - An array of bytes, containing a hash code for the receiver of an AssignmentInfo instance
to verify its authenticity.
See also
• section 5.4.4 Validating an AssignmentInfo instance
Syntax
public string AssignmentId { get; }
Property value
The value of this property is a string, containing an identifier for the type of assignment. The formatting
and exact meaning of the identifier may differ between sites.
Syntax
public string CareUnitIdIssuer { get; }
Property value
The value of this property is a string, containing an identifier for the care unit that the user is assigned
to during the session. The formatting and exact meaning of the identifier may differ between sites.
Syntax
public string CareUnitId { get; }
Property value
The value of this property is a string, containing an identifier for the care unit that the user is assigned
to during the session. The formatting and exact meaning of the identifier may differ between sites.
Syntax
public byte[] HashCode { get; }
Property value
The value of this property is an array of bytes, containing the hash code for verification of the authenticity
of this instance.
See also
• section 5.4.4 Validating an AssignmentInfo instance
Syntax
public override string ToString()
Namespace: Sectra.Client.ContextManager
Syntax
[DataContract]
public class CustomAuthenticationData
See also
• section 6.6.9 UserIdentifier class
Syntax
public string AddinId { get; }
Property value
The value of this property is a string, containing the identifiier of the addin used to create the security
token.
Syntax
public Version AddinVersion { get; }
Property value
The value of this property is a Version, containing the version of the addin used to create the security
token.
Syntax
public string SecurityToken { get; }
Property value
The value of this property is a string, containing the security token for verification of the authenticity
of this instance.
Syntax
public CustomAuthenticationData(
string addinId,
Version addinVersion,
string securityToken
)
Parameters
• addinId - A string, containing the identifier of the addin used to generate the security token.
• adddinVersion - A string, containing the version of the addin used to generate the security token.
• securityToken - A string, containing a security token for the receiver of a UserIdentifier to verify
the authenticity of the given instance.
See also
• section 5.4.3 Validating an UserIdentifier instance
■ CurrentCaseProxy class
■ LoginProxy class
■ UserIdentifierFactory class
This chapter contains the reference documentation of the utility classes provided in the IDS7 Desktop
Synchronization SDK.
Namespace: Sectra.Client.ContextManager
Syntax
public class CommandsProxy : DuplexClientBase<ICommands>, ICommands
Remarks
Class CommandsProxy follows the traditional implementation pattern for a proxy to a bidirectional
WCF service endpoint. That is, it inherits from DuplexClientBase<T> and implements the service
contract interface (i.e. ICommands). The ICommands implementation forwards all calls to the Context
Manager service.
• CommandsProxy contains code setting up the endpoint binding programmatically, i.e. no config
file is needed to set up the WCF connection.
• Callbacks from the Context Manager service are marshalled asynchronously to the "main thread" of
the client application.
See also
• section 6.4 Commands endpoint interfaces
Syntax
public static CommandsProxy CreateMarshallingProxy(
string baseAddress,
ICommandsCallback callbackInterface
)
Parameters
• baseAddress - The base address of the Context Manager WCF service. The default address is
"net.pipe://localhost/SectraContextManager".
Exceptions
Remarks
This method sets up the binding to the Context Manager WCF service programmatically. No need for
any configuration in the config file of the application.
Callbacks are marshalled asynchronously to the current thread before the given ICommandsCallback
implementation is called. This does however require that a SynchronizationContext has been set up
for the current thread. See the MSDN documentation for further information.
Syntax
public static CommandsProxy CreateNonMarshallingProxy(
string baseAddress,
ICommandsCallback callbackInterface
)
Parameters
• baseAddress - The base address of the Context Manager WCF service. The default address is
"net.pipe://localhost/SectraContextManager".
Exceptions
Remarks
This method sets up the binding to the Context Manager WCF service programmatically. No need for
any configuration in the config file of the application.
Callbacks are performed on threads from the WCF thread pool. The given implementation of
ICommandsCallback must implement proper thread synchronization.
Namespace: Sectra.Client.ContextManager
Syntax
public class CurrentCaseProxy : DuplexClientBase<ICurrentCase>, ICurrentCase
Remarks
Class CurrentCaseProxy follows the traditional implementation pattern for a proxy to a bidirectional
WCF service endpoint. That is, it inherits from DuplexClientBase<T> and implements the service
contract interface (i.e. ICurrentCase). The ICurrentCase implementation forwards all calls to the Context
Manager service.
• CurrentCaseProxy contains code setting up the endpoint binding programmatically, i.e. no config
file is needed to set up the WCF connection.
• Callbacks from the Context Manager service are marshalled asynchronously to the "main thread" of
the client application.
See also
• section 6.3 CurrentCase endpoint interfaces
Syntax
public static CurrentCaseProxy CreateMarshallingProxy(
string baseAddress,
ICurrentCaseCallback callbackInterface
)
Parameters
• baseAddress - The base address of the Context Manager WCF service. The default address is
"net.pipe://localhost/SectraContextManager".
Exceptions
Remarks
This method sets up the binding to the Context Manager WCF service programmatically. No need for
any configuration in the config file of the application.
Callbacks are marshalled asynchronously to the current thread before the given ICurrentCaseCallback
implementation is called. This does however require that a SynchronizationContext has been set up
for the current thread. See the MSDN documentation for further information.
Syntax
public static CurrentCaseProxy CreateNonMarshallingProxy(
string baseAddress,
ICurrentCaseCallback callbackInterface
)
Parameters
• baseAddress - The base address of the Context Manager WCF service. The default address is
"net.pipe://localhost/SectraContextManager".
Exceptions
Remarks
This method sets up the binding to the Context Manager WCF service programmatically. No need for
any configuration in the config file of the application.
Callbacks are performed on threads from the WCF thread pool. The given implementation of
ICurrentCaseCallback must implement proper thread synchronization.
Namespace: Sectra.Client.ContextManager
Syntax
public class LoginProxy : DuplexClientBase<ILogin>, ILogin
Remarks
Class LoginProxy follows the traditional implementation pattern for a proxy to a bidirectional WCF
service endpoint. That is, it inherits from DuplexClientBase<T> and implements the service contract
interface (i.e. ILogin). The ILogin implementation forwards all calls to the Context Manager service.
• LoginProxy contains code setting up the endpoint binding programmatically, i.e. no config file is
needed to set up the WCF connection.
• Callbacks from the Context Manager service are marshalled asynchronously to the "main thread" of
the client application.
See also
• section 6.5 Login endpoint interfaces
Syntax
public static LoginProxy CreateMarshallingProxy(
string baseAddress,
ILoginCallback callbackInterface
)
Parameters
• baseAddress - The base address of the Context Manager WCF service. The default address is
"net.pipe://localhost/SectraContextManager".
Exceptions
Remarks
This method sets up the binding to the Context Manager WCF service programmatically. No need for
any configuration in the config file of the application.
Callbacks are marshalled asynchronously to the current thread before the given ILoginCallback
implementation is called. This does however require that a SynchronizationContext has been set up
for the current thread. See the MSDN documentation for further information.
Syntax
public static LoginProxy CreateNonMarshallingProxy(
string baseAddress,
ILoginCallback callbackInterface
)
Parameters
• baseAddress - The base address of the Context Manager WCF service. The default address is
"net.pipe://localhost/SectraContextManager".
Exceptions
Remarks
This method sets up the binding to the Context Manager WCF service programmatically. No need for
any configuration in the config file of the application.
Callbacks are performed on threads from the WCF thread pool. The given implementation of
ILoginCallback must implement proper thread synchronization.
Namespace: Sectra.Client.ContextManager.UserValidation
Syntax
public static class UserIdentifierFactory
See also
• section 6.6.9 UserIdentifier class
Syntax
public static UserIdentifier CreateIdentifier(
string userLogin,
string fullName,
string systemPassword,
string careUnitIdIssuer = null,
string careUnitId = null,
string assignmentId = null
)
Parameters
• userLogin - The login name of the authenticated user. For AD users the login name is followed
by the AD domain, e.g. <user_login>@<domain_id>.
• systemPassword - The system password to use when creating the hash-code of the identifier.
• careUnitIdIssuer - The issuer of the care unit and assignment identifiers that the user is assigned
to during the session. This parameter is optional and may be null.
• careUnitId - An identifier for the care unit that the user is assigned to during the session. This
parameter is optional and may be null.
• assignmentId - An identifier that describes the purpose (assignment type) of the current session.
This parameter is optional and may be null.
Remarks
This method sets the value of UserIdentifier.TimeStamp to the current time and sets the value of
UserIdentifier.HashCode using the given user data and system password.
Important: Note that the application that creates a UserIdentifier is responsible to have authenticated the user.
Sending a UserIdentifier to other applications is to state that "This user has been authenticated by me.
You can safely log on the user in your application, using this identifier as a proof of authentication."
See also
• section 5.4.3 Validating an UserIdentifier instance
Syntax
public static void ValidateIdentifier(
UserIdentifier identifier,
string systemPassword,
double maxTimeDiffInSeconds
)
Parameters
• identifier - The UserIdentifier instance to be validated.
• systemPassword - Specifies the system password to use when validating the hash code of the given
identifier. The system password is the shared secret between applications that are connected over
the desktop sync interface. The idea is that if the creator of a UserIdentifier knows the same secret
password as this application, then the creator can be trusted.
Exceptions
UserIdentifierExpiredException The time stamp of the given identifier differs more than the specified
max difference from the current time.
UserIdentifierInvalidException The given identifier contains invalid data or the hash code of the
identifier does not match the given system password.
See also
• section 5.4.3 Validating an UserIdentifier instance
Disclaimer
Sectra AB is not responsible for problems caused by changes in the operating characteristics of the computer hardware or
operating system, which are made after the delivery of the software, or for problems that occur as a result of the use of
Sectra software in conjunction with non-Sectra software other than the software explicitly covered in this documentation.
For a complete description of warranty, refer to the End User License Agreement supplied with the Sectra product.
Trademarks and Patents
Sectra, Sectra Imtec and the Sectra logotype, are registered trademarks of Sectra AB. FIMAG and Image Exchange Portal
are registered trademarks of Burnbank Systems Ltd in the UK. IDS7, Sectra BizTrack, Sectra CloudFlex, Sectra DoseTrack,
Sectra IEP, Sectra Image Central, Sectra Image Lab, Sectra LiteView, Sectra UniView, Sectra One Connect, Sectra Open
Archive, Sectra VNA, Sectra UserInfluence, Sectra Upload & Store App and WISE are trademarks of Sectra Imaging IT
Solutions AB. Sectra Preop Online and Sectra OneScreen are trademarks of Sectra AB.
Windows is a registered trademark of Microsoft Corporation in the United States and other countries. iOS, IpadOS, Mac,
Safari, iPhone, and iPad are registered trademarks of Apple Inc. in the United States and other countries. Android is a
trademark of Google LLC.
The intellectual property of Sectra includes a number of patents, for full information refer to: https://sectra.com/medic-
al/about-sectra/patents/
All rights are reserved. Reproduction or transmission in whole or part, in any form or by any means, electronic, mechanical
or otherwise, is prohibited without written consent of the copyright owner.
Copyrights and all other proprietary rights in any software and related documentation ("Software") made available to you
rest exclusively with Sectra AB. No title or ownership in the Software is conferred to you. Use of the Software is subject to
the end user license conditions as are available on request.
To the maximum extent permitted by law, you shall not decompile and/or reverse engineer the software or any part thereof.
Sectra AB
Teknikringen 20
SE-58330 Linköping
Sweden
Phone: +46 13 23 52 00
E-mail: [email protected]