IHE ITI Technical Framework Supplement

crookpatedhatMobile - Wireless

Dec 10, 2013 (3 years and 6 months ago)

131 views

Copyright © 20xx: IHE International, Inc.

Integrating the Healthcare Enterprise





5

IHE ITI

Technical Framework

Supplement



Internet User Authorization

10

(I
U
A)




Draft
in preparation
for

P
ublic Comment


15

<
T
he IHE Documentation Specialist will change the title to just “
Draft for
Public Comment”
upo
n publication for public comment; leave “as is” until then.>



Date:


January 8, 2013

20

Author:

Rob Horn, Agfa Healthcare

Email:



IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

2

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3


25

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

3

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

Foreword

This
is a
supplement to the IHE
<
D
omain

Name
>

Technical Framework
<
V
X.X
>
.

Each
supplement undergoes a process of public comment and trial
implementation before being

incorporated into the volumes of the Technical Frameworks.

<
For Public
Comment
:
>

This

supplement
is published
on <
Month XX, 201x> for Public
30

Comment
.
Comments
are invited and may
be submitted
at

http://www.ihe.net/<domain>/<domain>comments.cfm
.
In order to be considered in
development of the Trial Implementation version of the supplement
,

comments must be received
by <Month XX, 201X>.

<
For Trial Implementa
tion
:
>

This

supplement is published on
<Month XX, 201X>

for Trial
35

Implementation
and may

be available for testing at subsequent IHE Connectathons
.
The
supplement may be amended based on the results of testing
.
Following successful testing it will
be incorp
orated into the <Domain Name> Technical Framework.
Comments are invited and may
be submitted

at
http://www.ihe.net/<domain>/<domain>comments.cfm
.

This supplement describes changes to the exis
ting technical framework documents
.


40


B
oxed” instructions
like the sample below indicate to
the Volume Editor how to integrate the
relevant section(s) into the
relevant

Technical Framework
volume
.

Amend s
ection X.X by the following:

Where the amendment add
s text, make the
added
text
bold underline
. Where the amendment
removes text
, make the removed text
bold strikethrough
. When entire new sections are added,
45

introduce with
editor’s instructions to “add new text” or similar, which for readability are not
bol
ded or underlined.


General information about IHE can be found at:
www.ihe.net
.

Information about the IHE <Domain Name>
domain
can

be found at
:
50

http://www.ihe.net/Domai
ns/index.cfm
.

Information about the
organization of IHE
Technical Frameworks and Supplements
and the
process used to create them
can be found at:
http://www.ihe.net/About/process.cfm

and
http://www.ihe.net/profiles/index.cfm
.

The current version of
the IHE

<
D
omain name>
Technical Framework can be found at:
55

http://www.ihe.net/Technical_F
ramework/index.cfm
.

<Com
ments may be submitted
on IHE Technical Framework templates

any time
at
http://ihe.net/ihetemplates.cfm
.
P
lease enter comments/issues as soon as they are found
.
Do not
wait until a fu
ture review cycle is announced
.


60

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

4

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

C
ONTENTS


Introduction to this Supplement

................................
................................
................................
......

6

Problem Statement

................................
................................
................................
..........................

6

65

Open Issues and Questions

................................
................................
................................
........

8

Closed Issues

................................
................................
................................
..............................

8

General Introduction

................................
................................
................................
.....................

10

Appendix A
-

Actor Summary Definitions

................................
................................
...................

10

Appendix B
-

Tran
saction Summary Definitions

................................
................................
.........

10

70

Glossary

................................
................................
................................
................................
........

10

Volume 1


Profiles

................................
................................
................................
......................

11

<
Copyright Licenses>

................................
................................
................................
..............

11

<
Domain
-
specific additions>

................................
................................
................................
..

11

X <Profile Name (Acronym)> Profile

................................
................................
..........................

12

75

X.1 <Profile Acronym> Actors, Transactions, and Content Modules

................................
.....

12

X.1.1 Actor Descriptions and Actor Profile Requirements

................................
.................

13

X.1.1.1 <Actor A>

................................
................................
................................
..........

15

X.1.1.2 <Actor B>

................................
................................
................................
..........

15

X.2 <Profile Acronym> Actor Options

................................
................................
....................

15

80

X.2.1 <Option Name>

................................
................................
................................
.........

15

X.3 <Profile Acronym> Required Actor Groupings

................................
................................

15

X.4 <Prof
ile Acronym> Overview

................................
................................
...........................

15

X.4.1 Concepts

................................
................................
................................
....................

15

X.4.1.1 Concept examples

................................
................................
..............................

16

85

X.4.1.2 Intended Uses

................................
................................
................................
....

18

X.4.2 Use Cases

................................
................................
................................
..................

18

X.4.2.1 Simple Authorization

................................
................................
.........................

19

X.4.2.1.1 Simple Authorization Use Case

................................
................................
.

19

X.4.2.1.2 Simple Authorization Flow

................................
................................
........

20

90

X.4.2.1 Simple Integrated U
se

................................
................................
.......................

21

X.4.2.1.2 Simple Integrated Use Flow

................................
................................
......

21

X.4.2.1 Redirect Based Separate Service

................................
................................
.......

22

X.4.2.3.1 Redirect Based Separate Service Workflow

................................
..............

22

X.4.2.1 Redirect Based Separate Service

................................
................................
.......

23

95

X.4.2.
3.1 Redirect Based Integrated Service Workflow

................................
...........

24

X.4.2.1 Machine Delegation

................................
................................
...........................

25

X.4.2.1.1 Delegation Use Case Description

................................
..............................

25

X.4.2.1.2 Delegation to a Device or Application Process Flow

................................

25

X.5 <Profile Acronym> Security Considerations

................................
................................
....

27

100

X.6 <Profile Acronym> Cross Profile Considerations

................................
............................

27

Appendices

................................
................................
................................
................................
....

28

Appendix A


S
tandards Evaluation and Tradeoffs

................................
................................
.....

28

A.1

<Add Title>

................................
................................
................................
.......................

34

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

5

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

Appendix B


<Appendix B Title>

................................
................................
...............................

34

105

B.1

<Add Title>

................................
................................
................................
.......................

34

Volume 2


Transactions

................................
................................
................................
..............

35

3.Y <Transaction Name [Domain Acronym
-
#]>

................................
................................
.....

35

3.Y.1 Scope

................................
................................
................................
.........................

35

3.Y.2 Actor Roles

................................
................................
................................
................

35

110

3.Y.3 Referenced Standards

................................
................................
................................

36

3.Y.4 Interaction Diagram

................................
................................
................................
...

36

3.Y.4.1 <Message 1 Name>

................................
................................
...........................

37

3.Y.4.1.1 Trigg
er Events

................................
................................
............................

37

3.Y.4.1.2 Message Semantics

................................
................................
....................

37

115

3.Y.4.1.3 Expected Actions

................................
................................
.......................

38

3.Y.4.2 <Message 2 Name>

................................
................................
...........................

38

3.Y.4.2.1 Trigger Events

................................
................................
............................

38

3.Y.4.2.2 Message Semantics

................................
................................
....................

38

3.Y.4.2.3 Expected Actions

................................
................................
.......................

38

120

3.Y.5 Security Considerations

................................
................................
.............................

39

3.Y.5.1 Security Audit Considera
tions

................................
................................
...........

39

3.Y.5.1.(z) <Actor> Specific Security Considerations

................................
..............

39

Appendices

................................
................................
................................
................................
....

40

Appendix A


<Appendix A Title>

................................
................................
..............................

40

125

C.1

<Add Title>

................................
................................
................................
.......................

40

Appendix B


<Appendix B Title>

................................
................................
...............................

40

B.1

<Add Title>

................................
................................
................................
.......................

40

Volume 2 Namespace Additions

................................
................................
................................
..

40

Volume 3


Content Modules

................................
................................
................................
.......

41

130

5. Namespaces and Vocabularies

................................
................................
................................
..

42

6. Content Modules

................................
................................
................................
.......................

43

6.4

<Domain Acr
onym> Value Sets

................................
................................
.......................

43

6.5.x

<Value Set Name> <oid>

................................
................................
..........................

43

Appendices

................................
................................
................................
................................
....

44

135

Appendix A


<Appendix A Title>

................................
................................
..............................

44

A.1

<Add Title>

................................
................................
................................
.......................

44

Appendix B


<Appendix B Title>

................................
................................
...............................

44

B.1

<Add Title>

................................
................................
................................
.......................

44

Volume 3 Namespace Additions

................................
................................
................................
..

44

140



IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

6

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

Introduction

to this Supplement

<
P
rovide a brief overview of the volumes/sectio
ns of the
Technical Framework

that get changed/
added by this
supplement
.
Provide
200 words or l
ess describing this

supplement
.
>

145

Problem Statement

This profile is motivated by
customer
requirements
for authorizing network transaction
s
, when
using

HTTP REST
ful

transports.
Authorization
means

that the
user,
patient or provider
,

has
legitimate

access to this
RESTful
service.
The authorization includes identifying the user,
device
, and or application that is making th
e request to the RESTful server
, so that server can
150

make further access control decisions
.
The RESTful services may
include

user driven browser
activity, downloaded applications, and automatic devices.

The existing XUA profile fills the
se

needs for the SOA
P transport
based
transactions.

The existing EUA profile fills these needs for
various different transports within a single enterprise environment
, including RESTful transports
.
The existing BPPC
profile
fills the need for documenting agreed disclosure re
lationships
. Other
155

future profiles may deal with documenting other consent related agreements.

T
his profile
is
related to BPPC and other consent documentation profiles by providing a mechanism to
implement those agreements over HTTP transports
.

Greater in
tegration of this authorization with t
hird party authorization and consent
documentation profiles, such as those found in the IHE BPPC profile, are a future effort. This
160

profile starts with
just
the basic authorization activities.

BPPC documents the authorization process for providers. The BPPC documents are part of the
legal, regulatory, and workflow processes that
the
access control mechanisms

like
IUA

enforce.
Although t
he IUA transactions
help to
enforce

BPPC relationships
,

IUA

is not a substitute for
proper documentation

using BPPC
.
Profiling of specific interactions between the BPPC process
165

and this authorization profile is outside the scope of this profile. This profile
will support

those
efforts
, and rules

about g
rouping with BPPC may be

added later.

There will be administrative actions to link the agreements documented by BPPC with the
authorization services used by IUA. These are not specified by the IUA profile. If the user has
chosen XYZ for an authorization service, they will follo
w the XYZ procedures for adding an
170

authorized device

for IUA access
. The BPPC
document
will indicate that this patient has agreed
to have XYZ provide authorization services for the patient’s devices. The patient will work with
XYZ service to au
thorize a device. Services like Facebook and Google have
methods for
customers to add authorized devices, but they are not the same. These methods for adding and
removing devices are not within the scope of this profile. This profile covers the d
etails of how
175

individual transactions are authorized.

The
HTTP
RESTFul

transport
is being
used
by
many healthcare applications and smart devices
.
These share a common set of issues. A typical example is:



The patien
t has a tablet and installs an application onto that tablet.

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

7

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3



The application will need to retrieve and update health related data that is stored on a
180

resource server. It uses
HTTP REST
ful

transactions for both retrieve and update

because
HTTP support is i
ntegrated into the platform services
.



The patient already has an established relationship with an authorization service.



The patient wants to configure the application to have access to their data without
needing

the IT staff at the ap
plication vendor and resource vendor to set things up.

185

One common pattern is to interact directly with the application to communicate with the
authorization service. The application interacts with both p
atient and authorization service to
support the granting of an access token. The application then saves the access token, and uses it
to retrieve and update the health related data. Another common pattern is for the user to interact
independently with th
e authorization service and obtain a
token
.
This token is save
d

on the
190

device for later use.

The key issues here are:



Reliable and accurate authorization
decisions
, as part of an overall privacy protecting and
security environment.



Application developers want one common method for obtaining and u
sing these tokens,
195

not thousands.

They want a method that is built into the common platforms, not one that
must be added later, because it is difficult for end user oriented applications to modify the
platforms.



Resource servers want one common method for

receiving these tokens as part of HTTP
REST
ful

transactions, and one common method for processing these tokens.

(They will
200

settle for a small number of methods if they must.)



Users, patients and providers,
want to be in control
,
do
not
want to
depend on

support
staff
to set up the
their
devices

and applications
, and want to minimize the interference
from authorization requirements.

Similar issues arise with:

205



In

house application d
istribution

leads to authorization needs for

devices used within the
facility
.



The in

house IT staff want a common method to authorize use of in

house web
applications and access to in

house resources.



IT staff are more willing to run their own internal
authentication and authorization
210

servers, but want to use off the shelf software and
want

the option to outsource these
services. They are more likely to separate authentication from authorization

than end
user systems
. Authentication issues are closely
related to HR activities like hiring
and firing. Authorization issues are related to patient and work assignments. These
are controlled by different parts of the organization and have different process
215

dependencies.

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

8

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3



Efficient user workflow requires minim
izing

the number of times a
person

is
challenged for
authentication
by
interactive applications.



Providers and Specialists

have authorization needs

for dealing with other organizations
.



Providers and specialists need to deal with hundreds o
f resource services. A
provider
220

panel of 10,000 patients will
need
hundreds of
relationships with
different specialists,
labs, priors, and other providers.



The providers and specialists
struggle to
maintain hundreds of different a
uthentication
and authorization relationships

today
.
The
ir

IT
staff
struggle to
support at all these
different relationships. Neither wants
delays
or
problems
that
will impact

patient
225

care.



Efficient user workflow requires minimizing the number of times a person is
challenged for credentials for interactive applications.



Granting subset access to specialized provider. E.g., read access to cardiac info to
physical therapy organization, forbidding access to other data like reproducti
ve health
230

and addiction data.

There are also environmental assumptions
made by
this profile.

First, it is assumed that there will be
multiple access control engines working together
.

The IUA
activities are
one part of a federated
system
. I
UA

will work in conjunction with other access
control engines. For example, a glucose monitor may be authorized to have access to a patient’s
235

medical record. The
expectation is that this will mean access to all of the glucose related
information, which will include a variety of measurements and prescriptions. But, it is expected
that if the device requests information about
sexually transmitted disease
diagnos
is it will be
rejected.

Second, this profile is operating in an environment where access consents are managed by BPPC
240

or other mechanisms. I
UA

is not a substitute for documen
ting, establishing, and modifying these
legal agreements. It is
a

method

by which those agreements are enforced. For example, there
will
be a documented consent agreement between a patient and a provider that the provider will
provide

medical
records to
a healthcare proxy

that is identified and authorized by the patient.
BPPC is one way to document that agreement
.

245

Open Issues and Questions

<List
the
open issues/
questions that

nee
d to be addressed
.

These are particularly useful for
highlighting problematic issues and/or specifically soliciting
public comments.
>

Closed Issues


<List
the

closed issues/questio
ns with their resolutions
. These are particularly useful for
250

recording the rationale for closed issues to forestall unnecessary rehashing in the future and/or
to make it easier to identify whe
n a closed issue should be re
-
opened due to new information.
>

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

9

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3


IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

10

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

General Introduction

255

Update the following Appendices to the General Introduction as indicated below. Note that these
are not appendices to Volume 1.

Appendix A
-

Actor Sum
mary Definitions

Add the following actors
to the IHE
Technical Frameworks

General Introduction list of Actors
:

<Add any actor definitions for new actors defined specifically for this profile. These will be
260

added to the IHE TF General Introdu
ction list of A
ctors namespace.
>


Actor

Definition





Appendix B
-

Transaction Summary Definitions

Add the following transactions
to the IHE
Technical Frameworks

General Introduction
list of
Transactions
:

265

<Add any transaction definitions for new transactions defined
specifically for this profile. These
will be added to the IHE TF General Introduction
list of Transactions namespace.
>


Transaction

Definition





Glossary

Add the following glossary terms to the IHE Technical Frameworks General Introduction
270

Glossary:

<
Any glossary additions associated
with the profile draft go here.
>


Glossary Term

Definition





IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

11

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

Volume
1



Profiles

<
Copyright
Licenses
>

275

<
General copyright licenses and permissions are listed in the IHE Technical Frameworks
General Introduction
.
Add in
formation on any standards referenced in the profile that are not
alr
eady addressed in the

permission section.>

A
dd the following to the IHE Technical Frameworks General Introduction

Copyright section
:


280

<
Domain
-
specific additions
>

<
Some domains have specif
ic sections, added as subsections to Sections 1 or 2, in their
Technical Frameworks
.
These types of additions are allowed as long as they do not adjust the
overall numbering scheme which needs to remain consistent across domains
.
If there are such
addition
s, they should be included here.>

285


A
dd

to
Section …

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

12

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

<Reserve a
subsequent section number in the current domain Technical Framework Volume 1

(DOM
TF
-
1
)
.
Replace the letter “X” with that section heading number
.
This number should not
290

change when this supple
ment is added to the Final Text Technical Framework
.
In this manner,
references should be able to be maintained going forward.>

X <
Profile Name

(
A
cronym)
> Profile

<Provide an end
-
user friendly overview of what the Profile does for them
.

Keep it brief (a p
aragraph or two, up to a page). If extensive detail is needed, it should be
295

included in section X.4
-

Use Cases
.>

<
E
xplicitly state whether this is a Workflow, Transport, or Content Module (or combination)
profile.

See the IHE Technical Frameworks General I
ntroduction for definitions of these profile
types
.
The IHE Technical Frameworks General Introduction
is
published a
t
http://www.ihe.net/Technical_Framework/index.cfm
.

300

X.1
<Profile Acronym>
Actors
,
Transactions
, and Content Modules


Other Profile
RESTful Client
Authorization
Client
Other Profile
RESTful Server
Resource
Server
Authorization
Server
Authentication
Server
Other Transaction
Authorized RESTful
Transaction
Authorized RESTful
Transaction
(redirect)
Authenticate User
Obtain RESTful
Authorization


Figure X.1
-
1
:
IUA

Actor Diagram

305

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

13

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3


Table X.
1
-
1 lists the transactions for each actor directly involved in the
IUA

Profile.
To
claim
compliance with this Profile, an actor shall support all re
qu
ired transactions (labeled “R”) and
may support the optional t
ransactions
(
labeled “O”
)
.


310

Table X.1
-
1
:

IUA

Profile
-

Actors and Transactions

Actors

Transactions

Optionality

Reference

Auth
orization
Client

Authorized RESTful
Transaction

R

<Domain Acronym> TF
-
2: 3.Y1

Obtain RESTful
Authorization

O

<Domain Acronym> TF
-
2: 3.Y2

Authorized RESTful
Transaction (redirect)

O


Authorization
Service


Obtain RESTful
Authorization

R

<
Domain Acronym
> TF
-
2: 3.Y1

Resource
Service


Authorized RESTful
Transaction

R

<
Domain Acronym
> TF
-
2: 3.Y
3

Autho
rized RESTful
Transaction (redirect)

O

<
Domain Acronym
> TF
-
2: 3.Y
4

Integrated
Authorization
Service

Obtain RESTful
Authorization

R


Authorized
Device

Obtain RESTful
Authorization

R


Authoriz
ed RESTful
Transaction

R

<Domain Acronym> TF
-
2: 3.Y3


X.1.1

Actor Descriptions and
Actor
Profile
Requirements

Most requirements are docu
mented in Transactions (Volume 2) and Content Modules (Volume
3). This section documents any additional requirements on profile’s actors.

315

X.1.1.1
Authorization Client

The authorization client actor performs the network transactions and user interactions ne
eded to
obtain an authorization token and to attach that token to HTTP RESTful transactions so that
those transactions are known to be authorized.

This activity has three basic patterns:

320



The Authorized RESTful transaction


In this case the authorization t
oken has already
be
en obtained and is communicated as part of the HTTP RESTful transaction for some
other profile or service. This token indicates that the RESTful transaction
has been
IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

14

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

authorized for a particular kind of service and particular device by a
n authenticated
person.

325



The Obtain RESTful authorization


In this use, the authorization client interacts with an
Authorization service, Integrated Authorization Service, and Authentication Service as
needed to obtain a token that indicates RESTful transa
ctions for a particular kind of
service and device are authorized by a particular person. This will often
include various
interactions with the user for authentication purposes. Those interactions are outside the
330

scope of this profile, and may involve bi
ometric or other identification activities. The
resulting token is saved for later use by the authorization client and must be
protected.



The Authorized RESTful transaction (redirect)


This use combines the Authorized
RESTful transaction with a web
-
orien
ted user interaction to obtain authorization.
These
are used when the Authorization Client does not already have an authorization token and
335

will obtain the token as part of the RESTful
transaction

activity. This transaction usually
requires support for a

human interaction as part of the web browser interactions.

X.1.1.1
Authentication Service

The Authentication Service Actor interacts with the device or user to identify and authenticate
the device or user.

340

X.1.1.1
Authorization Service

The Authorization S
ervice uses the authenticated user identity and the requested RESTful service
URL to determine whether RESTful transactions are allowed. If they are allowed, the
authorization service provides a token indicating the user identity and RESTful service acces
s
that are permitted.

345

X.1.1.1
Resource Service

The Resource Service accepts a RESTful transaction with an authorization token attached. It
evaluates the authorization token to verify that this is an authorized transaction. It then allows
the transaction
to proceed, subject to other constraints that may also be in place.

A Resource Service may also support the re
-
direct transaction. If it does, then it will interact
350

with the Authorization Client, Authorization Server, Authentication Server, and Integrated

Authorization Servers as necessary to perform the combined action
s of first obtaining an
authorization token and then performing the RESTful transaction.

X.1.1.1
Integrated Authorization Service

This actor is a combination of the Authentication Service an
d Authorization Service that requires
355

the user to use this actor for both authentication and authorization. It cannot act as an isolated
service that uses a different actor for either authentication or authorization activity.


IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

15

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

X.1.1.1
Authorized Device

Th
e authorized device actor shall be configurable in some manner to provide the authorization
360

token to the device. This capability is not further specified. It can vary substantially depending
upon technical differences in the purpose and use of the device
.

Devices might not have any
authorization related user interface.

X.2
IUA

Actor

Options

none

365


X.3 <Profile Acronym>
Required
Actor

Groupings

The

IUA

actors
are expected to be grouped with other
client
actors that perform
RESTful

transactions. Grouping an Authorization Client with another actor means that this other actor
370

will perform the necessary transactions to obtain an
authorization

token and provide tha
t token as
part of the HTTP transaction to a
RESTful server. Th
at

RESTful server should be grouped with
the Resource Service actor to indicate that the server will perform access control using the
OAuth
information.

Any mandatory groupings will be identif
ied in other profiles.

375

X.
4

<Profile

Acronym
>
Overview

X.
4
.1 Concepts

The term “authorization” and “access control” are used
colloquially
for a variety of related
activities. This profile will use m
ore specific terms for each
of these activities
. These are:

380



Provisioning


Setting up the initial rules and updating them when the situation changes.
The administrator may say “Authorize Dr. X to have access”. The steps taken to make
this happen are cal
led provisioning.



Delegation


Adding, transferring and revoking authorization from one person to another.
This is closely related to provisioning. It differs in that it can only transfer authority th
at
385

has already been provisioned, and it may track chan
ges to provisioned access for the
original person.



Authentication


Determining that the actual user (at the moment of authentication) is a
known identity.



Authorization


Determining that the authenticated user is authorized to have access to a
390

resource (
at the moment of authorization).


The profile describes how to convey an
access authorization decision. It is not defining how the decision is made.

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

16

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3



Access Control


A

system of provisioning, delegation, authentication, and authorization.
It is normal t
o have multiple nested levels of access control. The IAuth profile is
concerned with

access control at

the HTTP level. There are likely also building access
395

controls, resource server access controls, and other access controls involved.

X.4.1.1
Concept ex
amples

These concepts are explained here in terms of physical access controls.

Example 1
Facility Access Control experience

John Doe goes to the guard gate at a secured facility. The guard
400

hands John Doe his photo ID badge and opens the gate to let him
in
to the facility.

A number of things have happened to make this work.



Provisioning of Identity



Provisioning

of Access Rights and Credentials
A lot of policy, regulation, and
405

administration took place in the past.



Administration determined that it was OK fo
r John Doe to have access. (This kind of
activity will be out of scope for IAuth, but it is a necessary pre
-
requisite.)



John Doe had his picture taken and a photo ID was prepared.



The photo ID was provided to the guard gate.

410



Authentication


The guard at t
he gate is using human visual identification matching the person in front of
them with the ID badge requested. This is the authentication of John Doe.



Authorization

The presence of the photo ID was the provisioning for this authorization. This is input t
o
415

the guard’s actions. Based on this,



Opening the gate and handing the photo ID is both performing authorization and
providing an authorization and authentication token.



The guard logs the ID and time of entry as part of the security logs.

John Doe procee
ds inside the facility and goes to work.

420

Example 2

Multiple Levels of
Access Control
, and Classes of
documents.

John Doe goes to the files clerk and asks for files on
a patient’s
diabetes and psychiatric records
. The clerk
checks and finds that
John Doe is only
allowed to access diabetes related records
. The
425

clerk provides
the diabetes records
. The clerk silently logs the
IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

17

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

security violation that John Doe asked
for
the patient’s psychiatric
records
.

This is a subordinate access control activity from the perspective of facility access control. The
facility controls are separated from the
document
controls. The subordinate access control

can
430

act independently from facility controls, merely making the assumption that all people who reach
the file clerk are authorized to be present in the facility
.
T
he subordinate access control decisions
are independent of the facilit
y access decisions.

This
separates the overall facility access
decision from the document access decision.

This example also illustrates the use of document classes. The decision on document access is
435

not made by having a separate complete access control

rule for each individual document.
Instead, documents are organized into classes, like the
“diabetes related” class. These classes
will overlap, “blood lab results” and “diabetes related” are intersecting classes. Some blood tests
will be diabetes rela
ted and others will not.

Most consent and management of authorization is done at the level of document class level. It is
440

during the actual retrievals that the retrieval service decides which documents are permitted.

This decision is delegated by the aut
horization service to the retrieval service. (In the example
above, it is the file clerk that is selecting the documents that are permitted.)

The example above has an integrated authentication and authorization actor, the facility guard.
This is a common

configuration for software systems as well. But it is also possible to have
445

separate
systems.

Example 3

Independent Authentication system

The facility installs a biometric ID capability, and gives John Doe
permanent possession of his photo ID badge. In
order to gain
access he performs a biometric ID procedure at the guard gate and
450

the gates open automatically. The guards merely assure that John
Doe is following procedures.

This example has separated authentication and authorization:



Authentication

The b
iometric ID system is authenticating that the person is the John Doe that was
455

provisioned. It communicates this authentication to the gate controls.



Authorization

The automatic gate system is accepting the authentication from the ID system and
opening the

gate to allow John Doe to enter the facility.

The motivation for this separation is the ability to obtain the ID system for authenticating people
460

from a vendor that specializes in authenticating people, and to obtain the authorizing gate
controls from a v
endor that specializes in gate controls.

All of these facility access controls have direct analogues in the Internet HTTP access world.

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

18

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

X.4.1.2
Intended Uses


Healthcare uses include various forms of delegation.
One well defined and delimited use case is:

465



There is the special case of intelligent healthcare devices and applications. These cannot
use the same provisioning process as people. The patient may want the ability to
provision devices and applications without involving the healthcare providers’
ad
ministrations. They purchased the application and want the ability to delegate a limited
level of access to the application.

470

The following kinds of delegation are too complex to
fully solve

with this profile.

This profile
will provide a facility that fac
ilitates these activities.



Assigning a healthcare proxy for a patient. In this case the patient delegates a nearly
complete copy of their access rights to the healthcare proxy.
For example, a patient may
make a visiting nurse a healthcare proxy. The nur
se may have access to records before a
475

visit, help fill in forms

during a visit
, and update records after a visit.
The patient cannot
delegate more rights than they have, but changes to those rights automatically transfer to
the proxy.



The proxy must usua
lly be provisioned by the access control administration. The
patient does not have the ability to provision strangers or delegate to strangers. The
480

patient can delegate to other people that are known to the administration.



The proxy will go through authe
ntication and authorization process
es that identify
both the proxy’
s real identity and their actions in the role of proxy

for an authorized
person
.



There are often limited access proxies. These go through the same kind of provisioning,
485

authentication, and

authorization processes, but their access is identified as limited to
certain purposes. For example, a

secretarial

proxy might be granted access to scheduling
information only. The limited access might affect both the IAuth access level and lower
levels

of access control.

Delegation to intelligent healthcare devices and applications can be facilitated by IAuth,
490

although there are likely to be provisioning pre
-
requisites that must be established. These pre
-
requisites are outside the scope of
O
Auth.

X.4.
2 Use Cases

Intermediate level needed to show how business cases above map onto these detailed
transactions and actors below. Audience are app developers who have just encountered
495

healthcare.

Assume they have heard of OAuth
and will recognize names that s
how up in the
detailed use cases.

Need to show how “authorize
patient’s application

to access lab results”
above turns into transactions below.

There is one primary use case for authorization for access to a resource, which takes four
different common vari
ations. There is also one delegation use case that is perhaps in scope for
500

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

19

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

this profile. The
re are

other use cases for delegation, provisioning, etc.
that
are out of scope for
this profile.

The primary use case is that a user desires access to a resource

using HTTP mechanisms. The
user might be a patient, a provider, a machine, a software application, or some other kind of
participant.

505

The authorization service is provided by a different organization than the resource service. This
need is driven by the

requirements of patients and others to simplify and maintain autonomy and
control over authorization services. A patient may interact with dozens of providers. It is
difficult for the patient to coordinate different authorization mechanisms with each of

these
dozens of providers.

510

In other kinds of Internet usage there are vendors of authorization services that are used to solve
this problem. These include Facebook, Google, and a variety of other service providers from
different commercial and governme
ntal sectors.

These overlap with providers of authentication
services. For both authentication and authorization these services allow a patient to establish an
authentication and authorization system with minimal provisioning by the healthcare provider.

515

The patient can specify “use vendor X”.

The pre
-
requisites for these use cases are:



The User has established a relationship with the Authentication and Authorization
services.



The resource service has agreed to use the same Authentication and Authorizatio
n
520

services. This is often much easier than establishing and maintaining their own patient
facing authentication and authorization services. The agreement to use an external
service is a significant policy choice, because it is accepting some shared respo
nsibility
for choosing suitable authentication and authorization services. The user shares part of
this decision responsibility, but local laws and regulations will affect a resource servicer’s
525

decision to accept and use a third party authorization and au
thentication service.



The authentication and authorization services have agreed to be used by the User and
resource service provider.

This may be for a fee, or in return for other considerations.

X.
4
.2
.1

Simple Authorization

A provider with a mobile devic
e wishes to retrieve a medical document to which they have
530

authorized access.

X.
4
.2.1
.1

Simple Authorization Use Case

In this use case, the authentication and authorization services are separate services. The User
communicates first with the authenticatio
n and authorization services to obtain a token that will
be presented to the resource service. This token will be used as part of an access control decision
535

by the resource service.

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

20

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

The User could be any kind of participant, and the resource use could be
either retrieval or
storage of a resource by means of HTTP transactions.

X
.
4
.
2
.
1.
2
Simple Authorization

Flow


540

Figure X.
4
.
2
.
2
-
1
:

Basic Process Flow in <Profile
Acronym
> Profile

Pre
-
conditions
:

The provider is in physical possession of a mobile device, runn
ing application A, and wishes to
use application A to obtain a medical document using HTTP
-
based transactions from server S.
545

They are constrained to use authentication
and authorization
servers identified by their employer.

Main Flow:

1.

The user provides us
er authentication and the intended resource request information to
the authentication server.

2.

The authentication server generates a token A that indicates that this user is authorized to
550

have access to this resource.

3.

The user

provides user authentication

t
oken A

and the intended resource request
information to the authorization server.

4.

The authorization server generates a token
B
that indicates that this user is authorized to
have access to this resource.

555

5.

The device sends a resource request to the resource
server, together with the authorization
token

B
.

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

21

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

6.

The
resource
service provider makes an access control decision based upon the user
identity, authorization token

B
, and resource requested. It may provide the resource, a
subset of the resource, or reject t
he request.

560

Post
-
conditions:

The device either receives the resource requested, a modified resource, or a rejection based upon
the access decision of the
resource server.

X.4.2.1
Simple

Integrated Use

The situation is the same as Simple Use, but in this ca
se the Authentication and Authorization
565

are provided by a single integrated service.

X.4.2.1.2
Simple Integrated Use

Flow

The t
ransactions for authorization are the similar, but the authentication transactions are
different
.


The differences are in the l
ikely relationships among the participating actors.


570


Main Flow:

1.

The user requests user authorization and the intended resource request information to the
integrated server.

2.

The integrated server queries the user to establish and authenticate their identi
ty.

575

3.

The user provides the appropriate reply information to the integrated server.

4.

The authorization server generates a token B that indicates that this user is authorized to
have access to this resource.

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

22

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

5.

The device sends a resource request to the resource
server, together with the authorization
token B.

580

6.

The resource service provider makes an access control decision based upon the user
identity, authorization token B, and resource requested. It may provide the resource, a
subset of the resource, or reject t
he request.


X.4.2.1
Redirect Based Separate Service

585

The service provision is like the simple use case above, but the request process is different. In
this case the user has not established authentication or authorization in advance. The three
service pr
oviders use a re
-
direct mechanism to obtain the necessary authentication and
authorization as part of the resource request process.

X.4.2.3.1 Redirect Based Separate Service Workflow

590


IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

23

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3


Main Flow:

1.

The user requests the resource from the resource server.

2.

Th
e resource server
notes the absence of token B, and re
-
directs the User agent to the
595

Authorization service.

3.

The User agent requests the resource from the authorization server.

4.

The Authorization server notes the absence of token A, and re
-
directs the User a
gent to
the Authentication service.

5.

The User agent requests the resource from the authentication service.

600

6.

The Authentication service establishes the user identity and authenticates the user.

7.

The
Authentication service provides token A, and re
-
directs the U
ser agent back to the
Authorization service
.

8.

The authorization server generates a token B that indicates that this user is authorized to
have access to this resource.

605

9.

The device sends a resource request to the resource server, together with the authorizati
on
token B.

10.

The resource service provider makes an access control decision based upon the user
identity, authorization token B, and resource requested. It may provide the resource, a
subset of the resource, or reject the request.

610

This kind of re
-
direction

support is a common feature in browsers and similar user agents. It has
a greater transactional complexity, but avoids needing to perform authentication and
authorization transactions in advance in the proper sequence.

X.4.2.1
Redirect Based Separate Ser
vice

The service provision is like the simple use case above, but the request process is different. In
615

this case the user has not established authentication or authorization in advance. The three
service providers use a re
-
direct mechanism to obtain the
necessary authentication and
authorization as part of the resource request process.

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

24

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

X.4.2.3.1 Redirect Based Integrated Service Workflow


620


Main Flow:

1.

The user requests the resource from the resource server.

2.

The resource server notes the absence of token B
, and re
-
directs the User agent to the
Integrated service.

625

3.

The User agent requests the resource from the Integrated server.

4.

The Integrated service establishes the user identity and authenticates the user.

5.

The Integrated server generates a token B that indi
cates that this user is authorized to
have access to this resource.

6.

The device sends a resource request to the resource server, together with the authorization
630

token B.

7.

The resource service provider makes an access control decision based upon the user
iden
tity, authorization token B, and resource requested. It may provide the resource, a
subset of the resource, or reject the request.

The Integrated services provide a simpler flow with fewer transactions for the situations where
635

there is a user agent that s
upports re
-
direction and the user is unwilling to obtain tokens in
advance.

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

25

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

X.4.2.1
Machine
Delegation

X.4.2.1.1
Delegation

Use Case Description

There are three sig
nificant and common reasons to
perform delegations. These cases are
640

primarily patient dele
gation choices. Providers rarely have the authority to delegate. The
alternative and backup providers are directly authorized to have access by the providing
organization.

Patients will delegate authority to:



Device or applications that are performing a
service for the patient, for example
645

automatic glucose monitors that can provide monitoring records and receive control
information from a healthcare provider service that is providing diabetic care.



Applications that are distributed across multiple device
s, multiple instantiations. E.g.,
Kindle device
s synchronize last read location, documents available, etc. across multiple
Kindle devices for a single user account
.

650



Advocates and proxies who are authorized by the patient to make decisions for the
patient.



Organizations that are acting for the patient, such as a visiting nurse organization that is
providing support to the patient.

Revocation needs to be clearly specified as well. Revocation may be merely removal of rights
655

because of swapping devices. Expi
ration, re
-
authorization, etc. need to be covered.
Revocation
is not just

a response to breaches and
failures. Revocation is a normal response to changes in
people, equipment, and relationships.

Only the first use case is considered in scope for the IAut
h profile. The multiple device
synchronization, human advocates, and organizational relationships involve a great many rules,
660

regulation, policies, and procedural variations. These are all outside the reasonable scope of an
IHE profile. These local poli
cies and procedures might take advantage of IAuth for part of the
policy or procedure.

X.4.2.1.2
Delegation to a Device or Application

Process Flow

Pre
-
conditions:

665

The device has a secure mechanism to save Token B for later re
-
use.

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

26

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3


Main Flow:

1.

The user
provides user authentication and the intended resource request information to
the authentication server.

670

2.

The authentication server generates a token A that indicates that this user is authorized to
have access to this resource.

3.

The user provides user authe
ntication token A and the intended resource request
information to the authorization server.

4.

The authorization server generates a token B that indicates that this user is authorized to
675

have access to this resource.

5.

The device sends a resource request to th
e resource server, together with the authorization
token B.

6.

The user provides the Token B to the device. The mechanism for this is not part of this
profile. It will depend upon the nature of the device or software application.

680

7.

The device stores Token B
, and uses Token B whenever it needs to make a resource
request of the resource service.

8.

The resource service provider makes an access control decision based upon the user
identity, authorization token B, and resource requested. It may provide the resourc
e, a
subset of the resource, or reject the request.

685

Post
-
conditions:

<Very briefly (typically one sentence) describe the state of the clinical scenario after this content
module has been created including examples of potential next steps.>


IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

27

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

X.
5

<Profile

Ac
ronym
> Security Considerations

690

<Describe Profile
-
specific security considerations. This should include the outcomes of a risk
assessment. This likely will include profile groupings, and residual risks that need to be assigned
to the product design, system
administration, or policy.

See
the ITI document titled ‘Cookbook:
Preparing the IHE Profile Security Section’ at
http://www.ihe.net/Technical_Framework/index.cfm

for
suggestions on risk assessment, risk
695

mitigation, and IT and security profiles.
>

<
If this i
s not a content module, delete the sentence below
.
If this is a content module profile, you
may want to expound upon the security considerations provided by grouped actors.>


The security considerations for a content module are dependent upon the security
provisions
defined by the grouped actor
(s).

700

X.
6

<Profile Acronym>
Cross
Profile
Considerations

none

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

28

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

Appendices


<
Add Appendices to this Profile here
.
Examples of an appendix include HITSP mapping to IHE
Use Cases or long use case definitions.
>

705

<
Volume 1
A
ppendices are informational only
.
No “
SHALL
” language is allowed in a

Volume 1
appendix.>


Appendix A


Standards Evaluation and Tradeoffs

Standards under consideration:

710



OAuth 1.x



These are a predecessor to the OAuth 2.0 framework, documented in

various

RFCs.

They have widespread use experience. This showed that there inter
-
operability
problems between different services, but that when a single authorization service was
used it worked on many different user platforms for many different applicati
ons. The
interoperability problem meant that an application would specify that it supported
715

“vendor


Oauth 1.x”. There could be several vendors on the list supported, but adding a
new authorization vendor usually meant changing code.


Removed from con
sideration. There were no reasons identified to disagree with the
OAuth community choice to move to OAuth 2.0. There is not a significant installed
720

base within healthcare that would benefit from preserving OAuth
1.x use. There is
not a functional argume
nt for OAuth 1.x.


These profiles were also strongly tied to user interactions involving use of a browser.


725

These restrictions lead to the development of OAuth 2.0. It was written as a framework,
rather than a single standard, so that it can be adapted to

different uses.


OAuth 1.x is specifically for HTTP transactions.



OAuth 2.0



This is documented in RFC
-
6749.

It defines a framework, where many
730

details of things like codes must be separately specified. Multiple vendors have working
implementations.

Profiles are being developed. Some may be single vendor profiles,
leaving the interoperability situation unchanged. Others may be multi
-
vendor profiles for
better interoperability.


735

OAuth 2.0 is specifically for HTTP transactions.



EUA



This is
an IHE p
rofile based on

Kerberos. It has been robust and is widely used in
enterprise environments. It depends upon the ability to exchange shared secrets between
servers using unspecified administrative paths. This is easy when the servers are all
IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

29

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

under contro
l of a single enterprise. It has been used in cross enterprise environments
740

and is robust, but it has not been popular.

The administrative issues are probably the
reason it has not been popular.


EUA has bindings to multiple different protocols including

HTTP.



HTTP Password



This has been available for a long time, and is in use. It suffers from
745

the usual issues with username
-
password systems. It has not been popular.


Removed from
consideration
. HTTP Password

has not been popular, and simple
password
based approaches like this have significant administrative problems.

The
failure to reach acceptance despite years of availability indicate that this will not be
750

a
cceptable.



HTTP SAML



This has been available for a long time and is in use. It has not be
en
popular with consumer devices.



LDAP Authentication



This is very similar to EUA, and differs primarily in
administrative details. An EUA compliant device can usually be configured to use LDAP
755

Authentication.



Attribute Certificates



This is not an a
lternative transaction standard, but introduces
considerations that may affect the standard selection and profiling plans.
HTTP headers
can be defined to include any kind of certificate.
The HTTP SAML, the Browser SSO,
and OAuth 2.0 all have some flexibil
ity in this regard.
Attribute certificates are a kind of
760

certificate defined by RFC 3281
.

SAML Browser SSO
can

co
-
exist with OAuth 2.0.
The
OAuth emphasis has been much stronger in the consumer markets, and the Browser SSO
has been stronger in the business to business
markets.
Possiblities include
:

1.

Generate a XUA update
to incorporate defined use of attribute certificates
independently of this profile
.

765

2.

Use attribute certs as part of the token selection for a medical OAuth 2.0.

3.

Do both 1) and 2) as coordinated efforts in two separate work items for
ITI.

<< Initially a matrix of alternatives and considerations>>

Criterion/Re
quirement

OAuth 1.x

(
removed)

OAuth 2.0

EUA (HTTP
-
Kerberos)

HTTP
Password

(removed)

HTTP
SAML

LDAP
Authenti
cation

Attribute
Certs.

Mindshare of
Application
Developers

In use, but

considered
flawed with
interoperability
limitations.

Very high
current
mindshare.
More consumer
and small
business
friendly.

It’s old. It is not
widely accepted
for cross
-
enterprise.

Considered
too
simplistic.

Not
recognized
as
consumer
oriented.
Usuall
y
B2B.

Enterprises
often
uncomforta
ble
exposing it
for authN
and authZ.
(Overlaps
with EUA)


Backwards
Interoperability
Not directly
Nil

Nil

Nil

Nil


IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

30

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

Criterion/Re
quirement

OAuth 1.x

(
removed)

OAuth 2.0

EUA (HTTP
-
Kerberos)

HTTP
Password

(removed)

HTTP
SAML

LDAP
Authenti
cation

Attribute
Certs.

compatibility
with OAuth 1.x
(Installed base
consideration).

issues are
experienced.

compatible.

Delegat
ion to
Application

Non
-
standard
extension

Within
framework

Complex
provisioning

Nil

Complex
provisionin
g

Complex
Provisionin
g


Delegation to
3
rd

Human

Weak

Within
framework

Nil

Nil

Complex
provisionin
g

Nil


Delegation to
3
rd

Organization

Weak

Within
fram
ework

Complex
provisioning

Nil

Complex
provisionin
g

Nil


Multiple
identity
providers

Nil

Within
framework,
uncommon

Nil

n/a

Nil

Nil


Multiple
authorization
providers

Weak
Interoperability

Within
framework,
prime goal

Nil

n/a

Nil

Nil


Identity
provider n
eed
not be the
Authorization
provider

Nil

Within
framework

Complex
provisioning

n/a

Complex
provisionin
g

Nil


HTTP(x)
interface
specified

Yes

Yes

Yes

Yes

Yes

No


Platform
support in
common
platforms (iOS,
Android)

Yes

Yes

No

No

No

No


Sharable
certifica
te store

n/a

n/a

n/a

n/a

n/a

n/a


Sessions

Unspecified

Within
framework

Yes

Unspecified

Unspecifie
d

n/a


Revocable
Delegation

Nil

Within
framework,
uncommon

Yes

n/a

n/a

n/a


Short
-
term
Delegation
(hours)

Nil

Within
framework,
uncommon

Yes

