Get documents about "OASIS Cross-Enterprise Security and Privacy Authorization (XSPA
Document Sample
1 OASIS Cross-Enterprise Security and
2 Privacy Authorization (XSPA) – WS-
3 Trust Healthcare Profile
4 Working draft 20 August, 2008
5 Document identifier:
6 xspa-ws-trust-profile-01
7 Location:
8
9 Editor:
10 Brett Burley, Department of Veterans Affairs (Near Infinity Corporation)
11 Duane DeCouteau, Department of Veterans Affairs (Edmond Scientific Company)
12 Mike Davis, Department of Veterans Affairs
13 David Staggs, Department of Veterans Affairs (SAIC)
14
15 Contributors:
16
17 Abstract:
18 This document describes how WS-Trust is leveraged by cross-enterprise security and privacy
19 authorization (XSPA) to satisfy requirements pertaining to information-centric security within the
20 healthcare community.Table of contents
21 1. Introduction ..................................................................................................................................... 4
22 1.1. Document Roadmap ................................................................................................................ 4
23 1.2. Requirements and Non-goals .................................................................................................. 4
24 1.2.1. Requirements.................................................................................................................... 4
25 1.2.2. Non-Goals ......................................................................................................................... 4
26 2. Terminology ..................................................................................................................................... 5
27 3. WS-Trust Overview ......................................................................................................................... 5
28 4. XSPA WS-Trust Implementation ..................................................................................................... 6
29 4.1. Interactions between Parties .................................................................................................... 6
30 4.1.1. Assumptions ..................................................................................................................... 6
31 4.1.2. Logical Framework............................................................................................................ 7
XSPA-WS-Trust Healthcare Profile – Draft 15 August 2008
Page 1 of 24
4.1.2.1. Client Application .................................................................................................... 7
32 4.1.2.2. Service Interface ............................................................................................................ 7
4.1.2.3. Access Control System ........................................................................................... 8
4.1.2.3.1. Abstracting Access Control Decisions in Cross Enterprise Implementation .. 9
4.1.2.4. Attribute Services .................................................................................................... 9
4.1.2.4.1. Subject Attributes ............................................................................................ 9
4.1.2.4.2. Resource Attributes ...................................................................................... 12
Consent Repository...................................................................................................... 15
4.1.2.5. Policy Authority ..................................................................................................... 16
4.1.2.6. STS ....................................................................................................................... 16
4.1.2.7. Patient Lookup Service ......................................................................................... 16
4.1.2.8. Transmission Integrity ........................................................................................... 17
4.1.2.9. Transmission Confidentiality ................................................................................. 17
4.1.2.10. Error States ......................................................................................................... 17
4.1.2.11. Security Considerations ...................................................................................... 17
4.1.2.12. Confirmation Identifiers ....................................................................................... 17
4.1.2.13. Metadata Definitions ........................................................................................... 17
4.1.2.14. Naming Syntax, Restrictions and Acceptable Values ......................................... 17
4.1.2.15. Namespace Requirements ................................................................................. 17
4.1.2.16. Attribute Rules of Equality ................................................................................... 17
33 4.1.3. Example Messages......................................................................................................... 18
34 4.1.4. Request / Response – Cross Enterprise Patient Lookup ............................................... 18
35 4.1.5. Request / Response – Medical Record Access ............................................................. 22
36 4.1.6. Masking of Clinical Data ................................................................................................. 25
37 4.1.7. Enforcement Cross Enterprise Business Rules .............................................................. 25
38 4.1.8. Request for Additional Attributes .................................................................................... 25
39 5. References .................................................................................................................................... 27
40
41
42
43
44
45
46
47
XSPA-WS-Trust Healthcare Profile – Draft 15 August 2008
Page 2 of 24
48 Introduction
49 XSPA encompasses the mechanisms to authenticate and administer, and enforce authorization
50 policies controlling access to protected information residing within or across enterprise boundaries.
51 The policies being administered and enforced relate to security, privacy and consent directives. In
52 general, and with respect to this profile, WS-Trust works in concert with additional, supporting,
53 lower-layer standards including WS-Security, WS-Policy and SAML to provide the overarching
54 XSPA specification.
55 [XACML] is well suited for, and may be used to provide policy administration and enforcement
56 within XSPA, leveraging a WS-based infrastructure where appropriate. However, this profile does
57 not include the use of XACML within XSPA. XSPA does not mandate the use of XACML.
58 This document provides an overview of the major WS components of the XSPA profile. The profile
59 then establishes how these components may be used to implement cross-enterprise access control
60 requirements relevant to the healthcare community.
61 This profile does not address security required to protect message transactions such as digital
62 signatures and encryption, but instead discusses how shared messages can be used to negotiate
63 the necessary claims to access a protect resource.
64 It is assumed that the reader is somewhat familiar with the WS standards extended by WS-Trust.
65 Document Roadmap
66 Presentation of requirements, non-goals and terminology
67 Review of components that are encompassed by this XSPA profile
68 Details of XSPA implementation within the healthcare community
69 Requirements and Non-goals
70 Requirements
71 Achieve cross-enterprise authentication and authorization of entities (e.g. user or server) within the
72 healthcare community. This will be accomplished through XSPA by leveraging and extending
73 existing and candidate OASIS standards.
74 Non-Goals
75 The following topics are outside the scope of this document:
76 The use of XACML as means for creating rules and policy sets within or across security
77 domains.
78
79
80
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 3 of 24
81 Terminology
82 The following definitions establish the terminology and usage in this profile:
83 Access Control System (ACS) –
84 Attribute Service - An attribute service is a Web service that maintains information (attributes) about
85 principals within a trust realm or federation. The term principal, in this context, can be applied to
86 any system entity, not just a person.
87 Claim – A claim is a declaration made by an entity (e.g. name, identity, key, group, privilege,
88 capability, attribute, etc).
89 Metadata – Any data that describes characteristics of a subject. For example, federation metadata
90 describes attributes used in the federation process such as those used to identify – and either
91 locate or determine the relationship to – a particular Identity Provider, Security Token Service or
92 Relying Party service.
93 Policy – A policy is a collection of policy alternatives.
94 Purpose of Use
95 Realm or Domain – A realm or domain represents a single unit of security administration or trust.
96 Relying Party – A Web application or service that consumes Security Tokens issued by a Security
97 Token Service.
98 Security Token – A security token represents a collection of claims.
99 Security Token Service – A security token service (STS) is a Web service that issues security
100 tokens (see [WS-Security]). That is, it makes assertions based on evidence that it trusts, to
101 whoever trusts it (or to specific recipients). To communicate trust, a service requires proof, such as
102 a signature to prove knowledge of a security token or set of security tokens. A service itself can
103 generate tokens or it can rely on a separate STS to issue a security token with its own trust
104 statement (note that for some security token formats this can just be a re-issuance or co-signature).
105 This forms the basis of trust brokering.
106 Trust – Trust is the characteristic that one entity is willing to rely upon a second entity to execute a
107 set of actions and/or to make set of assertions about a set of subjects and/or scopes.
108 WS-Trust Overview
109 This profile specifies the use of WS-Trust, an extension of WS-Security, as a token-type agnostic
110 means for requesting, issuing, renewing, and validating security assertions. While the WS-Trust
111 specification completely describes these activities, a brief overview is provided here describing the
112 interactions between a web service requestor, security token service (STS) and web service
113 provider.
114
115 The core component of WS-Trust is the STS. The authentication and authorization-related services
116 provided by the STS are conducted on the frontline of the multi-layered approach of this profiles
117 strategy for securing web services.
118
119
120
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 4 of 24
121
122 Figure 1 WS-Trust Model [WS-Trust]
123
124 In Figure 1 the STS acts as a brokering agent by issuing tokens, in the form of a response to the
125 requestor. The requestor then submits the token to the web service. The web service may
126 subsequently contact the STS to ensure the validity of the token and its claims (e.g. none of the
127 claims have been revoked).
128 The most fundamental concept of WS-Trust is that requestors and consumers of tokens trust the
129 issuer of that token, the STS.
130
131 XSPA WS-Trust Implementation
132 The objective of XSPA and this profile is to achieve cross-enterprise authorization of entities within
133 the healthcare community by providing common semantics and vocabularies for interoperable
134 course and fine-grained access control.
135
136 The following sections present a detailed look at the interaction between parties operating within
137 the security framework of this profile, the elements of WS-Trust leveraged by XSPA, as well as a
138 use case demonstrating the access control capabilities of XSPA.
139 Interactions between Parties
140 The XSPA WS-Trust model facilitates course and fine-grained access control, relieving the service
141 provider from making access control decisions. The service provider is left with only having to
142 enforce the decision determined by an access control service (ACS).
143 Assumptions
144 The enterprise identity related to the healthcare system user has been established prior to
145 issuing the request for a security token
146 No user or application is allowed direct access to patient information services
147 All security policies related to healthcare system end point have been established and put
148 in place using mechanisms outside the scope of this document
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 5 of 24
149
150 Logical Framework
151 The following figure provides a logical view of components and the interaction between parties in
152 the exchange of healthcare information. Elements illustrated in the figure are explained in the
153 subsections below.
154
155
156
157
158
159
160
161
162
163
164
165
166 Figure 2 – Logical Framework/Interaction
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 6 of 24
167
168 Client Application
169 Both rich (desktop) and browser based applications are supported in this profile. The client
170 application may ONLY request resources from the local service interface. Client requests must
171 include
172 Purpose of Use (POU),
173 Object requested as described in HL7 Version 3 Standard: Role-based Access Control
174 Healthcare Permission Catalog [HL7-RBAC],
175 Action requested may be in the form of create, read, update, delete, and edit.
176 Additional actions may be passed if agreed upon by both parties.
177 Resource (patient unique identifier if known, and the user’s unique identifier or token.
178 Service Interface
179 This interface acts as a bus to all available services within a given entity. Users may only request
180 allowed resources through this interface. The responding service interface at the remote entity will
181 be responsible for authenticating the validity of the token by parsing out any assertions (SAML
182 Assertion) made and providing them to the ACS so an access control decision may be made.
183
184 The responding service interface will be responsible for providing any object translations required
185 within that entity. An example for consideration is shown in the following table.
186
HL7 Object Site A – Service Result Site B – Service Native
Format Format
Radiology Http://siteA/XSPA/Radiology?wsdl CDA Http://siteB/XSPA/Radiology?wsdl CDA
Order
(common)
Radiology Http://siteA/ClinServices/Radiology?wsdl CDA Http://siteB/Orders/Radiology?wsdl Proprietary
Order
(site specific)
187
188 In the above table, Site B would be responsible for translating from the proprietary format of a
189 radiology order to Clinical Documentation Architecture (CDA).
190
191 Note: This profile DOES NOT provide for or recommend any clinical data exchange standards.
192 Access Control System
193 In typical implementations, no user or application is allowed direct access to patient information.
194 The XSPA profile of WS-Trust supports this requirement by sending all requests through an Access
195 Control System (ACS). In performing the request, the ACS may acquire additional attribute
196 information related to a user’s location, purpose of use, permissions, roles, license information,
197 remote service endpoints, and requested resource requirements and actions. A local access control
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 7 of 24
198 decision may be made to deny access to the requested resource (course-grained access control).
199 If permitted the requesting ACS will request a token be granted from an STS that asserts all known
200 information relevant to the request. The requesting ACS is responsible for enforcing the access
201 control decision.
202
203 It should be noted that the requesting ACS may make an access control decision to deny access to
204 remote resources based on local internal policies. If the requesting ACS determines to permit a
205 transaction, an applicable token will be requested from an STS and the subsequent request to the
206 remote web service will be made with that token.
207
208 Abstracting Access Control Decisions in Cross Enterprise
209 Implementation
210 It is assumed that if a set of attributes are evaluated against identical policies that the resultant
211 decision would be the same regardless of the location of the evaluation. This profile in no way
212 defines how or what tools sets will be used in any vendor implementation. Instead it is
213 recommended that abstract program logic be used to describe how access decisions are reached
214 between parties and internally.
215
216 The following describes in an abstract manner how required permissions and permission granted to
217 a subject could be evaluated.
218
219
220 If permissions.attributeValue equals requiredpermission.attributeValue
221 then
222 permit
223 else
224 deny
225 end if;
226
227 Attribute Services
228 The Attribute Service provides the ACS additional attributes necessary to make an access control
229 decision. This profile focuses a healthcare use case and its required attributes to describe its
230 implementation. This by no means limits its implementation to this sector. Any vocabulary could be
231 offered to ACS through the Attribute Service model. Attributes within this profile will be harmonized
232 with and support ISO 10148-3.
233 Subject Attributes
234 This service provides attributes that are specific to the requesting user and are only known to the
235 entity which manages them.
236
237 SubjectName
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 8 of 24
238 This is the name of the user as required by HIPAA Privacy Rule, Section 164.528 – Accounting of
239 Disclosures SubjectName will be typed as a string in plain text with an identifying element of
240 <urn:oasis:names:tc:SAML:2.0:profiles:attribute:XPSA:subjectname >
241
242 SubjectID (Optional)
243 In some implementations, a country may require a government issued identifier. For example, in the
244 U.S., the subjects National Provider Identifier (NPI) is required for all HIPPA standard transactions.
245 SubjectID will be typed as a string in plain text with an identifying element of
246 <urn:oasis:names:tc:SAML:2.0:profiles:attribute:XPSA:subjectid>.
247
248 Organization
249 This is the organization that the user belongs to as required by HIPAA Privacy Disclosure
250 Accounting. Organization will be typed as a string in plain text with an identifying element of
251 <urn:oasis:names:tc:SAML:2.0:profiles:attribute:XPSA:organization>
252
253
254 Role (Optional)
255 Roles are placeholders for permission defined by that organization. The use of Role as criteria to
256 make an access control decision would require agreement of their vocabulary between
257 organizations, which may be mandated by law or by a multi-organizational agreement, e.g., by
258 members of a health information exchange organization. Permissions, assigned to roles within an
259 organization, are defined in the HL7 Version 3 Standard: Role-based Access Control Healthcare
260 Permission Catalog [HL7-RBAC]. Licensing information related to subject playing the role may be
261 asserted in the form of a certificate.
262
263 Permission (optional)
264 There is no explicit assertion of permission required by this profile.
265 The permission in use is determined by the Action on the Target. See Action below. The
266 Permission is the ANSI INCITS RBAC compliant action-object pair representing the authorization
267 required for access by the protected resource. In this profile, the service acting as a proxy for the
268 user implicitly asserts the authorizations of the principal by sending the request as required by the
269 inter-organizational agreement. The sending of the request by the trusted service consumer is
270 evidence to the relying party (service) that the service consume has:
271
272 Correctly authenticated at the assurance level required by mutual agreement,
273 Determined that the user is authorized to make the request and receive the information
274 requested,
275 Verified that all subject consent directives have been consulted and there is no prohibition
276 regarding the request.
277
278 Figure 3 illustrates the general relationship between subject (user) and granted permissions to
279 specific objects as a relationship to their POU. POU is determined during the login process. Roles
280 in this relationship are placeholders for permissions. Permission defines the object-action
281 relationship.
282
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 9 of 24
283
284 Figure 3 Determining Subject Permissions
285
286
287 Resource Attributes
288
289 Required Permissions
290 Required permissions for object action pairing are known only to a given entity. A relationship
291 exists with the client application requested resource and the permission required for its action. By
292 determining that the requester’s role and asserted POU should be permitted to act on the object
293 requested, an access control decision can be made prior to traversing across enterprises.
294 Objects, actions and permissions are described in the HL7 Version 3 Standard: Role-based Access
295 Control Healthcare Permission Catalog [HL7-RBAC].
296
Purpose of Use Object Action Permission Required
Healthcare Access {R, Radiology Order} Read PRD-004
Emergency Access {R, Radiology Order} Read PEA-001
(etc)
297
298
299 Purpose of Use
300 Purpose of use (POU) provides essential context for requests to information resources. Each
301 purpose of use will be unique to a specific claim, and will establish the context for other security and
302 privacy attributes. Within a claim, all other claims and assertions must be bound to the purpose of
303 use. POU allows the service to consult its policies to determine if the user’s claims meet or exceed
304 those needed to allow access.
305 From a clinician’s perspective, they will interact with the healthcare application to establish the POU
306 at the time of requesting patent information. This will take the form of the healthcare application
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 10 of 24
307 offering a list of appropriate POUs to the clinician based on their role. (e.g. Healthcare Treatment,
308 Emergency Treatment, etc.).
309 A patient establishes usage permissions through consent directives, which will be correlated to
310 each POU. For example, a patient’s consent directive under normal conditions (Healthcare
311 Treatment POU) will include objects, confidentiality codes and policy attributes which may be much
312 different from those in an emergency (Emergency Treatment POU). Consent directives specific to
313 a purpose of use allows both the patient and the system enforcing access control to share a
314 common context and vocabulary for requirements, claims and policy enforcement that provides for
315 interoperability of both security and privacy enforcement.
316
317 The following list of healthcare related purposes of use is specified by this profile.
318 Healthcare Treatment
319 Emergency Treatment
320 System Administration
321 Operations
322 Payment
323 Research
324 Marketing
325
326 Object Service Endpoints
327 Additionally, object service endpoints which are shared / distributed across trusted entities are also
328 provided. Participating organization must share clinical service endpoints, have a common method
329 naming convention, and data format exchange standard as described in the following table.
330
331
Site Object Endpoint Operation Result
Format
Site A {R, Radiology Http://siteA/XSPA/ClinicalServices?wsdl GetRadiologyOrder CDA
Order}
Site B {R, Radiology Http://siteB/webservices/Clinical?wsdl GetRadiologyOrder CDA
Order}
Site C {R, Radiology Http://siteC/ws/Radiology?wsdl GetRadiologyOrder CDA
Order}
332 Consent Repository
333 The resource (e.g. patient) may choose to constrain access to their records. They do so by
334 establishing a consent directive which subsequently resides in the consent repository. The
335 responsibility of enforcing these constraints falls on both the Service Responder and Consumer.
336 Figure 4 shows the general relationship between POU and resources consent directive when
337 constraining permissions to specific subjects (users) or their roles. In this profile POU will be those
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 11 of 24
338 previously specified in this document. Consent Code in this profile will implement the HL7 Version 3
339 Consent related vocabulary including Confidentiality Codes [HL7-Consent]. The Subject and Role
340 vocabulary for this profile conforms to the ASTM standard for structural healthcare roles [ASTM
341 E1986-98(2005)].
342
343 Figure 4 POU and User Based Access (UBA) Control
344
345
346 Figure 5 shows the general relationship between POU and masking of specific object based on the
347 subject or their role. In addition to those vocabularies specified for use with the components
348 illustrated in figure 4, the objects of this profile are defined through the HL7 RBAC Permission
349 Catalog [HL7-RBAC].
350
351
352 Figure 5 Resource Object Masking (MA)
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 12 of 24
353
354 Policy Authority
355
356 The Policy Authority contains rules specific to that entity as well as any mutually agreed upon
357 cross-enterprise policies. The ACS sources these policies to make access control determination
358 prior to making any external requests. This document does not address how the policies are
359 represented. It remain up to the implementer what best fits their ACS implementation.
360
361 STS
362 The Security Token Service (STS) acts as a brokering agent by issuing tokens, in the form of a
363 response to the requesting ACS. The requesting ACS then submits the token to the web service.
364 The web service may subsequently contact the STS to ensure the validity of the token and its
365 claims (e.g. none of the claims have been revoked).
366 The most fundamental concept of WS-Trust is that requestors and consumers of tokens trust the
367 issuer of that token: the STS.
368 Patient Lookup Service
369 Refer to section 4.1.4 for an example of interactions. This document does not address or suggest
370 how this function may be implemented.
371 Transmission Integrity
372 The XSPA profile of WS-Trust recommends the use of reliable transmission protocols. Where point-
373 to-point transmission integrity is required, this profile specifies the Healthcare Information
374 Technology Standards Panel (HITSP) Secured Communication Channel (TP17).
375 Transmission Confidentiality
376 The XSPA profile of WS-Trust recommends the use of secure transmission protocols. Where point-
377 to-point transmission confidentiality is required, this profile specifies the HITSP TP17.
378 Error States
379 This profile will implement messaging standards described in WS-Trust when communicating error
380 states between requesting and responding entities.
381 Security Considerations
382 <Risk assessment>
383 Confirmation Identifiers
384 No known common identifiers at this time.
385 Metadata Definitions
386 This profile will utilize the WS-Trust <AttributeStatement> to inject a SAML assertion into request.
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 13 of 24
387 Naming Syntax, Restrictions and Acceptable Values
388 This profile will support the namespace requirements described in WS-Trust.
389 Namespace Requirements
390 This profile will support the namespace requirements described in WS-Trust.
391 Attribute Rules of Equality
392 All asserted attributes child to <AttributeStatement> element will be typed as strings. Two
393 <Attributes> elements refer to the same SAML attribute if and only if their Name XML attribute
394 values are equal in a binary comparison.
395
396
397 Example Messages
398 The following are intended to provide additional guidance to implementers. These examples
399 leverage the draft profile [XSPA-SAML] Cross-Enterprise Security and Privacy Authorization
400 (XSPA) Profile of Security Assertion Markup Language (SAML). Implementers may choose to
401 utilize other means of asserting attributes beyond SAML capabilities within WS-Trust.
402
403 Example Header
404
405 Timestamp Example
406 Timestamp information should be included – TBD.
407 Request / Response – Cross Enterprise Patient Lookup
408
409 Event Flow
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 14 of 24
410
411 Figure 6 Cross Enterprise Patient Lookup Event Flow
412
413 Patient search across enterprises may only require a coarse grain approach to authorization where
414 an access control decision can be made without the evaluation of subject attributes. In this case
415 the responder’s services interface may execute the lookup without having to interact with the ACS.
416 This a result of trust between two STSs.
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 15 of 24
417
418 Figure 7 Cross Enterprise Patient Lookup Event Flow (Cont.)
419
420 Request
421 Within this XSPA profile SAML 2.0 assertions are used to establish the attributes of the actors
422 involved in a transaction.
423 The following is an example of the expected syntax of an RST with respect to this XSPA profile.
424
425 <wst:RequestSecurityToken Context="..." xmlns:wst="...">
426 <wst:TokenType>...</wst:TokenType>
427 <wst:RequestType>...</wst:RequestType>
428 <wst:SecondaryParameters>...</wst:SecondaryParameters>
429 ...
430 </wst:RequestSecurityToken>
431
432
433 Response Example
434 This document does not define what attributes of the patient demographic record should be
435 contained in the resultant patient list. At minimum the patientId, name, age, gender, primary clinic,
436 and/or provider should be available for the consumer to make a selection. This also assumes that
437 all requests for a patients clinical record require the selection of that patient first.
438
439 The following is an example of the expected syntax of an RSTR with respect to this XSPA profile:
440
441 <wst:RequestSecurityTokenResponse>
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 16 of 24
442 <wst:TokenType>
443 SAML
444 </wst:TokenType>
445 <wsp:AppliesTo>
446 <wsa:EndpointReference>
447 <wsa:Address>http://hostname/webservice/patientlookup</wsa:Address>
448 </wsa:EndpointReference>
449 </wsp:AppliesTo>
450 <RequestedSecurityToken>
451 <saml:Assertion … >
452 <AttributeStatement>
453 <Attribute
454 AttributeName="subject"
455 AttributeNamespace="http://schemas.xmlsoap.org/claims">
456 <AttributeValue>
457 <Attribute AttributeName=”subjectName”
458 AttributeNameSpace=”http://schemas.xmlsoap.org/claims”>
459 <AttributeValue>
460 Doctor, Bob
461 </AttributeValue>
462 </Attribute>
463
464 <!-- optional -->
465 <Attribute AttributeName=”subjectID”
466 AttributeNameSpace=”http://schemas.xmlsoap.org/claims”>
467 <AttributeValue>
468 100011
469 </AttributeValue>
470 </Attribute>
471 <!-- end optional -->
472
473 <Attribute AttributeName=”organization”
474 AttributeNameSpace=”http://schemas.xmlsoap.org/claims”>
475 <AttributeValue>
476 Fort Harrison, Helena MT
477 </AttributeValue>
478 </Attribute>
479
480 <!-- optional -->
481 <Attribute AttributeName=”Role”
482 AttributeNameSpace=”http://schemas.xmlsoap.org/claims”>
483 <AttributeValue>
484 Physician
485 </AttributeValue>
486 </Attribute>
487 <Attribute AttributeName=”permissions”
488 AttributeNameSpace=”http://schemas.xmlsoap.org/claims”>
489 <AttributeValue>
490 PRD-001
491 </AttributeValue>
492 <AttributeValue>
493 PRD-004
494 </AttributeValue>
495 <AttributeValue>
496 PRD-011
497 </AttributeValue>
498 </Attribute>
499 <!-- end optional -->
500
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 17 of 24
501 <AttributeStatement>
502 <Attribute
503 AttributeName="resource"
504 AttributeNamespace="http://schemas.xmlsoap.org/claims">
505 <AttributeValue>
506 <Attribute AttributeName=”resourceName”
507 <AttributeValue>
508 patientSearch
509 </AttributeValue>
510 </Attribute>
511 <Attribute AttributeName=patientName
512 <AttributeValue>
513 Doe,John
514 </AttributeValue>
515 </Attribute>
516 <Attribute AttributeName=”action”
517 AttributeNameSpace=”http://schemas.xmlsoap.org/claims”>
518 <AttributeValue>
519 Read
520 </AttributeValue>
521 </Attribute>
522
523 </AttributeStatement>
524 </saml:Assertion>
525 </wst:RequestedSecurityToken>
526 </wst:RequestedSecurityTokenResponse>
527
528
529
530 Required Attributes
Attribute Namespace Comments
Patientidentifier tbd Each entity may employ varying
(lastname,firstname,middle methodologies for patient
initial, etc.) lookup. Participating parties
will need to agree on what is
required and to what level of
detail.
Subjectname tbd
Organization tbd
Purposeofuse tbd
Resourcename tbd Refer to [HL7-PERM] for object
values
Action tbd Create, read, update, delete,
edit, and other mutually agreed
upon action values.
531
532
533 Optional Attributes
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 18 of 24
Attribute Namespace Comments
SubjectId tbd For U.S. Implementations this
is the users Medicaid ID.
Role tbd
Permission tbd
534 Request / Response – Medical Record Access
535 Event Flow
536 Refer to Figure 6 for local access control decision. Figure 8 shows the access control decision
537 event at remote site. In this example the ACS must be provided with the patient’s consent
538 directives.
539
540
541 Figure 8 Medical Record Event Flow
542
543 Request Example
544 The following is an example of the expected syntax of an RST with respect to this XSPA profile with
545 requesting access to patient medical record(char).
546
547 <wst:RequestSecurityToken Context="..." xmlns:wst="...">
548 <wst:TokenType>...</wst:TokenType>
549 <wst:RequestType>...</wst:RequestType>
550 <wst:SecondaryParameters>...</wst:SecondaryParameters>
551 ...
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 19 of 24
552 </wst:RequestSecurityToken>
553
554 Response Example
555 The following is an example of the expected syntax of an RSTR with respect to this XSPA profile
556 with requesting access to patient medical record(char).
557
558 <wst:RequestSecurityTokenResponse>
559 <wst:TokenType>
560 SAML
561 </wst:TokenType>
562 <wsp:AppliesTo>
563 <wsa:EndpointReference>
564
565 <wsa:Address>http://hostname/webservice/MedicalRecord/Radiology</wsa:Address>
566 </wsa:EndpointReference>
567 </wsp:AppliesTo>
568 <RequestedSecurityToken>
569 <saml:Assertion … >
570 <AttributeStatement>
571 <Attribute
572 AttributeName="subject"
573 AttributeNamespace="http://schemas.xmlsoap.org/claims">
574 <AttributeValue>
575 <Attribute AttributeName=”subjectName”
576 AttributeNameSpace=”http://schemas.xmlsoap.org/claims”>
577 <AttributeValue>
578 Doctor, Bob
579 </AttributeValue>
580 </Attribute>
581
582 <!-- optional -->
583 <Attribute AttributeName=”subjectID”
584 AttributeNameSpace=”http://schemas.xmlsoap.org/claims”>
585 <AttributeValue>
586 100011
587 </AttributeValue>
588 </Attribute>
589 <!-- end optional -->
590
591 <Attribute AttributeName=”organization”
592 AttributeNameSpace=”http://schemas.xmlsoap.org/claims”>
593 <AttributeValue>
594 Fort Harrison, Helena MT
595 </AttributeValue>
596 </Attribute>
597
598 <Attribute AttributeName=”role”
599 AttributeNameSpace=”http://schemas.xmlsoap.org/claims”>
600 <AttributeValue>
601 Physician
602 </AttributeValue>
603 </Attribute>
604 <Attribute AttributeName=”permissions”
605 AttributeNameSpace=”http://schemas.xmlsoap.org/claims”>
606 <AttributeValue>
607 PRD-001
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 20 of 24
608 </AttributeValue>
609 <AttributeValue>
610 PRD-004
611 </AttributeValue>
612 <AttributeValue>
613 PRD-011
614 </AttributeValue>
615 </Attribute>
616
617
618 <AttributeStatement>
619 <Attribute
620 AttributeName="resource"
621 AttributeNamespace="http://schemas.xmlsoap.org/claims">
622 <AttributeValue>
623 <Attribute AttributeName=”resourceName”
624 <AttributeValue>
625 RadiologyReport
626 </AttributeValue>
627 </Attribute>
628 <Attribute AttributeName=patientId
629 <AttributeValue>
630 Doe,John
631 </AttributeValue>
632 </Attribute>
633 <Attribute AttributeName=”action”
634 AttributeNameSpace=”http://schemas.xmlsoap.org/claims”>
635 <AttributeValue>
636 Read
637 </AttributeValue>
638 </Attribute>
639
640 </AttributeStatement>
641 </saml:Assertion>
642 </wst:RequestedSecurityToken>
643 </wst:RequestedSecurityTokenResponse>
644
645
646 Required Attributes
647
Attribute Namespace Comments
PatientId tbd Unique to remote entity
Subjectname tbd
Organization tbd
Purposeofuse tbd
Resourcename tbd Refer to [HL7-PERM] for object
values
Action tbd Create, read, update, delete,
edit, and other mutually agreed
upon action values.
Permission tbd
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 21 of 24
Role tbd
648
649 Optional Attributes
650
Attribute Namespace Comments
PatientName tbd
651
652
653
654 Masking of Clinical Data
655
656 In masking clinical data, the event flow is identical to accessing a patient-specific medical record
657 discussed in section 4.1.5 with the exception that the patient's consent directive requires masking
658 of portions of the clinical record. The response in this case will need to contain an obligation
659 defining which object must be hidden from the requesting user. The consuming ACS and its
660 service interface must enforce this obligation.
661
662 Enforcement Cross Enterprise Business Rules
663
664 In enforcing cross enterprise business, the event flow is identical to accessing a patient specific
665 medical record as discussed in section 4.1.5 with the exception that entities internal policies
666 requires additional controls on the clinical record. The response in this case will need to contain a
667 policy snippet defining the business rule. The consuming ACS and its service interface must
668 enforce this business rule.
669
670 Request for Additional Attributes
671 Event Flow
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 22 of 24
672
673 Figure 9 Request of Additional Attributes
674
675
676 References
677
678 [ASTM E1986-98(2005)] Standard Guide for Information Access Privileges to Health Information.
679
680 [HITSP/TP20] Healthcare Information Technology Standards Panel Security and Privacy
681 Technical Committee. HITSP Access Control Transaction Package, v1.1. October 2007.
682
683 [HL7-Consent] Healthcare Level 7. RBAC Consent related vocabulary including Confidentiality
684 Codes, v3.0.
685
686 [HL7-RBAC] Healthcare Level 7. RBAC Healthcare Permission Catalog, v3.38. November 2007.
687
688 [SAMLPROF] Organization for the Advancement of Structured Information Standards. Profiles for
689 the OASIS Security Assertion Markup Language, v2.0, February 2005.
690
691 [WS-Trust] Organization for the Advancement of Structured Information Standards. WS-Trust,
692 v1.3, March 2007.
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 23 of 24
693
694 [XSPA-SAML] Draft Profile - Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of
695 Security Assertion Markup Language (SAML)
XSPA-WS-Trust Healthcare Profile - Draft 15 August 2008
Page 24 of 24
Related docs
