OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: XSPA WS-Trust Profile

Dear Colleagues,

I had hope to see more dialog on list in regards to selecting XSPA WS-Trust profile as a work item
of this TC.  Currently the profile may seem to lack WS-Trust functionality, which is true, it's utilization of
the SAML assertion capability to deliver health care unique attributes, does not necessarily extend of fully
utilize the standard.  This can only be attributed to our core knowledge being healthcare and the need
for this TC's guidance.

I am attaching the systems interaction diagram, event flows for x-enterprise patient lookup,
and emergency access scenario(with comments on how it might work). 
I am doing so to solicit comment. 

In the draft release of XSPA WS-Trust we have described much of the
vocabulary needed to satisfy most healthcare use cases, please refer to the document
when questions arise.

Duane DeCouteau
Veterans Health Administration
Emerging Health Technologies

Systems Interaction Diagram
Figure 1 - XSPA WS-Trust Systems Interaction

Event Flows
Cross-Enterprise Patient Lookup
Figure 2 - Cross Enterprise Patient Lookup

  1. With POU of “Emergency Access” selected at login, a check box will become visible to allow the user to choose “Include Cross Enterprise Results”. The user will enter the patients last name and first name.

  2. The service interface will request all attributes for subjectID based on their purpose of use. This will include the endpoint attributes for Site B.

  3. Additional Policy information may be returned.

  4. An access control decision will be made by vendors PDP. XACML policy will need to be changed to include POU for emergency access.

  5. A Request for Security Token, (RST), will be sent to local STS for patient lookup service at Site B. All attributes necessary for an Access Control Decision (ACS) will be asserted at this time.

  6. A Request for Security Token Response (RSTR) is returned and a service call is initiated to Site B.

Figure 3 - Cross Enterprise Patient Search #2
  1. Site B attributes related to cross enterprise patient lookup based on POU are provided.

  2. A request for any additional Site B specific policy attributes is made/obtained

  3. An access control decision is requested, determining whether Site A and User are allowed access to patient search.

  4. Permit or deny decisions is reached and returned.

  5. If permit, Site B patient lookup is performed.

  6. A patient listing is returned to Site A.

Event Flow - Accessing Patients Medical Record

Figure 4 - Accessing Patient Chart #1

  1. Subject(user) selects patient from patient listing returned from previous search. If patient is flagged as being hosted at Site B a request is made to the service interface for the remote record.

  2. Again a request for subject's(users) role, permissions are requested from attribute service, as well as remote endpoint for the patient's chart data.

  3. Any additional policy attributes are requested and returned.

  4. An access decision is requested from local ACS with a deny or permit response for access to remote resource. Note: should be distinguish remote vs. local permissions in HL7

  5. If Permit, an Request for Security Token (RST) is made to local STS with all attributes asserted at that time. A Request for Security Token Response (RSTR) is returned.

  6. The request for medical record is sent to SITE B and claim is authenticated attributes specific to request are parsed from assertion.

Figure 5 - Accessing Patient's Chart #2
  1. A request of all patient consent directives specific to the POU of “Emergency Access” is made and attributes are returned to the service interface.

  2. Any additional policy attributes are requested and returned

  3. An Access Control Decision is requested, a permit or deny are returned to the service interface

  4. If permit is returned a subsequent gathering of the patient clinical record occurs and are formatted to a common record format...C32?

  5. Since data returned is in a format not necessarily in alignment with the requesting organization it will be displayed in text format (C32 viewer/stylesheet etc.).

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]