Re: [xspa] Comments for XSPA 2.0 SAML profile

[Massimiliano Masi <massimiliano.masi@tiani-spirit.com>]

Hi, 


Il giorno 15/giu/2012, alle ore 21:01, Duane Decouteau ha scritto:

> 1. The NwHIN Authorization guide specifies the use of a pseudo ­ xspa
> subject id attribute of "urn:oasis:names:tc:xspa:1.0:subject:subject-id"
> instead of using the XACML subject-id as called out in the XSPA 1.0 and
> 2.0 draft. Should we care?
> 
> ****Don't care
> 

This error came from earlier draft of XSPA that was mandating this 
endpoint. IHE XUA++ was following the typo of NwHIN, but it has 
been corrected. So I suppose NwHIN will correct this typo too. 
EU epSOS is using the correct name. (Although is funny: the attributes
is named subject-id, but in fact, it is not an id, just the human
readable name).
  
> 2. The NwHIN Authorization gude specifies the use of a structured HL7 type
> as the attribute value for the purpose of use and role attributes. We
> decided to reference other sources for the value of these attributes, but
> should we copy the concept of a coded type or just leave the value lacking
> the notion of a code system? The commonly accepted health care IT practice
> when it comes to standards seems to prefer using coded or strongly typed
> values, so I advocate a similar approach for consistency sake.
> 
> ***Does the community plan to write policy based on a attributes code, codeSystem, codeSystemName, not sure this complexity would help implementors.


I see that as an misunderstanding by the NwHIN (and thus IHE XUA++) specs: XSPA defines
to have string-based roles, thus element-based roles are a violation of the standard. 
Either XSPA relaxes the dataType or NwHIN has to change the name. 

I agree with you, Michael: the usual way to encode a value in healthcare IT is
through coded values, since they have a precise semantics, thus guaranteeing 
interoperability.

Maybe coded values can be took into account for XSPA 2.0? I see the fact to use
either string or elements is a big opportunity for XSPA. 

Ciao, 

	Massi




--
Massimiliano Masi - http://www.mascanc.net/~max

Tiani "Spirit" GmbH
Guglgasse 6
Gasometer A
1110 Vienna
Austria/Europe

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail