IDS7_DevelopersGuide.DesktopSync

Developer's Guide
IDS7 Desktop Synchronization

Sectra PACS, Version 24.1, March 2022
About this document
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.
IDS7, Version 24.1, March 2022 About this document ii

Contents
About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
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
2 About desktop synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 About the IDS7 workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Synchronization of current case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Single log on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 About the desktop synchronization interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Introducing the Context Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Context Manager transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Callback interface considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
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
IDS7, Version 24.1, March 2022 Contents iii

Contents
7 SDK Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.1 CommandsProxy class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2 CurrentCaseProxy class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.3 LoginProxy class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.4 UserIdentifierFactory class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
IDS7, Version 24.1, March 2022 Contents iv

1 Introduction
The following topics are included in this chapter:

■ Related documents
■ How this document is organized
■ Assumptions about the reader
■ Conventions used in this document
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.
1.1 Related documents

[1] User's Guide IDS7
[2] System Administrator's Guide Sectra Healthcare System
1.2 How this document is organized

This document consists of a number of guides for how to integrate with the IDS7 Desktop
Synchronization interface, as well as reference documentation of the interface.
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.
A brief summary of the chapters in this document follows below:
chapter 2 About desktop synchronization

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.
chapter 3 About the desktop synchronization interface

This chapter describes the overall design of the IDS7 Desktop Synchronization interface and introduces
some central concepts of the design.
IDS7, Version 24.1, March 2022 Introduction 1

Assumptions about the reader 1.3
chapter 4 Getting started

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.
chapter 5 Development guides

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.
chapter 6 Interface reference

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.
chapter 7 SDK Reference

This chapter contains the reference documentation of the utility classes provided in the IDS7 Desktop
Synchronization SDK.
1.3 Assumptions about the reader

We assume that you, the reader, are an experienced developer and that you are comfortable with
object-oriented programming and design. We assume that you have fair knowledge about the Microsoft
.NET platform and that you know basic C#.
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.
1.4 Conventions used in this document

The following typographical conventions are used in this document:
Code examples are written with constant width font on grey background.
Emphasized code sections are written in bold font.
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.
IDS7, Version 24.1, March 2022 Introduction 2

2 About desktop synchronization

■ About the IDS7 workstation
■ Synchronization of current case
■ 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.
2.1 About the IDS7 workstation

IDS7 is a diagnostic workstation for radiologists, designed for secure remote reading throughout the
enterprise. The workstation is installed and started over the web, using the Microsoft ClickOnce
framework.
IDS7 is designed for usage on computers with multiple monitors and has multiple full-screen main
windows, as depicted in the figure below.
IDS7, Version 24.1, March 2022 About desktop synchronization 3

About the IDS7 workstation 2.1
IDS7 main windows
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.

Synchronization of current case 2.2
2.2 Synchronization of current case

The primary role of the desktop sync is to make IDS7 and other desktop applications, such as HIS or
RIS clients, automatically show the same examination. For applications without information about
examinations, e.g. HIS clients, synchronization can be performed on the current patient. The possibility
to synchronize on either the current examination or the current patient was introduced in version 14.1
of IDS7. In this guide, current case is used as a common term for both current examination and current
patient.
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.
IDS7 commands manually synchronizing the current case.
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.

Single log on 2.3
2.3 Single log on

Single log on is an optional part of desktop synchronization. It is not necessary to do single log on to
be able to do synchronization of the current case, and vice versa.
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.

3 About the desktop synchronization interface

■ Introducing the Context Manager
■ Context Manager transactions
■ Callback interface considerations
This chapter describes the overall design of the IDS7 Desktop Synchronization interface and introduces
the central concepts of the design.
3.1 Introducing the Context Manager

The IDS7 Desktop Synchronization interface is implemented as a WCF service, called the Context
Manager. The Context Manager WCF service is hosted by the IDS7 process (SectraWorkstation.exe),
as depicted in the figure below.
The Context Manager WCF service is hosted by IDS7.
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.
The Context Manger WCF service has three independent endpoints:
• The CurrentCase endpoint, net.pipe://localhost/SectraContextManager/CurrentCase, is

for synchronization of the current case (current examination or patient) between applications.
• The Commands endpoint, net.pipe://localhost/SectraContextManager/Commands, is for

forwarding commands between applications (for instances requesting one of the other applications
to bring its main window to the front).
• The Login endpoint, net.pipe://localhost/SectraContextManager/Login, is for single log

on, i.e. synchronizing user logging on and off.
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.
3.2 Context Manager transactions

Early as we started designing the Context Manager interface, we recognized that there are situations
when an application cannot perform the actions of an incoming desktop sync request. It could for instance
be that the user changes current case (current examination or patient) in IDS7 while there is an unsaved
report in the RIS. The RIS cannot change current case, since discarding the report would mean that
work would be lost and automatically saving the report would mean that an unfinished report gets stored
in the system.
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.
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.
3.2.1 Successful transaction example

This example illustrates the Context Manager transaction call pattern when all applications agree to
perform the suggested action and then perform the action successfully.
Call graph for a successful transaction.
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.
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.
3.2.2 Denied transaction example

This example illustrates the Context Manager transaction call pattern when one of the applications votes
against the transaction.
Call graph for a denied transaction.
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.
action or not.
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.
7. The "listening" applications act as if the transaction never occurred.
3.2.3 Cancelled transaction example

perform the suggested action, but the initiating application then decides not to go ahead and perform
the action it has suggested.
Call graph for a cancelled transaction.
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.
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.
6. The Context Manager notifies all applications that the transaction has been cancelled.
7. All applications remain in the same state as before transaction.
3.2.4 Transaction commit error example

perform the suggested action, but one of the applications encounters an error when performing the
action.
Call graph for a transaction that fails in the commit phase.
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.
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.
3.2.5 Transaction voting error example

This example illustrates the Context Manager transaction call pattern when one of the applications
encounter an error during the voting phase of the transaction.
Call graph for a transaction that fails in the voting phase.
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.
Callback interface considerations 3.3
3.3 Callback interface considerations

All Context Manager endpoints are, as previously described, bidirectional. Each connecting application
must implement the callback interface associated with the endpoint. This section describes some of the
general issues to consider when implementing the callback interfaces.
Process callbacks asynchronously

All methods in the Context Manager callback interfaces have been designed not to return any data to
the Context Manager1. This makes it possible for the implementation of the callback interface methods
to schedule asynchronous processing of the callback and then to return immediately. The Context
Manager interface then contains methods so that the client application can notify the Context Manager
when the asynchronous processing of the callback has finished.
This design pattern becomes apparent if you study the call graph examples for the Context Manager
transactions. See section 3.2 Context Manager transactions.
The benefits of processing the callbacks asynchronously are:
• It eliminates the risk of deadlocks.
• It increases the performance of the desktop sync, since more work is done in parallel.
• It reduces the risk of errors due to WCF-level timeouts.
The proxy classes provided in the SDK implement asynchronous scheduling of callbacks and should
preferably be used. See chapter 7 SDK Reference.
Don't throw exceptions in callbacks

The implementation of a callback interface method should never throw any exceptions. If the processing
of the callback fails, then it should instead be reported to the Context Manager with a
ITransactedService.ReportTransactionError call.
Don't require user interaction while processing callbacks

It is important that your application does not require any user input as it processes a callback from the
Context Manager.
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.
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.
Prevent user interaction while processing a transaction

It is a good idea for an application to block further user input while a Context Manager transaction is
in progress.
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.
Make the user aware of sync errors in a non-blocking way

Your application will receive a ITransactedCallback.TransactionCompleted(..., TransactionError)
callback if a Context Manager transaction fails. It is important that your application makes the user
aware that the desktop applications now may be out of sync. It is, for reasons stated previously, important
that this notification is made in a way that does not block the GUI. This means that pop-up error message
boxes should not be used.
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.
Non-blocking desktop sync error notification in IDS7.
4 Getting started

■ What you need to use this SDK
■ About the IDS7 Desktop Synchronization SDK
■ Setting up the Visual Studio project
■ 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).
4.1 What you need to use this SDK

The IDS7 Desktop Synchronization interface is based on the Windows Communication Foundation (WCF)
framework for inter-process communication. Although WCF is technology-neutral, we assume that you
are developing your desktop sync integration on the Microsoft .NET platform.
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.
4.2 About the IDS7 Desktop Synchronization SDK

The IDS7 Desktop Synchronization SDK includes, in addition to this document, a set of C# source
code files that provide utility functions to be incorporated in an application that integrates the IDS7
Desktop Synchronization interface (i.e., an application that connects to the Context Manager WCF
service).
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.
IDS7, Version 24.1, March 2022 Getting started 17

Setting up the Visual Studio project 4.3
See section 4.3 Setting up the Visual Studio project for instructions on how to include the SDK in your
application.
4.3 Setting up the Visual Studio project

This section describes the necessary steps to incorporate desktop synchronization in an existing Visual
Studio project. It is assumed that you are using Visual Studio 2013. Other Visual Studio versions will
work but may differ slightly in the setup procedure. It is also assumed that the .NET framework 4.0 (or
later) runtime components have been installed.
4.3.1 Adding references for WCF support

To add WCF support to your project, it is necessary for the project to reference the System.ServiceModel
and System.Runtime.Serialization assemblies in the .NET framework.
Adding the references

In the Visual Studio solution explorer, right-click on the References node in the project and select Add
Reference…. Select the Assemblies - Framework category in the Add Reference dialog tree view
and select assemblies System.ServiceModel and System.Runtime.Serialization.
4.3.2 Including the SDK in the project

If you are developing in C#, then the preferred way to incorporate the IDS7 Desktop Synchronization
SDK is to include the source code in your project. If you do not have a C# compiler, then you could
instead add a reference to Sectra.Client.ContextManager.Proxy.dll in your project.
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.
Adding the SDK source code to the project

Add a new subdirectory to the source code directory of the project. Right-click on the project and select
Add->New Folder in the Visual Studio solution explorer. Name the folder "SyncSDK".
Copy the following files from the SDK to the newly created "SyncSDK" subdirectory.
File name Description
ContextManagerContracts.cs Reworked versions of the Context Manager service and

data contracts. See chapter 6 Interface reference.
CurrentCaseProxy.cs Proxy class for connecting to the CurrentCase endpoint

of the Context Manager. See section 7.2
CurrentCaseCallbackMarshaller.cs CurrentCaseProxy class.

An example project 4.4
File name Description
CommandsProxy.cs Proxy class for connecting to the Commands endpoint

of the Context Manager. See section 7.1
CommandsCallbackMarshaller.cs CommandsProxy class.
LoginProxy.cs Proxy class for connecting to the Login endpoint of the

Context Manager. See section 7.3 LoginProxy class.
LoginCallbackMarshaller.cs
UserValidation.cs Utility classes for creation and validation of user

identifiers, communicated over the Login endpoint. See
section 7.4 UserIdentifierFactory class.
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.
Using the SDK compiled assembly

If you have not incorporated the SDK source code in the project, you should copy
Sectra.Client.ContextManager.Proxy.dll from the SDK to the source code directory of the project.
It is recommended that you add the file to your source control system.
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.
4.4 An example project

In this section, a minimal test application is created to give you a short step-by-step example of how to
get started connecting to the Context Manager.
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 application implements callback method ICommandsCallback.ShowView, so that the test

application will be brought to the front when the user selects Window->Current RIS Window in
IDS7.
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).
Create the Visual Studio project

Create a new Visual Studio project of type Visual C#->Windows, using template Windows Forms
Application. Name the project "CommandsTest".
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.
Set up the test application GUI

Open Form1.cs in the visual designer.
Set property Text on Form1 to "Desktop Sync Test Application".
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.
Add code for connecting Form1 to the Context Manager

The main form, class Form1, of the test application will connect to the Commands endpoint of the
Context Manager, so Form1 must implement callback interface ICommandsCallback.
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 {
...
#region ICommandsCallback Members
public void ShowView(string viewId) {

// TODO: We will implement this later
}
#endregion
#region ICommonCallback Members
public void Ping() {

// Not required to do anything here
}
public void LostContact(List<string> applicationNames) {

// We should notify the user (in a non-blocking way) that
// contact has been lost to one or more of the synchronized
// applications. This is however outside the scope
// of this example...
}
public void ServiceIsClosing() {

// TODO: We will implement this later
}
#endregion

}
}
Add the following utility methods to Form1.
ConnectToCommandsEndpoint(...) creates a CommandsProxy instance and opens a WCF-connection

to the Commands endpoint on the Context Manager. It then calls ICommands.Connect on the Context
Manager to register the test application for callbacks.
DisconnectFromCommandsEndpoint(...) calls ICommands.Disconnect and closes the

WCF-connection, while DropProxy(...) just closes the WCF-connection.
...
private static CommandsProxy ConnectToCommandsEndpoint(ICommandsCallback cb) {

// Create a WCF proxy object
CommandsProxy proxy = null;
try {
proxy = CommandsProxy.CreateMarshallingProxy(
"net.pipe://localhost/SectraContextManager",
cb);
}
catch {
return null;
}
// Try opening a connection to the WCF service

try {
proxy.Open();
}
catch {
DropProxy(proxy);
return null;
}
// Register this connection for callbacks

try {
proxy.Connect("Desktop Sync Test Application", "SyncTest");
}
catch {
DropProxy(proxy);
return null;
}
// All good, we are up and running.

return proxy;
}
private static void DisconnectFromCommandsEndpoint(CommandsProxy proxy) {

// Unregister this connection from callbacks
try {
proxy.Disconnect();
}
catch {
// Ignore the error - just close the connection
}
// Close the WCF-connection
DropProxy(proxy);
}
private static void DropProxy(CommandsProxy proxy) {

// First hand choice is to close the connection gracefully
if ((proxy != null) && (proxy.State != CommunicationState.Faulted)) {
try {
proxy.Close();
proxy = null;

}
catch {
// Ignore the error - abort the connection in the next step
}
}
// Second hand choice is to just terminate the proxy

if (proxy != null) {
try {
proxy.Abort();
}
catch {
// Ignore the error - not much we can do anyway.
}
}
}
}
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.
Return to the implementation of ICommonCallback.ServiceIsClosing (previously left empty).

ICommonCallback.ServiceIsClosing will be called if IDS7 is closed before the test application. The test
application is then expected to immediately close the connection to the Context Manager, without calling
ICommands.Disconnect.
private CommandsProxy myProxy = null;
private ICommands Proxy {

get { return this.myProxy; }
}
protected override void OnShown(EventArgs e) {

base.OnShown(e);
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.");
}
}
protected override void OnClosing(CancelEventArgs e) {

base.OnClosing(e);
if (!e.Cancel) {
DisconnectFromCommandsEndpoint(this.myProxy);
this.myProxy = null;
}
}
...
public void ServiceIsClosing() {

// Close the connection. We should also start an reoccurring
// task trying to reconnect if/when a new Context Manager
// instance comes online. This is however outside the scope
// of this example...
DropProxy(this.myProxy);
this.myProxy = null;
}
}

Implement the Click-event handler for the PACS button

Return to the handler for the Click event for the PACS button (previously left empty). The handler
should call ICommands.ShowView in order to request IDS7 to bring the information window to the
front.
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.
...
[System.Runtime.InteropServices.DllImport("user32.dll")]
private static extern bool AllowSetForegroundWindow(int dwProcessId);
private void activatePACSButton_Click(object sender, EventArgs e) {

try {
AllowSetForegroundWindow(-1);
this.Proxy.ShowView(null, "IDS7InformationWindow");
}
catch (Exception exc) {
MessageBox.Show(this, "Failed to activate PACS: " + exc.Message);
}
}
}
Implement the ICommandsCallback.ShowView callback method

The ICommandsCallback.ShowView callback method will be called when the user selects
Window->Current RIS Window in IDS7. The implementation of the method should bring the test
application's GUI to the front on the desktop.
...
public void ShowView(string viewId) {

// We should only act if IDS7 does not specify any specific view.
// If a specific view is given, then some other application
// should bring its GUI to the front.
if (String.IsNullOrEmpty(viewId)) {
if (this.WindowState == FormWindowState.Minimized) {
this.WindowState = FormWindowState.Normal;
}
this.Activate();
}
}
}
Compile and run the application

Compile the example application, but do not start it yet (since it has no automatic reconnect function
if IDS7 is not already running).
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.

5 Development guides

■ General guides
■ Commands endpoint guides
■ CurrentCase endpoint guides
■ Login endpoint guides
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.
5.1 General guides

This section contains guides concerning general tasks when interacting with the Context Manager, such
as connecting and disconnecting.
5.1.1 Connecting to a Context Manager endpoint

The following steps should be performed to establish a connection to one of the endpoints of the Context
Manager.
Step 1: Instantiate callback implementation

Instantiate an object that implements the callback interface of the endpoint. The callback interfaces are:
• ICommandsCallback for the Commands endpoint
• ICurrentCaseCallback for the CurrentCase endpoint
• ILoginCallback for the Login endpoint
Step 2: Instantiate a proxy

Instantiate a proxy object for the Context Manager connection:
• Call CommandsProxy.CreateMarshallingProxy to connect to the Commands endpoint. The proxy

exposes the service interface, ICommands, of the endpoint.
• Call CurrentCaseProxy.CreateMarshallingProxy to connect to the CurrentCase endpoint. The

proxy exposes the service interface, ICurrentCase, of the endpoint.
• Call LoginProxy.CreateMarshallingProxy to connect to the Login endpoint. The proxy exposes the
service interface, ILogin, of the endpoint.
IDS7, Version 24.1, March 2022 Development guides 25