n/a

n/a

n/a


Long
-
term
Delegation
(weeks
-
months)

Nil

Within
framework,
uncommon

Yes

n/a

n/a

n/a


Bi
-
directional
TLS
Authentication
Nil

Within
framework,
serious
implementation
Yes

Yes

Yes

n/a


IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

31

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

Criterion/Re
quirement

OAuth 1.x

(
removed)

OAuth 2.0

EUA (HTTP
-
Kerberos)

HTTP
Password

(removed)

HTTP
SAML

LDAP
Authenti
cation

Attribute
Certs.

of Node

issue.

Uni
-
directional
TLS
Authentication
of Server Node

Yes

Withi
n
framework,
implementation
issue

Yes

Yes

Yes

Yes


Multiple kinds
of authorization
over one
connection?
Require
resource per
kind of
authorization.

No

Within
framework,
uncommon

Yes

No

No

n/a



Authorization
for classes of
documents.

?

Within
framework,

must be
profiled

No

No

Yes

No


Support of
policy
expressiveness
in the token

?

Within
framework,
must be
profiled

No

No

Yes

No


Indication of
LOA used as
part of
transaction.








Expiration
mechanism









Description of Criterion for evaluation

770



Mindshare of Application Developers

This criterion reflects the readiness of the mobile device platforms for the chosen
technology
. Application developers prefer to minimize the number of dependencies
that they have beyond the basic platform. It also ref
lects the adoption by major
non
-
healthcare Internet players like Google, Facebook, etc. The ideal for
775

