[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-sx] XSPA WS-Trust Profile
I think that this would fit in the TC if this was done as an examples document and would be a good set of real working examples.
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 ddecouteau@sbcglobal.net Systems Interaction Diagram Event Flows Cross-Enterprise Patient Lookup
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.
8. A request for any additional Site B specific policy attributes is made/obtained 9. An access control decision is requested, determining whether Site A and User are allowed access to patient search. 10. Permit or deny decisions is reached and returned. 11. If permit, Site B patient lookup is performed. 12. A patient listing is returned to Site A. Event Flow - Accessing Patients Medical Record
14. 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. 15. Any additional policy attributes are requested and returned. 16. 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 17. 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. 18. The request for medical record is sent to SITE B and claim is authenticated attributes specific to request are parsed from assertion.
20. Any additional policy attributes are requested and returned 21. An Access Control Decision is requested, a permit or deny are returned to the service interface 22. If permit is returned a subsequent gathering of the patient clinical record occurs and are formatted to a common record format...C32? 23. 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]