Commands endpoint guides 5.2
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".
Step 3: Open the WCF connection

Call ClientBase.Open on the created proxy to open the connection to the Context Manager. If the call
fails, drop the proxy and schedule a task that tries to establish a new connection somewhat later.
Step 4: Register for callbacks

Call the Connect(...) method of the endpoint interface on the proxy (see for instance
ICommands.Connect). If the call fails, you should close the connection, drop the proxy and schedule a
task that tries to establish a new connection somewhat later.
The example given in section 4.4 An example project contains example code for how to connect to a
Context Manager endpoint.
5.1.2 Disconnecting from a Context Manager endpoint

The following steps should be taken to disconnect from a Context Manager endpoint.
Step 1: Unregister from callbacks

If Connect(...) was successfully called when the connection was established and the state of the proxy
is not faulted (see ClientBase.State in MSDN), then you should start by calling the Disconnect(...)
method on the endpoint interface of the proxy (see for instance ICommands.Disconnect).
Note that you should not call the Disconnect(...) method if you are disconnecting due to a
ICommonCallback.ServiceIsClosing callback from the Context Manager.
Step 2: Close the WCF connection

If the proxy is in a non-faulted state, you should call ClientBase.Close to close the proxy. If the proxy
is in a faulted state, call ClientBase.Abort instead.
The example given in section 4.4 An example project contains example code for how to disconnect from
a Context Manager endpoint.
5.2 Commands endpoint guides

The Commands endpoint is for forwarding commands between the applications that are connected to
the Context Manager. The currently available functionality is:
• 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.

CurrentCase endpoint guides 5.3
5.3 CurrentCase endpoint guides

An application should connect to the CurrentCase endpoint (see section 5.1.1 Connecting to a Context
Manager endpoint) to synchronize the current case (current examination and patient) with IDS7.
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.
5.3.1 Responding to sync from IDS7
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.
Call ITransactedService.RegisterApprovingVote or ITransactedService.RegisterDenyingVote to register

the vote of your application.
Step 3: Wait for commit or cancellation

Your application should now wait for the context manager to indicate if the transaction should be
committed or if it has been cancelled. The Context Manager will call
ICurrentCaseCallback.CommitCurrentCase if all applications agree to go ahead and commit the suggested
action. The Context Manager will call ITransactedCallback.TransactionCompleted if the transaction
has been cancelled.
Step 4: Commit the transaction

As a response to ICurrentCaseCallback.CommitCurrentCase your application should start switching
to the case specified by the parameters of the ICurrentCaseCallback.CommitCurrentCase callback. The
action to take depends on what parameters are provided and how they match the information in your
application. The possible scenarios are listed in the table below.
Scenario Expected behavior
The patient and examination is known to your application. Display the patient and examination.
The current examination belongs to the current patient.

CurrentCase endpoint guides 5.3
Scenario Expected behavior
The current examination is known to your application. Display the examination.

No patient is provided. This can be the case if the sync
is coming from an older version of IDS7.
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.
2. Display the patient, but do not select or highlight

any examination related information. This is
important in order to prevent the applications from
displaying different examinations.
(In this scenario, IDS7 would clear the user interface,

as the specified examination is not found.)
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 5: Wait for the transaction to finish

The Context Manager will call ITransactedCallback.TransactionCompleted when all applications have
finished switching current case. If the parameters of the ITransactedCallback.TransactionCompleted
callback indicates that an error has occurred, your application should just notify the user about the error
in a non-blocking way (as described in section 3.3 Callback interface considerations). It should not start
switching current case again in some attempt to regain synchronization automatically.
5.3.2 Synchronizing to IDS7
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.
You start the transaction by calling ICurrentCase.StartCurrentCaseTransaction on the Context Manager.

If you know the identity of the examination or patient that will become the new current case, then you
should preferably use the variant of ICurrentCase.StartCurrentCaseTransaction that allows you to
specify the suggested new current case. This will give the other applications more information to base
their decision to approve or deny the transaction upon.

Login endpoint guides 5.4
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.
Step 2: Wait for approval or cancellation

The Context Manager will call ITransactedCallback.TransactionApproved to notify your application
when IDS7 and all other applications have agreed to go ahead and switch current case.
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.

As a response to the ITransactedCallback.TransactionApproved callback, your application is expected
to call ICurrentCase.CommitApprovedTransaction and then to start switching current case accordingly.
Your application should call ITransactedService.CommitCompleted when it has finished switching

current case. If any unexpected error occurs while switching case, your application should instead call

finished switching current case. If the parameters of the ITransactedCallback.TransactionCompleted
callback indicates that an error has occurred, your application should just notify the user about the error
in a non-blocking way (as described in section 3.3 Callback interface considerations). It should not start
switching current case again in some attempt to regain synchronization automatically.
5.4 Login endpoint guides

An application should connect to the Login endpoint (see section 5.1.1 Connecting to a Context Manager
endpoint) to synchronize user log on and user log off with IDS7.
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.
5.4.1 Checking current user when connected to the Context Manager

After connecting to the Login endpoint, as described in section 5.1.1 Connecting to a Context Manager
endpoint, your application should check if there already is a user logged on in IDS7. You can do this by
calling ILogin.GetCurrentSession on the Context Manager.
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.
If the ILogin.GetCurrentSession call fails with exception FaultException<TransactionStateException>,

then a login transaction is in progress. Your application should then wait for a
ITransactedCallback.TransactionCompleted callback and then try calling ILogin.GetCurrentSession
again.
5.4.2 Responding to synchronized log on from IDS7
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.
Reasons to deny log on could be:
• 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.
• Another user is already logged on.


Your application should now wait for the context manager to indicate if the transaction should be
committed or if it has been cancelled. The Context Manager will call ILoginCallback.CommitLogin if
all applications agree to go ahead and log on the user. The Context Manager will call
ITransactedCallback.TransactionCompleted if the transaction has been cancelled.

As a response to ILoginCallback.CommitLogin your application should start logging on the user specified
by the parameters of the ILoginCallback.CommitLogin callback.
Your application should call ITransactedService.CommitCompleted when it has logged on. If any
unexpected error occurs while logging on, your application should instead call

logged on. If the parameters of the ITransactedCallback.TransactionCompleted callback indicates that
an error has occurred, your application should just notify the user about the error in a non-blocking
way (as described in section 3.3 Callback interface considerations).

5.4.3 Validating an UserIdentifier instance

As described in section 5.4.2 Responding to synchronized log on from IDS7, a UserIdentifier data
container is transferred from IDS7 to the synchronized applications when a user has been authenticated
by IDS7. This section describes how to use the UserIdentifier data container as proof of user
authentication.
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.
• UserIdentifier.CustomAuthenticationData - This property contains a CustomAuthenticationData

including a security token 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 security token 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.
The value of UserIdentifier.HashCode is calculated in the following manner:
1. Concatenate the values of UserIdentifier.TimeStamp, UserIdentifier.UserId, UserIdentifier.FullName

and the "system password" of your system into a single string.
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.
3. Calculate a 160 bit SHA1 hash value for the byte-array.

The value of UserIdentifier.CustomAuthenticationData is calculated based on some algorithm provided

by the system you are integrating with.
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.
5.4.4 Validating an AssignmentInfo instance

A UserIdentifier may contain an AssignmentInfo instance in its Assignment property. The AssignmentInfo
describes the purpose of the login session and this information is typically used to determine what patient
data the user should have access to.
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.
The value of AssignmentInfo.HashCode is calculated in the following manner:
1. Concatenate the values of UserIdentifier.TimeStamp, UserIdentifier.UserId,

UserIdentifier.FullName, AssignmentInfo.CareUnitIdIssuer, AssignmentInfo.CareUnitId,
AssignmentInfo.AssignmentId and the "system password" of your system into a single string. The
UserIdentifier property values should be fetched from the instance that contains the current
AssignmentInfo.
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.
3. Calculate a 160 bit SHA1 hash value for the byte-array.
The SDK contains code that validates a UserIdentifier, including any contained AssignmentInfo. See
section 7.4.2 UserIdentifierFactory.ValidateIdentifier static method.
5.4.5 Supporting "inactivity log off"

IDS7 automatically logs off if the user has been inactive for some configurable time. That is, IDS7 logs
off if it has not received any user input for a while. A reason for IDS7 not receiving any user input could
be that the user currently is working in one of the synchronized applications. It is not desirable that
IDS7 logs off in this situation.
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.

5.4.6 Responding to synchronized log off from IDS7
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.)


Your application should now wait for the Context Manager to indicate if the transaction should be
committed or if it has been cancelled. The Context Manager will call ILoginCallback.CommitLogout
if all applications agree to go ahead and log off. The Context Manager will call
ITransactedCallback.TransactionCompleted if the transaction has been cancelled.

