Comments on XSPA SAML profile Public Review Draft 02

[Kathleen Connor <Kathleen.Connor@microsoft.com>]

Thank you for the opportunity to comment.

 

Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of Security Assertion Markup Language (SAML) for Healthcare Version 1.0
Submitted by Kathleen Connor, Microsoft Corporation
Section	XSPA Profile Text	Comments
1.1 Terminology	Object – An object is an entity that contains or receives information.  The objects can represent information containers (e.g., files or directories in an operating system, and/or columns, rows, tables, and views within a database management system) or objects can represent exhaustible system resources, such as printers, disk space, and central processing unit (CPU) cycles.  ANSI RBAC (American National Standards Institute Role Based Access Control) Operation - An operation is an executable image of a program, which upon invocation executes some function for the user.  Within a file system, operations might include read, write, and execute.  Within a database management system, operations might include insert, delete, append, and update.  An operation is also known as an action or privilege.  ANSI RBAC Permission - An approval to perform an operation on one or more RBAC protected objects.  ANSI RBAC Structural Role - A job function within the context of an organization whose permissions are defined by operations on workflow objects.  ASTM	Why are these terms not aligned with the terms used in Section 2.12?
2.12.5 Structural Role	Structural roles provide authorizations on objects at a global level without regard to internal details.  Examples include authorization to participate in a session, authorization to connect to a database, authorization to participate in an order workflow, or connection to a protected uniform resource locator (URL).  The structural role is the role name referenced by the patient’s consent directive.	(1) HL7 Composite Privacy Consent Directive (CPCD) V2.0 specifies both a functional and a structural role.  The XSPA description is equivalent to an HL7 functional role not a structural role.  Structural roles are competencies.  Functional roles are how entities with those competencies participate in acts – which in this context are equivalent to operations. Example:  Emergency Responder is a functional role that can be taken on by an Emergency Provider, a non-emergency  healthcare professional or a “good Samaritan” with a Red Cross certification.  All three have different “competencies” or structural roles. Because the XSPA definition has blurred the distinction, the XSPA definition of functional role is vague and not very useful. (2) Please use the HIPAA required Provider Taxonomy codes to specify structural roles – this will align more closely to designations used in the US as these tie to the NPI, which XSPA selects as the identifier.  In addition to being normative, widely used, well-maintained, and expansive, its terms are defined. http://www.wpc-edi.com/codes/taxonomy . Because the structural role type  is coded with extension in the HL7 model, parties can add codes for any deemed to be missing from the Provider Taxonomy code system.
2.12.6 Functional Role	Functional Role Functional role can include custom attributes related to application functionality agreed upon by the parties in an exchange.	Should reference the HL7 Composite Privacy Consent Directive model code system for functional roles – AuthorizedParticipationFunction, which is used to specify the exact function an actor is authorized to have in an act.  At a minimum, create a value set from that code system for XSPA.  Because the AuthorizedParticipationFunction is coded with extension in the HL7 model, parties can add codes for any deemed to be missing from the HL7 code system.
2.12.8 Action	Action The HL7 (Health Level Seven) RBAC Permission catalog is an ANSI INCITS 359-2004 RBAC compliant vocabulary that provides a minimal permission subset for interoperability.  This profile specifies the use of the following HL7 RBAC Permission Catalog Actions: Append Create Delete Read Update Execute	Should reference entire set of Operation Act Codes used in the HL7 Composite Privacy Consent Directive model, so that the operations in the HL7 encoded consent directive or privacy policy can be mapped to XSPA using a more extensive set of operation types.  At a minimum, create a value set for these codes from the HL7 Operation Act Codes so that the XSPA profile is using defined codes from a normative code system.
2.12.10 Objects	Objects are any system resource subject to access control.  This profile specifies the use of HL7 RBAC Permission Catalog as the object vocabulary in an action-object permission pair.  HL7 RBAC Permission Catalog provides the minimum set of interoperable objects suitable for the support or security and privacy access control decisions in this profile.	Should reference the HL7 Composite Privacy Consent Directive Information Artifact codes – ActInformationCategoryCode so that the object or system resource in the HL7 encoded consent directive or privacy policy can be mapped to XSPA.   I believe there are efforts to bridge the two vocabularies so that all the Permission Catalog objects are better organized and defined.  Because the ActInformationCategoryCode concept domain is coded with extension in the HL7 model, parties can add codes for any deemed to be missing from the HL7 code system.
2.12.11 Purpose of Use	Purpose of Use (POU) Purpose of use provides context to requests for information resources.  Each purpose of use will be unique to a specific assertion, and will establish the context for other security and privacy attributes.  For a given claim, all assertions must be bound to the same purpose of use.  Purpose of use allows the service to consult its policies to determine if the user’s authorizations meet or exceed those needed for access control.  Purpose of Use will be typed as string with an identifying element of <urn:oasis:names:tc:xspa:1.0:subject:purposeofuse> The following list of healthcare related purposes of use is specified by this profile: Healthcare Treatment, Payment, Operations, Emergency Treatment, System Administration, Research, Marketing, and Request of the Individual	Should reference the HL7 Composite Privacy Consent Directive model normative code system the normative rather than non-standard, less specific, undefined terms that won’t map to the HL7 encoded consent directive or privacy policy. ActInformationManagementReason Description: The rationale or purpose for an act relating to information management, such as archiving information for the purpose of complying with an enterprise data retention policy.
2.12.12 Resource	The object(s) for which access is requested must be identical to the object(s) for which the authorization assertions of this profile apply.  A requested resource is not required to be a simple object but may instead be a process or workflow.  his profile specifies the use of HL7 RBAC Permission Catalog as the resource vocabulary.	Should reference the HL7 Composite Privacy Consent Directive Information Artifact codes – ActInformationCategoryCode so that the object or system resource in the HL7 encoded consent directive or privacy policy can be mapped to XSPA using normative, defined codes.  XSPA could select a value set from that code system.