 |
Return to detail page at www.hitsp.org | HITSP/SC108 |
| Prev TOC Next |
| HOME | ABOUT | MEMBERSHIP | NEWS & ANNOUNCEMENTS | MEETINGS | FAQ | CONTACT US | | Powered by American National Standards Institute |
|
Return to detail page at www.hitsp.org | HITSP/SC108 |
| Prev TOC Next |
HITSP/T17 Secured Communication Channel and HITSP/C19 Entity Identity Assertion as pre-conditions
HITSP/TP20 Access Control
HITSP/TP30 Manage Consent Directives
For more information about the underlying capabilities, pre-conditions, post-conditions, data flows and other detailed information, please refer to the constructs that are used by this service collaboration.
The Service Collaboration document illustrates one internal view diagram and sequence table for each service interface. The diagrams are descriptive and the sequences are not mandatory. They may be affected by policy, chosen architecture, and implementation details. Conformance is measured against the underlying constructs.
Table 1-1 Service Collaboration Transactions and Data
|
Service Collaboration |
Service Collaboration Description |
Interface |
Interface Optionality [1] |
|
HITSP/SC108 |
Provides mechanism for an access control decision to be made |
Request access control decision |
R |
Figure 1-1 Access Control External View Diagram
Table 1-2 List of Access Control Constructs
|
Construct |
Description |
|
HITSP/C19 - Entity Identity Assertion (Optional) |
The Entity Identity Assertion Component provides the mechanisms to ensure that an entity is the person or application that claims the identity provided. An example of this Component is the validation and assertion of a consumer logging on to a Personal Health Record (PHR) system |
|
HITSP/T17 - Secured Communication Channel |
The Secured Communication Channel Transaction provides the mechanisms to ensure the authenticity, integrity, and confidentiality of transmissions, and the mutual trust between communicating parties. Its objectives include providing: mutual node authentication to assure each node of the others identity; transmission integrity to guard against improper information modification or destruction while in transit; and transmission confidentiality to ensure that information in transit is not disclosed to unauthorized individuals, entities, or processes |
|
HITSP/TP20 - Access Control |
The Access Control Transaction Package provides the mechanism for security authorizations which control the enforcement of security policies including: role-based access control; entity based access control; context based access control; and the execution of consent directives. An example of this is a functional role that has the permission to perform an act (e.g., consumer updating a Personal Health Record (PHR). In an emergency, this construct must support the capability to alter access privileges to the appropriate level (failsafe/emergency access), which may include override of non-emergency consents |
|
HITSP/TP30 - Manage Consent Directives |
The Manage Consent Directives Transaction Package describes the messages needed to capture, manage, and communicate rights granted or withheld by a consumer to one or more identified entities in a defined role to access, collect, use or disclose individually identifiable health information (IIHI), and also supports the delegation of the patients right to consent. The transactions described in this construct are intended to be carried out by HITSP/TP13 - Manage Sharing of Documents |
There is one example diagram included for each service interface. The diagrams are descriptive and the sequences are not mandatory. They may be affected by policy, chosen architecture, and implementation details. Conformance is measured against the underlying constructs.
Figure 1-2 Request Access Control Internal View Diagram
Table 1-3 Request Access Control Pre-conditions
|
Pre-conditions |
Uses SC, T, TP or C |
Interface |
Purpose |
|
A secure communications channel shall exist |
HITSP/T17 - Secured Communication Channel |
Secure node |
A secured communication channel must be open in order to protect the authenticity and integrity of the information being transmitted |
|
Entity identity assertions have been asserted |
HITSP/C19 - Entity Identity Assertion |
N/A |
To assert identity attributes about the entity making the request |
Table 1-4 Request Access Control Sequence of Constructs [2]
|
Step Number |
Uses SC, T, TP or C |
Interface [3] |
Purpose |
|
1 |
None |
None |
Get the intended purpose of the request |
|
2 |
None |
None |
Get the identity of the system requesting the access control decision |
|
3 |
HITSP/C19 - Entity Identity Assertion |
Content Consumer |
Retrieve the identity attributes about the entity requesting the access control decision |
|
4 |
HITSP/TP30 - Manage Consent Directives |
Consent Directive Requestor |
Retrieve appropriate consent attributes |
|
5 |
None |
None |
Get the confidentiality code of the object for which access is being requested |
|
6 |
HITSP/TP20 - Access Control
|
Service User or Service Provider |
Request an access control decision from the Access Control Service, providing it with all of the attributes collected in steps 1-5 |
|
7 |
None |
None |
Enforce the access control decision. (e.g.: Grant or deny access.) |
Table 1-5 Request Access Control Sequence of Constructs Post-conditions
|
Post-conditions |
Uses SC, T, TP or C |
Interface |
Purpose |
|
Not applicable |
|
|
|
|
Return to detail page at www.hitsp.org | HITSP/SC108 |
| Prev TOC Next |