As a response to ILoginCallback.CommitLogout your application should start logging off. Your
application should call ITransactedService.CommitCompleted when it has finished logging off. If any
unexpected error occurs while logging off, your application should instead call

logged off.
5.4.7 Synchronizing log off to IDS7
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.
You start the transaction by calling ILogin.StartLogoutTransaction on the Context Manager.
Step 2: Wait for approval or cancellation

The Context Manager will then call ITransactedCallback.TransactionApproved to notify your application
when IDS7 and all other applications have agreed to go ahead and log off.
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.


As a response to the ITransactedCallback.TransactionApproved callback, your application is expected
to call ILogin.CommitApprovedTransaction and then to start logging off.
Your application should call ITransactedService.CommitCompleted when it has logged off. If any
unexpected error occurs while logging off, your application should instead call

logged off.

6 Interface reference

■ Overview
■ Common interfaces
■ CurrentCase endpoint interfaces
■ Commands endpoint interfaces
■ Login endpoint 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 interfaces are organized in an inheritance hierarchy, as described below.
IDS7, Version 24.1, March 2022 Interface reference 35

Common interfaces 6.2
Inheritance hierarchy of the Context Manager interfaces.
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).
Inheritance hierarchy of the Context Manager callback interfaces.
6.2 Common interfaces

This section describes the base interfaces that the Context Manager service endpoint interfaces inherit
from.
See also
• section 6.4 Commands endpoint interfaces
• section 6.3 CurrentCase endpoint interfaces
• section 6.5 Login endpoint interfaces

6.2.1 ICommonCallback interface

Interface ICommonCallback is the base interface for the callback interface that a client needs to
implement when connecting to a Context Manager endpoint. The interface provides means for the
Context Manager to verify that the connection to the client is still healthy. It also makes it possible for
the Context Manager to notify the client if the Context Manager unexpectedly loses contact with any
of the other connected clients.
Namespace: Sectra.Client.ContextManager
Syntax
public interface ICommonCallback
See also
• section 3.3 Callback interface considerations
• section 5.1 General guides
• section 6.2.2 ICommonService interface
• section 6.2.3 ITransactedCallback interface
• section 6.4.2 ICommandsCallback interface
6.2.1.1 ICommonCallback.LostContact method

Called by the Context Manager to inform your application that the Context Manager has unexpectedly
lost contact with one or more of the other applications.
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.
6.2.1.2 ICommonCallback.Ping method

Called by the Context Manager to verify that the connection to the client is still healthy.
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.
6.2.1.3 ICommonCallback.ServiceIsClosing method

Called by the Context Manager to notify the connected applications that the Context Manager is closing
down.
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
6.2.2 ICommonService interface

Interface ICommonService is the base interface for all Context Manager service endpoints. The interface
provides means for the client to verify that the connection to the service is still healthy.
Syntax
[ServiceContract(CallbackContract = typeof(ICommonCallback))]
public interface ICommonService
See also
• section 6.2.1 ICommonCallback interface
• section 6.2.4 ITransactedService interface
• section 6.4.1 ICommands interface
6.2.2.1 ICommonService.Ping method

Performs a call to the Context Manager service to verify that the connection is still healthy.
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
6.2.3 ITransactedCallback interface

Interface ITransactedCallback is the base interface for the callback interface that a client needs to
implement when connecting to a Context Manager endpoint that use a transaction-based communication
scheme. The interface contains common methods for the Context Manager to notify the connected
applications about the progress of the current transaction.
Syntax
public interface ITransactedCallback : ICommonCallback
Remarks
The ITransactedCallback interface inherits from interface ICommonCallback.
See also
• section 3.2 Context Manager transactions
• section 6.2.4 ITransactedService interface
• section 6.3.2 ICurrentCaseCallback interface
• section 6.5.2 ILoginCallback interface
6.2.3.1 ITransactedCallback.TransactionApproved method

Called by the Context Manager to notify the application that has initiated a transaction that all other
applications have registered approving votes.
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
• section 6.3.1.1 ICurrentCase.CommitApprovedTransaction method
• section 6.5.1.1 ILogin.CommitApprovedTransaction method
6.2.3.2 ITransactedCallback.TransactionCompleted method

Called by the Context Manager to notify all connected applications that a transaction has finished.
Syntax
[OperationContract(Name = "TransactedCB_TransactionCompleted")]
void TransactionCompleted(
ContextTransactionIdentifier transactionId,
ContextTransactionResult result
)
Parameters
• result - A ContextTransactionResult containing the completion status of the transaction and,

optionally, an error message if the transaction was not completed successfully.
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.
6.2.4 ITransactedService interface

Interface ITransactedService is the base interface for the Context Manager service endpoints that use
a transaction-based communication scheme. The interface contains the common methods for registering
votes, reporting commit completed and reporting transaction errors.
Syntax
[ServiceContract(CallbackContract = typeof(ITransactedCallback))]
public interface ITransactedService : ICommonService
Remarks
The ITransactedService interface inherits from interface ICommonService.
See also
• section 6.2.3 ITransactedCallback interface
• section 6.3.1 ICurrentCase interface
• section 6.5.1 ILogin interface

6.2.4.1 ITransactedService.CancelApprovedTransaction method

Cancels an approved transaction before the commit phase is entered.
Syntax
[OperationContract(Name = "TransactedService_CancelApprovedTransaction")]
[FaultContract(typeof(ServiceClosingException))]
[FaultContract(typeof(TransactionStateException))]
void CancelApprovedTransaction(
)
Parameters
Exceptions
Exception type Condition
FaultException<ServiceClosingException> The Context Manager is closing down. Your application should

immediately close the connection to the Context Manager.
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 Context Manager responds to CancelApprovedTransaction by completing the current transaction

without entering the commit phase. The Context Manager notifies all connected applications that the
transaction has been cancelled by calling ITransactedCallback.TransactionCompleted.
6.2.4.2 ITransactedService.CommitCompleted method

Reports to the Context Manager that this application has successfull completed the commit phase of
the current transaction.
Syntax
[OperationContract(Name = "TransactedService_CommitCompleted")]
void CommitCompleted(
)
Parameters
Exceptions


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.
6.2.4.3 ITransactedService.RegisterApprovingVote method

Registers a vote in the Context Manager that this application approves to perform the current transaction.
Syntax
[OperationContract(Name = "TransactedService_RegisterApprovingVote")]
void RegisterApprovingVote(
)
Parameters
Exceptions

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
• section 6.3.2.2 ICurrentCaseCallback.VoteForCurrentCase method
• section 6.5.2.4 ILoginCallback.VoteForLogin method
• section 6.5.2.5 ILoginCallback.VoteForLogout method

6.2.4.4 ITransactedService.RegisterDenyingVote method

Registers a vote in the Context Manager that this application denies the current transaction.
Syntax
[OperationContract(Name = "TransactedService_RegisterDenyingVote")]
void RegisterDenyingVote(
string rationale
)
Parameters
• 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

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
• section 6.3.2.2 ICurrentCaseCallback.VoteForCurrentCase method
6.2.4.5 ITransactedService.ReportTransactionError method

Reports to the Context Manager that this application has encountered an error when processing the
current transaction.
Syntax
[OperationContract(Name = "TransactedService_ReportTransactionError")]
void ReportTransactionError(
string errorMessage
)

CurrentCase endpoint interfaces 6.3
Parameters
• 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

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.
6.3 CurrentCase endpoint interfaces

This section contains the reference documentation of the service and callback interfaces associated with
the CurrentCase endpoint of the Context Manager WCF service.
See also
• chapter 3 About the desktop synchronization interface
• section 5.3 CurrentCase endpoint guides
6.3.1 ICurrentCase interface