mindshare is something that is already part of the basic platform for IOS, Android,
and is used by Google, Facebook, and others.



Backwards compatibility
with OAuth 1.x (Installed base consideration).



Delegation to Application

An un
-
attended application must be able to be given authorization to gain access to
780

healthcare data. Automatic applications like glucose monitors will not be usable if
a
patient

inte
raction is needed whenever data is to be transferred.

The patient needs
to be able to set up the device and forget about it.

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

32

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3



Delegation to 3rd Human

A patient needs to be able to delegate authorization to another person. This might
785

be for purposes of a h
ealthcare proxy while the patient is unable to make decisions.
It might be so that an advisor can obtain information.



Delegation to 3rd Organization

A patient needs to be able to delegate authorization to an organization. This might
be so that a doctor h
as access to records, or a visiting nurse organization has access
790

t
o records.



Support
Multiple identity providers

A provider will sometimes need to be able to accept identities from multiple
identity providers. A patient will sometimes need to have iden
tities that are
managed

by multiple identity providers.

795



Support
Multiple authorization providers

A provider will sometimes need to be able to accept authorizations from multiple
authorization

providers. A patient will sometimes need to
deal with
multiple

authorization

providers.



Identity provider need not be the Authorization provider

800

The identity provider will sometimes be the same as the authorization provider. In
these cases, authorization and identification are often combined into a single
simplifie
d
set of transactions.

In other cases, the identity provider and authorization
provider will be separate servers. This separate case is presently more common in
the enterprise environments, where the identity provision is related to HR functions
805

and the
authorization is related to the persons current work assignments. The
selected approach must work for both environments.



HTTP(x) interface specified

This service must use HTTP framing (e.g., HTTP headers) only. It may also
require use of protective secur
ity layers like TLS, but
must
not require modification
810

of those layers.

It may use other protocol layers for ancillary services, but mobile
devices cannot be expected to provide those as platform services. Such use is a
definite negative.



Platform suppor
t in common platforms (iOS, Android)

The selected standards must be able to be used on the common platforms of IOS,
815

Android, Windows, MacOS, and Linux.



Sharable certificate store

The selected standards should not interfere with use of shared certificate st
ores.
Some platforms enable shared storage of certificates and other security related
tokens. The standards should not prevent use of shared stores.

820

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

33

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3



Sessions

Many healthcare applications need to perform multiple HTTP transactions as part of
basic functio
n. The selected standard should not require a full re
-
authorization for
every HTTP transaction. Some sort of token or session mechanism will be needed
for performance reasons.

825



Revocable Delegation

The authorization delegations to devices, people, and org
anizations must be
revocable. A revision method is not as critical, since revision can be done as a
revocation and new authorization. The revocation must not require access to the
device, since devices can be lost and stolen.

830



Short
-
term Delegation (hours
)

Some delegations are known to be needed for only a short time. There should be a
way to authorized for only a limited number of hours.



Long
-
term Delegation (weeks
-
months)

Some delegations are known to be needed for a long time. There should be a way
835

to

authorize for a long period. E.g., a blood pressure monitor should be able to be
authorized to report blood pressure for months or years.



Bi
-
directional TLS Authentication of Node

Some uses, e.g., physician in
-
house tablet, need full bi
-
directional authe
ntication of
t
he device. This should be supported.

840



Uni
-
directional TLS Authentication of Server Node

It will not always be practical to fully authenticate each patient device. The
authentication service must not force such authentication. It is

allowed

to permit
authentication of the server side

only
.



Multiple kinds of authorization over one connection? Require resource per kind of
845

authorization
?

Access to s
ome
kinds of
healthcare data

requires multiple authorizations.

Mechanisms that support this are

acceptable but not required. These situations are
not common in the mobile environment.





Authorization for classes of documents.

850

Authorizations need to be available for a class of resources or documents. These
classes will be defined by policy and agre
ement. For example, a doctor reviewing
diabetic care should be able to retrieve all r
elevant documents based upon a single
authorization, rather than require re
-
authorization for each individual document and
resource.

855



Support of policy expressiveness in t
he token

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

34

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

The authorization token may have the ability to include significant self
-
description.
For example, it may be able to include a string saying
“Authorization based on
BPPC document with UID x.y.z”.



Indication of
level of assurance (
LOA
)

used as p
art of transaction.

860

The authorization
token may indicate a LOA that was performed in generating the
token. The server may specify a desired LOA for the tokens that it will accept.


A.1

<Add Title>

Appendix A.1 text goes here

865

Appendix B


<Appendix B Title>

There are many sections of the OAuth 2.0 framework that require a profile to specify lists, codes,
etc. The following table identifies these:















870

B.1

<Add Title>

Appendix B.1
text
goes here.

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

35

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

Volume 2


Transactions

Add sec
tion 3.Y

3
.Y <Transaction Name

[
Domain Acronym
-
#
]
>

875

<The “Y” in the heading should be the same as the # in the [
Domain Acronym

-
#] title>

3
.Y.1 Scope

This transaction is used to
<…describe what is accomplished by using the transaction.

Remember that by kee
ping transactions general/abstract, they can be re
-
used in a variety of
profiles>

880

3
.Y.2

Actor
Roles

<Optional
:
if desired,
in addition to the table,
add a diagram as shown below to illustrate the
actors included in this transaction, or delete the diagram a
ltogether.>


Figure 3.Y.2
-
1:
Use Case Diagram

885


Table 3.Y.2
-
1: Actor Role
s

Actor:

<Official actor name; list every actor in this transaction.>

Role:

<Very brief, one phrase, description of the role that this actor plays in this
transaction
.
>

Actor:


Role:



Actor:



Role:


<
The assignment and use of Role Names in transaction specifications has proved to be very
effective/efficient in Radiology
, especially when existing transactions are re
-
used by additional
Transaction Name
[DOM
-
#]


Transaction Name
[DOM
-
#]

Actor ABC


Actor ABC

Actor DEF


Actor DEF

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

36

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

actors.

Following

is an
alternative example of the Role
section. Delete
which ever form of the
890

role section you choose not to use
.
>


The Roles in this transaction are defined in the following table and may be played by the actors
shown here:

Table 3.Y.2
-
1 Actor Roles

895

Role:

<Role Name:><Only unique within this transaction. Typically one word. The
Role Name is analogous to SCU or SCP in DICOM Services.>

Actor(s):

The following actors may play the role of
<Role Name>
:



<Actor Name>: <optionally, the situation where the

Actor would play
this Role if needed for clarity.>


Role:

<e.g., Requestor:

Submits the relevant details and requests the creation of a new
workitem.>

Actor(s):

<e.g., The following actors may play the role of Requestor:

Workitem Creator: when requestin
g workitems

Workitem Performer: when performing unscheduled workitems>

Role:

<e.g., Manager:

Creates and manages a Unified Procedure Step instance for the
requested

workitem.>

Actor(s):

<e.g., The following actors may play the role of Manager:

Workitem M
anager: when receiving a new workitem for its worklist.>

Transaction text specifies behavior for each Role. The behavior of specific Actors may also be
specified when it goes beyond that of the general Role.

3
.Y.3 Referenced Standard
s

<e.g., HL7 2.3.1 Cha
pters 2, 3>

<e.g.
,

DICOM 2008 PS 3.3: A.35.8 X
-
Ray Radiation Dose SR IOD>

900

3
.Y.4 Interaction Diagram

<T
he interaction diagram shows the detailed standards
-
based message exchange that makes up
the IHE transaction
.
>

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

37

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3


3
.Y.4.1 <
Messa
ge

1

Name>

905

<One or two sentence summary of what Message 1 accomplishes typically relating the message
to the relevant standard. Avoid shall language in this upper level section
.
Do not duplicate the
triggers, encoding, semantics, standards used, or expecte
d actions
.
Those belong in the following
sections.>

<Explicitly state if the multiplicity of an actor may be greater than one; i.e., if an actor (whether
910

it is a client or server) can expect this message from a single source or multiple sources.>

3
.Y.4.1.1

Trigger Events

<Description of the real world events that cause the sender (Actor A) to send Message
1 (e.g., an

operator or an automated function determines that a new workitem is needed
).
>

3
.Y.4.1.2 Message Semantics

915

<D
etailed description of the meaning
, structure

and contents
of
the m
essage, including

any IHE
specific clarifications of the message format, attributes, etc.>

<Start by describing the standard underlying the message and how the participating actors are
mapped

(e.g., “This

message is a DICOM

C
-
FIND Request
.
Actor A is the SCU
.
Actor D is the
SCP.

)
.
>

920

<Continue profiling the message by providing guidance or constraints on how the message
parameters are populated, how the payload is encoded, how the message is structured and what
the contents m
ean
.
These message semantics should both help the sender to construct the
message and the receiver to interpret the message.>

A
ctor A


A
ctor A

Message
1


Message
1

A
ctor D


A
ctor D

Message
2


Message
2

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

38

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

3
.Y.4.1.3 Expected Actions

925

<D
escription of the actions expected
to be taken as a result of sending or receiving
this
message
.
>

<De
scribe what the receiver is expected/required to do upon receiving this message. >

<Avoid re
-
iterating the transaction sequencing specified in the Profile Process Flows as
expected actions internal to the transaction
.
Doing so prevents this transaction bei
ng re
-
used in
930

other contexts.>

<Explicitly define any expected action based on the multiplicity of an actor(s), if applicable.>

3
.Y.4.2

<Message
2

Name>

<One or two sentence summary of what Message 2 accomplishes typically relating the message
to the relev
ant standard. Avoid shall language in this upper level section
.
Do not duplicate the
935

triggers, encoding, semantics, standards used, or expected actions
.
Those belong in the following
sections.>

<Explicitly state if the multiplicity of an actor may be great
er than one; i.e., if an actor (whether
it is a client or server) can expect this message from a single source or multiple sources.>

<
R
epeat this section as necessary based on the number of messages in the interaction diagram
.
>

940

3.Y.4.
2
.1 Trigger Events

<De
scription of the real world events that cause the sender (Actor A) to send Message 1
(e.g., an

operator or an automated function determines that a new workitem is needed
)
.>

3
.Y.4.2
.2 Message Semantics

<Detailed description of the meaning, structure and cont
ents of
the message
, including

any IHE
945

specific clarifications of the message format, attributes, etc.>

<Start by describing the standard underlying the message and how the participating actors are
mappe
d (e.g.,

T
his message is a DICOM C
-
FIND Request
.
Act
or A is the SCU
.
Actor D is the
SCP
.

)
.
>

<Continue profiling the message by providing guidance or constraints on how the message
950

parameters are populated, how the payload is encoded, how the message is structured and what
the contents mean
.
These message s
emantics should both help the sender to construct the
message and the receiver to interpret the message.>

3
.Y.4.2
.3 Expected Actions

<Description of the actions expected to be taken as a result of sending or receiving this
955

message.>

<Describe what the rece
iver is expected/required to do upon receiving this message. >

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

39

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

<Avoid re
-
iterating the transaction sequencing specified in the Profile Process Flows as
expected actions internal to the transaction
.
Doing so prevents this transaction being re
-
used in
other
contexts.>

960

<Explicitly define any expected action based on the multiplicity of an actor(s), if applicable.>

3.Y.
5

Security Considerations

<
D
escription of the transaction specific security consideratio
n
; s
uch as use of security profiles
.
>

3.Y.5.1 Security A
udit Considerations

<
This section should
identify

any specific ATNA security audit event that is associated with this
965

transaction and requirements on the encoding of that
audit event.

>

3.Y.5.1.(z)
<
Actor
>

Specific Security Considerations

<This section sho
uld
specify

any specific security considerations on an Actor by Actor basis.>

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

40

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

Appendices


<Detailed cross transaction relationships or mapping details are described in an appendix in
970

Volume 2x. Volume 2 appendices may be informational or normative. Immedia
tely after the title
of a Volume 2 appendix, provide a very explicit statement defining whether this new appendix is
informative or normative.>


Appendix A


<Appendix A Title>

975

Appendix A text goes here.

C.1

<Add Title>

Appendix A.1 text goes here

Appendix B


<Appendix B Title>

Appendix B text goes here.

980

B.1

<Add Title>

Appendix B.1 text goes here.


Volume 2
Name
s
pace Additions

Add the following terms
to the IHE
General Introduction Appendix G
:

985

<Please

explicitly

identify all
new
OIDs, UIDs, URNs,

etc.,
defined
specifically for this profile.

These will be added to the IHE TF General Introduction namespace

appendix when it becomes
available
.
These items should be
collected
from the
sections
above
,

and
listed here as additions
when this document is published for Tr
ial Implementation
.
This section will be deleted prior to
inclusion into the Technical Framework as Final Text, but should be present for publication of
990

Public Comment and Trial Implementation.
>




IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

41

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

Volume 3


Content Modules

995

It’s unclear what (if any) cont
ent modules will be defined. Certainly there will not be any CDA
content.

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

42

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

5.

Namespaces and Vocabularies

Add to section 5 Namespaces and Vocabularies

<Note that the code systems already defined in the Technical Framework of this domain may
1000

(but not requir
ed) be replicated here just to aid in the supplement review as a standalone
document
.
Also note that the Section 5 table numbers and names are already defined in the TF
Vol
ume

3.>


codeSystem

codeSystemName

Description

<oid or uid>

<code system name>

<short description or pointer to more detailed
description>

<oid or uid>

<code system name>

<short description or pointer to more detailed
description>

<oid or uid>

<code system name>

<short description or pointer to more detailed
description>


1005

Add to section 5.1.1 IHE Format Codes


Profile

Format Code

Media Type

Template ID

<Profile name (profile acronym)>

<urn:ihe: >


<oids>










Add to section
5.1.3 IHE

RoleCode Vocabulary


1010

Code

Description

<name of role>

<Short, one sentence desc
ription of role or reference to more info.>

<name of role>

<Short, one sentence description of role or reference to more info.>

<name of role>

<Short, one sentence description of role or reference to more info.>

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

43

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

6
.

Content Modules

This supplement does n
ot add any CDA templates, etc. It only adds value sets to define
terminology and contexts for use within OAuth.

6.4

<Domain Acronym>
Value Sets

<Replicate the Value Set 6.5.x section as many times as needed for this supplement.>

1015

6.5.x

<Value Set Name>

<oid>

<
Add description or clarifications here if necessary.>


Coding Scheme

Concept

<Coding Scheme
Name>










Note:

<as necessary, applicable>


1020

IHE <Domain Name> Technical Framework Supplement


<Profile Name (Profile Acronym)>

______________________________________________________________________________


_________________________________________________________________
_________

Rev. x.x


20xx
-
MM
-
DD

44

Copyright © 20xx: IHE International, Inc.

Template Rev. 10.3

Appendices


<Add any applicable appendices below
;
NA if none.>

Appendix A


<Appendix A Title>

Appendix A tex
t goes here.

A.1

<Add Title>

1025

Appendix A.1 text goes here

Appendix B


<Appendix B Title>

Appendix B text goes here.

B.1

<Add Title>

Appendix B.1 text goes here.

1030


Volume
3

Namespace Additions

Add the following terms
to the IHE Namespace
:

<Please explicitly identi
fy all new OIDs, UIDs, URNs, etc., defined specifically for this profile.

These will be added to the IHE TF General Introduction namespace appendix when it becomes
1035

available. These items should be collected from the sections above

by the author
, and listed

here
as additions when this document is published for Trial Implementation. This section will be
deleted prior to inclusion into the Technical Framework as Final Text, but should be present for
publication of Public Comment and Trial Implementation.>


1040