Interface ICurrentCase is the service contract for the CurrentCase endpoint of the Context Manager
(address net.pipe://localhost/SectraContextManager/CurrentCase). The CurrentCase endpoint
synchronizes the examination and patient currently selected in the connected applications.
An application that connects to the CurrentCase endpoint is required to implement callback interface
ICurrentCaseCallback.
Syntax
[ServiceContract(CallbackContract = typeof(ICurrentCaseCallback))]
public interface ICurrentCase : ITransactedService
Remarks
The ICurrentCase interface inherits from interface ITransactedService.

See also
• section 6.3.2 ICurrentCaseCallback interface
6.3.1.1 ICurrentCase.CommitApprovedTransaction method

Starts the commit phase of the given transaction.
Syntax
[OperationContract(Name = "CurrentCase_CommitApprovedTransaction")]
void CommitApprovedTransaction(
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

Remarks
The Context Manager responds to CommitApprovedTransaction by calling

ICurrentCaseCallback.CommitCurrentCase on all other applications, instructing them to start the
commit phase. It then waits for all applications to report that they have completed the commit phase.
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

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.
The platform invoke signature of AllowSetForegroundWindow is:

public static extern bool AllowSetForegroundWindow(int dwProcessId);
6.3.1.2 ICurrentCase.Connect method

Registers the current application for callbacks from the Context Manager CurrentCase endpoint.
Syntax
[OperationContract(Name = "CurrentCase_Connect")]
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
6.3.1.3 ICurrentCase.Disconnect method

Unregisters the current application from getting callbacks from the Context Manager CurrentCase
endpoint.
Syntax
[OperationContract(Name = "CurrentCase_Disconnect")]
void Disconnect()

Exceptions

See also
• section 6.3.1.2 ICurrentCase.Connect method
6.3.1.4 ICurrentCase.GetContext method

Returns the current case context that was set by the last successful current case transaction.
Syntax
[OperationContract(Name = "CurrentCase_GetContext")]
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

FaultException<TransactionStateException> There is a transaction to change current case in progress. Your

application will get a ITransactedCallback.TransactionCompleted
callback from the Context Manager when the transaction has
finished. You can then try calling GetContext again.
6.3.1.5 ICurrentCase.StartCurrentCaseTransaction method

Initiates a new transaction to change current case.
Syntax
[OperationContract(Name = "CurrentCase_StartCurrentCaseTransactionNoContext")]
ContextTransactionIdentifier StartCurrentCaseTransaction()
[OperationContract(Name = "CurrentCase_StartCurrentCaseTransactionWithContext")]
ContextTransactionIdentifier StartCurrentCaseTransaction(
)
Parameters
• newContext - A CurrentCaseContext, specifying which case that the applications should switch
to.

Return value
Returns a ContextTransactionIdentifier, identifying the newly created transaction.
Exceptions

FaultException<TransactionStateException> A transaction to change current case is already in progress. Your

callback from the Context Manager when the ongoing transaction
has finished.
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.
6.3.1.6 ICurrentCase.GetConnectedApplicationIds method

Returns the Application Ids of currently connected systems
Syntax
[OperationContract(Name = "CurrentCase_GetConnectedApplicationIds")]
string[] GetConnectedApplicationIds();
Return value
Returns a list of application identifiers.
Exceptions


6.3.2 ICurrentCaseCallback interface

Interface ICurrentCaseCallback is the callback interface that must be implemented by an application
that connects to the CurrentCase endpoint of the Context Manager (address
net.pipe://localhost/SectraContextManager/CurrentCase).
Syntax
public interface ICurrentCaseCallback : ITransactedCallback
Remarks
The ICurrentCaseCallback interface inherits from interface ITransactedCallback.
See also
• section 6.3.1 ICurrentCase interface
6.3.2.1 ICurrentCaseCallback.CommitCurrentCase method

Called by the Context Manager to notify all applications that have voted in a transaction that the commit
phase of the transaction is starting.
Syntax
[OperationContract(Name = "CurrentCaseCB_CommitCurrentCase")]
void CommitCurrentCase(
)
Parameters
• 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.
If CommitCurrentCase is called unexpectedly or if your application encounters an error while switching

current case, it should call ITransactedService.ReportTransactionError instead of
ITransactedService.CommitCompleted.
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.

Commands endpoint interfaces 6.4
6.3.2.2 ICurrentCaseCallback.VoteForCurrentCase method

Called by the Context Manager when some other application has initiated a transaction to switch current
case.
Syntax
[OperationContract(Name = "CurrentCaseCB_VoteForCurrentCaseNoContext")]
void VoteForCurrentCase(
)
[OperationContract(Name = "CurrentCaseCB_VoteForCurrentCaseWithContext")]
void VoteForCurrentCase(
)
Parameters
• 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
6.4 Commands endpoint interfaces

the Commands endpoint of the Context Manager WCF service.

See also
• section 5.2 Commands endpoint guides
6.4.1 ICommands interface

Interface ICommands is the service contract for the Commands endpoint of the Context Manager
(address net.pipe://localhost/SectraContextManager/Commands). The purpose of the Commands
endpoint is to forward non-transactional commands between the connected applications. One such
command would be for one application to request another application to bring its main window to the
front.
An application that connects to the Commands endpoint is required to implement callback interface
ICommandsCallback.
Syntax
[ServiceContract(CallbackContract = typeof(ICommandsCallback))]
public interface ICommands : ICommonService
Remarks
The ICommands interface inherits from interface ICommonService.
See also
• section 6.4.2 ICommandsCallback interface
6.4.1.1 ICommands.Connect method

Registers the current application for callbacks from the Context Manager Commands endpoint.
Syntax
[OperationContract(Name = "Commands_Connect")]
void Connect(
)
Parameters
by.

Exceptions

See also
• section 6.4.1.2 ICommands.Disconnect method
6.4.1.2 ICommands.Disconnect method

Unregisters the current application from getting callbacks from the Context Manager Commands
endpoint.
Syntax
[OperationContract(Name = "Commands_Disconnect")]
void Disconnect()
Exceptions

See also
• section 6.4.1.1 ICommands.Connect method
6.4.1.3 ICommands.ShowView method

Forwards the "show view" command to the other applications by calling ICommandsCallback.ShowView
on the other connected applications.
Syntax
[OperationContract(Name = "Commands_ShowView")]
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:
viewId value IDS7 reaction
IDS7InfoOrMatrixWindow Brings either the information window or the matrix

window to the front, depending on the current state of
IDS7.
IDS7InformationWindow Brings the information window to the front.
IDS7MatrixWindow Brings the matrix window to the front.
IDS7ImageWindows Brings the image windows to the front.
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.
The platform invoke signature of AllowSetForegroundWindow is:

public static extern bool AllowSetForegroundWindow(int dwProcessId);
See also
• section 6.4.2.1 ICommandsCallback.ShowView method
6.4.2 ICommandsCallback interface

Interface ICommandsCallback is the callback interface that must be implemented by an application
that connects to the Commands endpoint of the Context Manager (address
net.pipe://localhost/SectraContextManager/Commands).
Syntax
public interface ICommandsCallback : ICommonCallback
Remarks
The ICommandsCallback interface inherits from interface ICommonCallback.
See also

Login endpoint interfaces 6.5
• section 6.4.1 ICommands interface
6.4.2.1 ICommandsCallback.ShowView method

Called by the Context Manager to forward the "show view" command when some application has called
ICommands.ShowView.
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.
IDS7 sends the following view identifiers:
viewId value Condition
<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.
6.5 Login endpoint interfaces

the Login endpoint of the Context Manager WCF service.
See also
• section 5.4 Login endpoint guides
6.5.1 ILogin interface

Interface ILogin is the service contract for the Login endpoint of the Context Manager (address
net.pipe://localhost/SectraContextManager/Login). The Login endpoint synchronizes the user
currently logged on in the connected applications.
An application that connects to the Login endpoint is required to implement callback interface
ILoginCallback.

Syntax
[ServiceContract(CallbackContract = typeof(ILoginCallback))]
public interface ILogin : ITransactedService
Remarks
The ILogin interface inherits from interface ITransactedService.
See also
• section 6.5.2 ILoginCallback interface
6.5.1.1 ILogin.CommitApprovedTransaction method

Starts the commit phase of the given transaction.
Syntax
[OperationContract(Name = "Login_CommitApprovedTransaction")]
LoginSession CommitApprovedTransaction(
)
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

Remarks
The Context Manager responds to CommitApprovedTransaction by calling

ILoginCallback.CommitLogin or ILoginCallback.CommitLogout on all other applications, instructing
them to start the commit phase. The Context Manager then waits for all applications to report that they
have completed the commit phase.

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
6.5.1.2 ILogin.Connect method

Registers the current application for callbacks from the Context Manager Login endpoint.
Syntax
[OperationContract(Name = "Login_Connect")]
void Connect(
)
Parameters
by.
Exceptions

See also
• section 6.5.1.3 ILogin.Disconnect method
6.5.1.3 ILogin.Disconnect method

Unregisters the current application from getting callbacks from the Context Manager Login endpoint.
Syntax
[OperationContract(Name = "Login_Disconnect")]
void Disconnect()
Exceptions


See also
• section 6.5.1.2 ILogin.Connect method
6.5.1.4 ILogin.GetCurrentSession method

Returns the current login session.
Syntax
[OperationContract(Name = "Login_GetCurrentSession")]
[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<TransactionStateException> There is a transaction to log on or off in progress. Your application

will get a ITransactedCallback.TransactionCompleted callback from
the Context Manager when the transaction has finished. You can
then try calling GetCurrentSession again.
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.
6.5.1.5 ILogin.LastRegisteredActivity method

Returns a timestamp for the last time any application called ILogin.RegisterUserActivity.
Syntax
[OperationContract(Name = "Login_LastRegisteredActivity")]
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.
6.5.1.6 ILogin.RegisterUserActivity method

Registers that the user is active in the current application to prevent other applications from performing
a logout due to user inactivity.
Syntax
[OperationContract(Name = "Login_RegisterUserActivity")]
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
6.5.1.7 ILogin.StartLoginTransaction method

Initiates a new Context Manager transaction to log on the specified user.
Syntax
[OperationContract(Name = "Login_StartLoginTransaction")]
[FaultContract(typeof(ArgumentNullException))]
ContextTransactionIdentifier StartLoginTransaction(
UserIdentifier user
)

Parameters
• user - A UserIdentifier, identifying the user that has been authenticated by the application that calls
StartLoginTransaction.
Return value
Exceptions
FaultException<ArgumentNullException> No UserIdentifier was given or the value of the UserIdentifier.UserId

property was not set.

FaultException<TransactionStateException> There is a transaction to log a user on or off in progress. Your

finished.
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
See also
• section 5.4.3 Validating an UserIdentifier instance
• section 6.5.1.8 ILogin.StartLogoutTransaction method
• section 6.5.1.4 ILogin.GetCurrentSession method
6.5.1.8 ILogin.StartLogoutTransaction method

Initiates a new Context Manager transaction to log off the user currently logged on.
Syntax
[OperationContract(Name = "Login_StartLogoutTransaction")]
[FaultContract(typeof(ArgumentException))]
ContextTransactionIdentifier StartLogoutTransaction(
LoginSessionIdentifier sessionId
)
Parameters
• sessionId - A LoginSessionIdentifier, identifying the login session to be terminated.

Return value
Exceptions
FaultException<ArgumentException> The given LoginSessionIdentifier is not valid.

FaultException<TransactionStateException> There is a transaction to log a user on or off in progress. Your

finished.
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
See also
• section 6.5.1.7 ILogin.StartLoginTransaction method
• section 6.5.1.4 ILogin.GetCurrentSession method
6.5.2 ILoginCallback interface

Interface ILoginCallback is the callback interface that must be implemented by an application that
connects to the Login endpoint of the Context Manager (address
net.pipe://localhost/SectraContextManager/Login).
Syntax
public interface ILoginCallback : ITransactedCallback
Remarks
The ILoginCallback interface inherits from interface ITransactedCallback.
See also
• section 6.5.1 ILogin interface

6.5.2.1 ILoginCallback.CommitLogin method

Syntax
[OperationContract(Name = "LoginCB_CommitLogin")]
void CommitLogin(
LoginSession session
)
Parameters
• session - A LoginSession specifying the user to be logged on.
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
6.5.2.2 ILoginCallback.CommitLogout method

Syntax
[OperationContract(Name = "LoginCB_CommitLogout")]
void CommitLogout(
)
Parameters
• sessionId - A LoginSessionIdentifier specifying the session to be logged out.
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
6.5.2.3 ILoginCallback.GetCurrentUser method

Returns an UserIdentifier for the user currently logged on in the application.

Syntax
[OperationContract(Name = "LoginCB_GetCurrentUser")]
UserIdentifier GetCurrentUser(
)
Parameters
• sessionId - A LoginSessionIdentifier, identifying the login session that this query concerns.
Exceptions
FaultException<TransactionStateException> The GetCurrentUser callback was unexpectedly called, or the given

LoginSessionIdentifier was invalid.
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
6.5.2.4 ILoginCallback.VoteForLogin method

Called by the Context Manager when some other application has initiated a transaction to log on the
specified user.
Syntax
[OperationContract(Name = "LoginCB_VoteForLogin")]
void VoteForLogin(
UserIdentifier userId
)
Parameters
• 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.

Data types 6.6
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 6.5.1.7 ILogin.StartLoginTransaction method
6.5.2.5 ILoginCallback.VoteForLogout method

Called by the Context Manager when some other application has initiated a transaction to log on the
specified user.
Syntax
[OperationContract(Name = "LoginCB_VoteForLogout")]
void VoteForLogout(
)
Parameters
• sessionId - A LoginSessionIdentifier, identifying the login session that is suggested to be logged

out.
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.
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.1.8 ILogin.StartLogoutTransaction method
6.6 Data types

The topics in this section describe the serializable data types used in the desktop synchronization interface.

Data types 6.6
6.6.1 CaseIdentifier class

Class CaseIdentifier is a data container holding identification data for an examination.
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.
6.6.1.1 CaseIdentifier.AccessionNumber property

Gets the accession number of the examination.
Syntax
public string AccessionNumber { get; }
6.6.1.2 CaseIdentifier.AccessionNumberGroupId property

Gets the Accession number integration ID of the examination.
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.
6.6.1.3 CaseIdentifier.CaseIdentifier constructor

Initializes a new instance of the CaseIdentifier class.
Syntax
public CaseIdentifier(
string accessionNumberGroupId,
string accessionNumber,
string examinationNumber
)
Parameters
• accessionNumberGroupId - The accession number group identifier. See property
CaseIdentifier.AccessionNumberGroupId for further information.

Data types 6.6
• accessionNumber - The accession number of the examination.
• examinationNumber - The examination number of the examination.
6.6.1.4 CaseIdentifier.ExaminationNumber property

Gets the examination number of the examination.
Syntax
public string ExaminationNumber { get; }
6.6.1.5 CaseIdentifier.ToString method

Returns a string representation of this instance, to be used for debug and trace purposes.
Syntax
public override string ToString()
6.6.2 ContextTransactionIdentifier class

Class ContextTransactionIdentifier is a type-safe wrapper around a Guid identifying a Context
Manager transaction.
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.
6.6.2.1 ContextTransactionIdentifier.Equals method

Returns a value indicating whether this instance is equal to a specified object.
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.

Data types 6.6
6.6.2.2 ContextTransactionIdentifier.GetHashCode method

Returns the hash code for this instance.
Syntax
public override int GetHashCode()
6.6.2.3 ContextTransactionIdentifier.NewIdentifier property

Gets a new (unique) Context Manager transaction identifier.
Syntax
public static ContextTransactionIdentifier NewIdentifier { get; }
6.6.2.4 ContextTransactionIdentifier.op_Equality method

Returns an indication whether the values of two specified ContextTransactionIdentifier objects are
equal.
Syntax
public static bool operator ==(
ContextTransactionIdentifier lhs,
ContextTransactionIdentifier rhs
)
Parameters
• lhs - A ContextTransactionIdentifier object.
• rhs - A ContextTransactionIdentifier object.
Return value
Returns true if the value of lhs equals the value of rhs.
6.6.2.5 ContextTransactionIdentifier.op_Inequality method

Returns an indication whether the values of two specified ContextTransactionIdentifier objects differ.
Syntax
public static bool operator !=(
)
Parameters
• lhs - A ContextTransactionIdentifier object.
• rhs - A ContextTransactionIdentifier object.
Return value
Returns true if the value of lhs differs from the value of rhs.

Data types 6.6
6.6.2.6 ContextTransactionIdentifier.ToString method

Syntax
6.6.3 ContextTransactionResult class

Class ContextTransactionResult is a data container that the Context Manager distributes to the
attached applications when an transaction has finished.
Syntax
[DataContract]
public class ContextTransactionResult
See also
• section 6.2.3.2 ITransactedCallback.TransactionCompleted method
6.6.3.1 ContextTransactionResult.ContextTransactionResult constructor

Initializes a new instance of class ContextTransactionResult.
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.
6.6.3.2 ContextTransactionResult.FailingApplication property

Returns the user-friendly name of the application that caused the transaction to fail.
Syntax
public string FailingApplication { get; }
Remarks
Only valid if the ContextTransactionResult.Status property is CanceledByVoting or TransactionError.

Data types 6.6
6.6.3.3 ContextTransactionResult.FailingRationale property

Returns the rationale given by the application that caused the transaction to fail.
Syntax
public string FailingRationale { get; }
Remarks
Only valid if the ContextTransactionResult.Status property is CanceledByVoting or TransactionError.
6.6.3.4 ContextTransactionResult.Status property

Returns the finishing status of the transaction.
Syntax
public ContextTransactionStatus Status { get; }
Property Value
The returned ContextTransactionStatus indicates the finishing status of the transaction.
6.6.4 ContextTransactionStatus enumeration

Specifies the status of a finished Context Manager transaction. Used by the
ContextTransactionResult.Status property.
Syntax
public enum ContextTransactionStatus
Members
Member name Description
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.
6.6.5 CurrentCaseContext class

Class CurrentCaseContext is a data container communicated over the Context Manager CurrentCase
endpoint, synchronizing what case to display in the connected applications. The CurrentCaseContext

Data types 6.6
contains an identifier for the current case as well as an optional identifier for the application view that
should be opened.
Syntax
[DataContract]
public class CurrentCaseContext
See also
• section 6.6.1 CaseIdentifier class
6.6.5.1 CurrentCaseContext.CurrentCaseContext constructor

Initializes a new instance of class CurrentCaseContext.
Syntax
The four variants of this constructor applies to the four different scenarios that are valid for current case
synchronization.
Constructor to be used if both current patient and examinations are available:

public CurrentCaseContext(
string viewIdentifier,
PatientIdentifier currentPatient,
int indexOfCurrentCase,
List<CaseIdentifier> relatedCases,
bool forceRefresh
)
Constructor to be used if only examination information is available:

int indexOfCurrentCase,
List<CaseIdentifier> relatedCases,
bool forceRefresh
)
Constructor to be used if only the patient information is available:

PatientIdentifier currentPatient,
bool forceRefresh
)
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.
• currentPatient - The current patient. See CurrentCaseContext.CurrentPatient for more information.

Data types 6.6
• 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]).
6.6.5.2 CurrentCaseContext.CurrentPatient property

Returns the patient identifier of the current case.
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).
6.6.5.3 CurrentCaseContext.IndexOfCurrentCase property

Returns the index of the CaseIdentifier in the list returned by CurrentCaseContext.RelatedCases that
identifies the current examination.
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.
6.6.5.4 CurrentCaseContext.RelatedCases property

Returns a list of CaseIdentifier items, specifying the current case and optionally a number of cases that
are related to 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.

Data types 6.6
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.
6.6.5.5 CurrentCaseContext.ViewIdentifier property

Returns a string identifying the view that the sending applications wants the other applications to display.
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.
ViewIdentifier value Condition
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.
ViewIdentifier value IDS7 reaction
IDS7InformationWindow Brings the information window to the front.
IDS7MatrixWindow Brings the matrix window to the front.
IDS7ImageWindows Brings the image windows to the front.
IDS7CloseImageAndMatrixWindows Closes the matrix and image windows if they are open.
6.6.5.6 CurrentCaseContext.ForceRefresh property

Returns true if the sending application wants the other applications to refresh regardless of any
configuration settings.
Syntax
public bool ForceRefresh { get; }

Data types 6.6
6.6.5.7 CurrentCaseContext.ToString method

Syntax
6.6.6 LoginSession class

Class LoginSession is communicated over the Context Manager Login endpoint to synchronize the
user currently logged on, so that the same user is automatically logged on in the other applications when
the user logs on in one of the applications.
Syntax
[DataContract]
public class LoginSession
See also
6.6.6.1 LoginSession.LoginSession constructor

Initializes a new instance of the LoginSession class.
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.
6.6.6.2 LoginSession.SessionId property

Gets the unique identifier of this login session.
Syntax
public LoginSessionIdentifier SessionId { get; }
Property value
A LoginSessionIdentifier, uniquely identifying this login session.
6.6.6.3 LoginSession.ToString method


Data types 6.6
Syntax
6.6.6.4 LoginSession.UserId property

Returns the identity of the user that is logged on in this session.
Syntax
public UserIdentifier UserId { get; }
Property value
A UserIdentifier, containing the identity of the user that is logged on in this session.
6.6.7 LoginSessionIdentifier class

Class LoginSessionIdentifier is a type-safe wrapper around a Guid identifying a user log on session,
initiated by a transaction on the Login endpoint on the Context Manager.
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.
6.6.7.1 LoginSessionIdentifier.Equals method

Returns a value indicating whether this instance is equal to a specified object.
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.
6.6.7.2 LoginSessionIdentifier.GetHashCode method

Returns the hash code for this instance.

Data types 6.6
Syntax
public override int GetHashCode()
6.6.7.3 LoginSessionIdentifier.NewIdentifier property

Gets a new (unique) Context Manager login session identifier.
Syntax
public static LoginSessionIdentifier NewIdentifier { get; }
6.6.7.4 LoginSessionIdentifier.op_Equality method

Returns an indication whether the values of two specified LoginSessionIdentifier objects are equal.
Syntax
public static bool operator ==(
)
Parameters
• lhs - A LoginSessionIdentifier object.
• rhs - A LoginSessionIdentifier object.
Return value
Returns true if the value of lhs equals the value of rhs.
6.6.7.5 LoginSessionIdentifier.op_Inequality method

Returns an indication whether the values of two specified LoginSessionIdentifier objects differ.
Syntax
public static bool operator !=(
)
Parameters
• lhs - A LoginSessionIdentifier object.
• rhs - A LoginSessionIdentifier object.
Return value
Returns true if the value of lhs differs from the value of rhs.
6.6.7.6 LoginSessionIdentifier.ToString method

Syntax

Data types 6.6
6.6.8 PatientIdentifier class

Class PatientIdentifier is a data container holding identification data for a patient.
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.
6.6.8.1 PatientIdentifier.PatientIdentifier constructor

Initializes a new instance of the PatientIdentifier class.
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.
6.6.8.2 PatientIdentifier.PatientId property

Gets the patient identifier of the patient.
Syntax
public string PatientId { get; }
6.6.8.3 PatientIdentifier.PatientIdIssuer property

Gets the MRN integration ID.
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.

Data types 6.6
6.6.8.4 PatientIdentifier.ToString method

Syntax
6.6.9 UserIdentifier class

Class UserIdentifier is an identifier of the user currently logged on in the applications connected to
the Context Manager Login endpoint. The identifier contains the name of the user as well as data
allowing the applications to verify that the identifier originates from a trusted application and that the
identifier has not been tampered with.
Syntax
[DataContract]
public class UserIdentifier
See also
• section 6.6.6 LoginSession class
6.6.9.1 UserIdentifier.Assignment property

Returns the purpose of the current login session.
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.
The Assignment property is optional and may be null.
See also
• section 6.6.10 AssignmentInfo class
6.6.9.2 UserIdentifier.FullName property

Returns the full name of the user.
Syntax
public string FullName { get; }

Data types 6.6
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
6.6.9.3 UserIdentifier.HashCode property

Returns a hash code for verification of the authenticity of this 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
6.6.9.4 UserIdentifier.CustomAuthenticationData property

Returns a list of custom security tokens for verification of the authenticity of this instance. The security
tokens returned are filtered to match the application id that is used when connecting to the context
manager (section 6.4.1.1 ICommands.Connect method).
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
6.6.9.5 UserIdentifier.TimeStamp property

Returns the time stamp for the creation of this 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

Data types 6.6
6.6.9.6 UserIdentifier.ToString method

Syntax
6.6.9.7 UserIdentifier.UserId property

Gets the login name of the user.
Syntax
public string UserId { get; }
Property value
The value of this property is a string, containing the login name of the user.
See also
6.6.9.8 UserIdentifier.UserIdentifier constructor

Initializes a new instance of the UserIdentifier class.
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>.
• fullName - A string, containing the full name of the authenticated user.
• hashCode - An array of bytes, containing a hash code for the receiver of a UserIdentifier to verify
the authenticity of the given instance.
• customAuthenticationData - A list of custom security tokens for verification of the authenticity

of this 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

Data types 6.6
6.6.10 AssignmentInfo class

Class AssignmentInfo appears in property UserIdentifier.Assignment and describes the purpose of the
current login session. This information is typically used to determine what patient data the user should
have access to.
Syntax
[DataContract]
public class AssignmentInfo
See also
• section 6.6.9 UserIdentifier class
6.6.10.1 AssignmentInfo.AssignmentInfo constructor

Initializes a new instance of the AssignmentInfo class.
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
6.6.10.2 AssignmentInfo.AssignmentId property

Returns the type of assignment.
Syntax
public string AssignmentId { get; }

Data types 6.6
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.
• SHS->Extensibility->User Authorization->Assignments enabled: A local adaptation,

custom built by Sectra for each external system, is required to be able to integrate with the external
authorization services.
• SHS->Extensibility->User Authorization->Active directory groups as assignments:

SID of the AD group that determines the preferred role.
6.6.10.3 AssignmentInfo.CareUnitIdIssuer property

Returns the issuer of the care unit and assignment identifiers that the user is assigned to during the
session.
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.


AD domain.
6.6.10.4 AssignmentInfo.CareUnitId property

Returns the care unit that the user is assigned to during the session.
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.


Not used.
6.6.10.5 AssignmentInfo.HashCode property

Returns a hash code for verification of the authenticity of this instance.

Data types 6.6
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
6.6.10.6 AssignmentInfo.ToString method

Syntax
6.6.11 CustomAuthenticationData class

Class CustomAuthenticationData contains authentication data for verification of the authenticity of
the system. The authentication data contains a security token allowing the applications to verify that
the identifier originates from a trusted application and that the identifier has not been tampered with.
It also contains the identifier and version of the add-in used to create the security token.
Syntax
[DataContract]
public class CustomAuthenticationData
See also
6.6.11.1 CustomAuthenticationData.AddinId property

Returns the identifier of the addin used to create the security token.
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.
6.6.11.2 CustomAuthenticationData.Version property

Returns the version of the addin used to create the security token.
Syntax
public Version AddinVersion { get; }

Data types 6.6
Property value
The value of this property is a Version, containing the version of the addin used to create the security
token.
6.6.11.3 CustomAuthenticationData.SecurityToken property

Returns a security token for verification of the authenticity of this instance.
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.
6.6.11.4 CustomAuthenticationData.CustomAuthenticationData constructor

Initializes a new instance of the CustomAuthenticationData class.
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

7 SDK Reference

■ CommandsProxy class
■ CurrentCaseProxy class
■ LoginProxy class
■ UserIdentifierFactory class
This chapter contains the reference documentation of the utility classes provided in the IDS7 Desktop
Synchronization SDK.
7.1 CommandsProxy class

Class CommandsProxy is a proxy for the Commands endpoint on the Context Manager WCF service.
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.
Some additional features have however been implemented in CommandsProxy:
• 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
7.1.1 CommandsProxy.CreateMarshallingProxy static method

Initializes a new instance of class CommandsProxy. Callbacks on the given callback interface are
asynchronously marshalled to the current thread.
IDS7, Version 24.1, March 2022 SDK Reference 83

CommandsProxy class 7.1
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".
• callbackInterface - An object implementing the ICommandsCallback interface.
Exceptions
ArgumentException The value of parameter baseAddress was not valid.
ArgumentNullException Parameter callbackInterface was null.
InvalidOperationException No valid SynchronizationContext for the current thread. The value

of SynchronizationContext.Current was null.
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.
7.1.2 CommandsProxy.CreateNonMarshallingProxy static method

Initializes a new instance of class CommandsProxy. Callbacks on the given callback interface will be
performed on a thread from the WCF thread pool.
Syntax
public static CommandsProxy CreateNonMarshallingProxy(
string baseAddress,
ICommandsCallback callbackInterface
)
Parameters
• callbackInterface - An object implementing the ICommandsCallback interface.
Exceptions

CurrentCaseProxy class 7.2
Remarks
Callbacks are performed on threads from the WCF thread pool. The given implementation of
ICommandsCallback must implement proper thread synchronization.
7.2 CurrentCaseProxy class

Class CurrentCaseProxy is a proxy for the CurrentCase endpoint on the Context Manager WCF
service.
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.
Some additional features have however been implemented in CurrentCaseProxy:
• CurrentCaseProxy contains code setting up the endpoint binding programmatically, i.e. no config
file is needed to set up the WCF connection.
See also
7.2.1 CurrentCaseProxy.CreateMarshallingProxy static method

Initializes a new instance of class CurrentCaseProxy. Callbacks on the given callback interface are
asynchronously marshalled to the current thread.
Syntax
public static CurrentCaseProxy CreateMarshallingProxy(
string baseAddress,
ICurrentCaseCallback callbackInterface
)
Parameters
• callbackInterface - An object implementing the ICurrentCaseCallback interface.

CurrentCaseProxy class 7.2
Exceptions

Remarks
Callbacks are marshalled asynchronously to the current thread before the given ICurrentCaseCallback
7.2.2 CurrentCaseProxy.CreateNonMarshallingProxy static method

Initializes a new instance of class CurrentCaseProxy. Callbacks on the given callback interface will be
performed on a thread from the WCF thread pool.
Syntax
public static CurrentCaseProxy CreateNonMarshallingProxy(
string baseAddress,
ICurrentCaseCallback callbackInterface
)
Parameters
• callbackInterface - An object implementing the ICurrentCaseCallback interface.
Exceptions
Remarks
ICurrentCaseCallback must implement proper thread synchronization.

LoginProxy class 7.3
7.3 LoginProxy class

Class LoginProxy is a proxy for the Login endpoint on the Context Manager WCF service.
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.
Some additional features have however been implemented in LoginProxy:
• LoginProxy contains code setting up the endpoint binding programmatically, i.e. no config file is
needed to set up the WCF connection.
See also
7.3.1 LoginProxy.CreateMarshallingProxy static method

Initializes a new instance of class LoginProxy. Callbacks on the given callback interface are asynchronously
marshalled to the current thread.
Syntax
public static LoginProxy CreateMarshallingProxy(
string baseAddress,
ILoginCallback callbackInterface
)
Parameters
• callbackInterface - An object implementing the ILoginCallback interface.
Exceptions


UserIdentifierFactory class 7.4
Remarks
Callbacks are marshalled asynchronously to the current thread before the given ILoginCallback
7.3.2 LoginProxy.CreateNonMarshallingProxy static method

Initializes a new instance of class LoginProxy. Callbacks on the given callback interface will be performed
on a thread from the WCF thread pool.
Syntax
public static LoginProxy CreateNonMarshallingProxy(
string baseAddress,
ILoginCallback callbackInterface
)
Parameters
• callbackInterface - An object implementing the ILoginCallback interface.
Exceptions
Remarks
ILoginCallback must implement proper thread synchronization.
7.4 UserIdentifierFactory class

Class UserIdentifierFactory contains utility methods for creating and validating an instance of class
UserIdentifier.
Namespace: Sectra.Client.ContextManager.UserValidation
Syntax
public static class UserIdentifierFactory

See also
7.4.1 UserIdentifierFactory.CreateIdentifier static method

Creates a new UserIdentifier instance for a user that has been authenticated in the application.
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>.
• fullName - The full name of the authenticated user.
• 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
7.4.2 UserIdentifierFactory.ValidateIdentifier static method

Verifies that a given UserIdentifier instance is correctly hashed and that the creation time of the identifier
has not expired. Throws an exception if an error is detected.

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.
• maxTimeDiffInSeconds - Specifies the maximum allowed difference, in seconds, between the

creation time of the identifier and the current time.
Exceptions
ArgumentException No system password was given.
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

Compliance to Regulations and Standards
The Management System of Sectra AB [Sectra] conforms to ISO 9001, ISO 13485, ISO 27001, ISO 27017 and ISO 27018.
All Sectra medical devices have obtained regulatory clearance for those markets where Sectra sells and deploys its devices,
e.g. EEA, USA, Canada, Australia. For further regulatory information, please contact Sectra.
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.
All other names/products by ® or ™ are registered trademarks of the respective manufacturer.
The intellectual property of Sectra includes a number of patents, for full information refer to: https://sectra.com/medic-
al/about-sectra/patents/
Copyright and Legal

© Sectra AB, Sweden, 2022
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: info.medical@sectra.com
For other regions please visit www.sectra.com/medical/

IDS7_DevelopersGuide.DesktopSync

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IDS7_DevelopersGuide.DesktopSync

Uploaded by

Copyright:

Available Formats

Developer's Guide

IDS7 Desktop Synchronization

IDS7, Version 24.1, March 2022 About this document ii

About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

2 About desktop synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 About the desktop synchronization interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

IDS7, Version 24.1, March 2022 Contents iii

IDS7, Version 24.1, March 2022 Contents iv

The following topics are included in this chapter:

■ How this document is organized

■ Assumptions about the reader

■ Conventions used in this document

1.1 Related documents

[2] System Administrator's Guide Sectra Healthcare System

1.2 How this document is organized

A brief summary of the chapters in this document follows below:

chapter 2 About desktop synchronization

chapter 3 About the desktop synchronization interface

IDS7, Version 24.1, March 2022 Introduction 1

chapter 4 Getting started

chapter 5 Development guides

chapter 6 Interface reference

chapter 7 SDK Reference

1.3 Assumptions about the reader

1.4 Conventions used in this document

IDS7, Version 24.1, March 2022 Introduction 2

The following topics are included in this chapter:

■ Synchronization of current case

2.1 About the IDS7 workstation

IDS7, Version 24.1, March 2022 About desktop synchronization 3

IDS7 main windows

IDS7, Version 24.1, March 2022 About desktop synchronization 4

2.2 Synchronization of current case

IDS7 commands manually synchronizing the current case.

IDS7, Version 24.1, March 2022 About desktop synchronization 5

2.3 Single log on

IDS7, Version 24.1, March 2022 About desktop synchronization 6

The following topics are included in this chapter:

■ Context Manager transactions

■ Callback interface considerations

3.1 Introducing the Context Manager

The Context Manager WCF service is hosted by IDS7.

The Context Manger WCF service has three independent endpoints:

• The CurrentCase endpoint, net.pipe://localhost/SectraContextManager/CurrentCase, is

• The Commands endpoint, net.pipe://localhost/SectraContextManager/Commands, is for

• The Login endpoint, net.pipe://localhost/SectraContextManager/Login, is for single log

3.2 Context Manager transactions

3.2.1 Successful transaction example

Call graph for a successful transaction.

3.2.2 Denied transaction example

Call graph for a denied transaction.

7. The "listening" applications act as if the transaction never occurred.

3.2.3 Cancelled transaction example

Call graph for a cancelled transaction.

7. All applications remain in the same state as before transaction.

3.2.4 Transaction commit error example

Call graph for a transaction that fails in the commit phase.

3.2.5 Transaction voting error example

Call graph for a transaction that fails in the voting phase.

3.3 Callback interface considerations

Process callbacks asynchronously

The benefits of processing the callbacks asynchronously are:

• It eliminates the risk of deadlocks.

• It reduces the risk of errors due to WCF-level timeouts.