Question+Dropbox

This wiki page is a place for Spec Factory participants and the community in general to ask questions and request clarifications from the Spec Factory Team. In order to post a question, please just add it by editing this page using the "EDIT" button on the top right hand part of the page. If you do not see an "EDIT" button you probably do not have a wiki account and you need to get yourself a wiki account at www.wikispaces.com.

To post a question add a new row to the table (or use an existing empty row). Include your name and, if known, the specification associated with the question. In the Description column include a detailed description of the question. Guidance on adding a new row.

The questions will be answered by the Spec Factory Team on the wiki page Spec Factory FAQ. Once the questions are answered, the questions will be deleted from this page.

Please Submit Your Question(s) Below:
Note: When viewing this table in Internet Explorer, all 7 columns may not be visible. It is recommended to maximize your browser window to view this table. If the full table is still not visible, there is a horizontal scroll bar located at the bottom of the page.

Clarify current position on PurposeForUse: The PurposeForUse/PurposeOfUse issue is well documented here: http://standards-and-interoperabilty-specifications.wikispaces.com/Auth+PurposeOfUse+Research. The new warning says in part: "elected to temporarily leave the errant text as is, and to call implementer’s attention to this discrepancy". But the spec stops short of telling current implementers to use PurposeForUse. Is that the intent? ||  ||   ||   || Section 3.3, SAML Assertions, specifies the "ID attribute which is an xs:ID as defined by http://www.w3.org/TR/xml-Id/". But in the following example, it shows an id constructed as a UUID: <saml2:Assertion ID="ed62b6fb-4d73-4011-9f7c-43e0575b6317"... Numerous gateway implementers have followed this example and used UUIDs. UUIDs can often start with a number, which would make them invalid assertion ids. Recommend modifying the example and adding guidance that if UUIDs are used to prefix them with something valid, for example, "_" or "uuid-". Is our interpretation correct? ||  ||   ||   || Section 3.3.3.1, Authorization Decision Statement Content, appears to fully prescribe the contents of this element, including an Assertion element. It does not call for a Subject element within the Assertion (although I guess it doesn't rule it out either). In saml-core-2.0-os, lines 1167-1168 say "Assertions containing  elements MUST contain a  element". Is this an oversight, or are the rules different for Assertions in this context? ||  ||   ||   || Section 3.3.2.7 Patient Identifier Attribute says: This attribute is OPTIONAL, as it may not be needed for cases in which the data being exchanged does not pertain to a specific patient (e.g. population health data). The value of the Patient Identifier attribute MUST be specified when the InstanceAccessConsentPolicy attribute is specified in an Authorization Decision Statement.
 * **Submit Date** || **Submittor** || **Specification** || **Description** || **Owner** || **Status** || **Close Date** ||
 * 10/25/2010 || Joe Lamy || Authorization Framework || [authfw-1]
 * Wrapup current discussion on SAML Subject and Issuer: at http://standards-and-interoperabilty-specifications.wikispaces.com/Auth.+Framework-+Incorrect+Issuer there is some excellent discussion around what the Subject and Issuer can be. As the questions come from a testing perspective, I'm requesting a conclusion on the immediate question taking into account the testability of the answer, and the date it is applicable. For example the last entry for Issuer states:
 * [spec factory entry] Agree: This is the identity of the identity-provider, not necessarily a human. At best this might be an organization or arm-of-an-organization. I would say that the concept of “less is more” be applied to the verbiage in the AF
 * [Testing team response] This sounds like there is consensus, but I don't want to jump the gun. Please make clear if there is an official position on this from the spec factory, what that is and when it is effective (i.e. when we can begin testing to it). As to testability, we have another discussion going regarding how we test the SAML header contents here: http://standards-and-interoperabilty-specifications.wikispaces.com/message/view/Testing+Team/28918897. For Subject and Issuer, assuming we are just passively looking at a SAML header, what passes and what doesn't? Should we attempt to make a subjective evaluation at all? Should the identity provider specified be cross-checked with other available information about the organization? Thanks. ||  ||   ||   ||
 * 10/25/2010 || Joe Lamy || Authorization Framework || [authfw-2]
 * 11/2/2010 || Tom Davidson || Patient Discovery || PatDisc-2: Given a scenario where a home community supports multiple assigning authorities, assuming that the home community has performed a security evaluation and determined that it should honor the request, how should the home community respond if it is unable to communicate with one of the assigning authorities (e.g. – network connectivity problems). Should the home community return a patient discovery response with the patient information that it could successfully match along with a status value indicating partial success (assuming such a status value exists), or should the home community return an error response for the entire transaction?
 * [spec factory discussion] Will investigate whether HL7 V3 has a mechanism to return some results plus and error. ||  ||   ||   ||
 * 11/2/2010 || Tom Davidson || Patient Discovery || PatDisc-3: Given a scenario where a home community supports multiple assigning authorities, is it possible to target patient discovery to a specific assigning authority?
 * [spec factory discussion] The IHE specification specifically restricts this but the underlying standard, HL7 V3 messaging, does support this use case. A Change Proposal will be created to request IHE to change its position on this. ||  ||   ||   ||
 * 11/4/2010 || Joe Lamy || Authorization Framework || [authfw-3]
 * 11/4/2010 || Joe Lamy || Authorization Framework || [authfw-4]
 * 11/17/2010 || Joe Lamy || Authorization Framework || [authfw-5]

Issue: The optionality of this attribute must be described with more precision. The Testing Team's interpretation is that it must be included for patient discovery, query for documents and retrieve documents requests, as these all pertain to a specific patient. Yet we have seen candidates not including it in these requests on the basis that it is optional. Is our interpretation correct?

The SSA does indeed pass the patientid over, as XCPD, XCA don't really make sense in their context without the PID. The PID may be construed as a release of information. In fact, some use pseudonymization of the PID. Proposed solution: The base spec is correct as is, but probably could benefit with some non-normative implementation guidance text. It is has also been suggested that a profile would be the proper place to address the precise use of the optionality of the PID. Perhaps use a use case to spell out intended use from a perspective of say Emergency Dept use case. It was suggested to have two levels of testing, one for the base NHIN E platform specs, and an additional layer for profiles.
 * Response:**

New text: Normative: This attribute is CONDITIONAL. It MUST be specified when the InstanceAccessConsentPolicy attribute is specified in an Authorization Decision Statement. It is optional otherwise. 

Non-normative: It is expected that profiles will further constrain the optionality of this attribute. The process of obtaining a PID is defined in the xxxx specification. If the patientid transmission could be considered a disclosure, then it is suggested that the identified be pseudonymized. Explain that the pid is useful/required to retrieve the associated policy. ||  ||   ||   || • 3.3.2.1 OCSP …. If a given NHIO elects to use OCSP-based certificate revocation detection, then that NHIO’s initiating and responding gateways MUST support NHIN policy with respect to latency, frequency of updates, and availability, as contained in the DURSA. • 3.3.2.2 CRL…. If a given NHIO elects to use CRL-based certificate revocation detection, then that NHIO’s initiating and responding gateways MUST support NHIN policy with respect to latency, frequency of updates, and availability, as contained in the DURSA.
 * 11/18/2010 || Joe Lamy || Messaging Platform || Participants are required to use either OCSP or CRL to check for revoked certs. Spec excerpts below:

There doesn't appear to be anything in the DURSA or its related documents defining the NHIN's "policy with respect to latency...". Is there such a policy?

ejh: Duplicate question. See below. ||  ||   ||   || It would seem that when a responder is doing a reverse query/retrieve in order to obtain a referenced access consent policy, they could conceivably pass their own ACP reference. If both parties do this it could cause an infinite loop. Is there any guidance on avoiding this?
 * Response:**
 * 11/29/2010 || Joe Lamy || Authorization Framework || [authfw-6]

Question: Can both an initiating and responding gateway have ACPs? We may have created a situation whereby which it is not obvious how to create ACPs on both initiating and responding. Requires more research. Should be addressed as future NHIN participants may indeed need the capability to exchange ACPs from both the initiating and the responding gateway perspectives. ||  ||   ||   || I believe patient identifier (i.e. Resource-id) is a required attribute in the SAML header for QFD requests, as they pertain to a patient. But in an ACP query scenario this is a problem: 1. NHIE A sends PD request to NHIE B, including ACP reference in the SAML 1.1. NHIE B sends QFD request to NHIE A to find the ACP 1.2. NHIE B sends RD request to NHIE A to retrieve the ACP 1.3. NHIE B processes the ACP and makes the access control decision for the PD request 1.4. NHIE B returns PD response containing PID to NHIE A
 * Response:**
 * 12/2/2010 || Joe Lamy || Authorization Framework || [authfw-7]

I think in step 1.1, NHIE B is supposed to pass their PID in the SAML, but they don't make the access control decision on providing this PID until step 1.3. Catch-22.

I'd like to suggest the way to resolve this is not to require PID for QFD requests that are getting a referenced ACP, but that just seems to lead to other catch 22s.

If implementers are using TP-30 to obtain the access consent policy. So the implementers are cautioned to not supply the patient ID in the SAML patient id attribute. The local PID is not required for a query/retrieve for a consent policy. ||  ||   ||   ||
 * Response:**
 * 11/24/2010 || RI Team || Messaging Platform || **Document Section Excerpt -**

2.2 Design Principles and Assumptions
… 3. Messages between NHIOs must be secure. This will necessitate the use of encryption as part of the message transport layer.

“Encryption” and “Secure” are too broad and not answered by actual design elements later in the spec. Instead, please refer to “digital signatures” and “trusted and non-repudiatable” design elements. Please provide specifications on above requested design elements.
 * Question:**

3. Messages between NHIOs must be secure. This will necessitate the use of encryption as part of the message transport layer. __Implementations MUST use secure transport as defined later in this specification.__ Status: Closed ||  ||   ||   ||
 * Response:**
 * Ejh: The Sec & Priv WG believe the above text is largely appropriate since it is a guiding principles section. However, we suggest adding a reference to the AF such as the modified paragraph below:**
 * 11/24/2010 || RI Team || Messaging Platform || **Document Section Excerpt –**

2.2 Design Principles and Assumptions
… 8. In certain well-defined cases, an NHIO may assert specific policy constraints with respect to the invocation of their web services.

Please clarify the intent of the bullet above. The assumption made is that no RI coding effort is needed. Please confirm.
 * Question:**


 * Response:**
 * Ejh: Incorrect. The RI should include a call to an empty class or method or function that will return a Boolean value indicating if the request should be honored. This empty function needs to be called prior to invoking web services requests. If the function returns TRUE then the web service should be invoked. If the function returns FALSE then the web service should not be invoked. The parameter to the function should be a complete copy of the SOAP message to be communicated ideally, or at least the  of the SOAP message. Note: This is guidance to the RI and other teams, it is not normative text for inclusion in a specification.**

Status: Closed ||  ||   ||   ||
 * 11/24/2010 || RI Team || Messaging Platform || **Document Section Excerpt –**

2.2 Design Principles and Assumptions
… 8. In certain well-defined cases, an NHIO may assert specific policy constraints with respect to the invocation of their web services.

Please define the type of policy constraints an NHIO may assert. Any kind, or only those covered by SAML and XACML?
 * Question:**


 * Response:**
 * Ejh: Please create a function in the RI as per the prior question. This will, as an intentional side-effect, allow an entity using the RI to insert arbitrary policy constraints on the process of initiating or responding to requests. It should not be limited to XACML, XSPA, SAML. For example, it may use a rule related to the content of the payload such as “don’t deliver a CDA document containing behavioral health information to anyone not on a whitelist”.**

Status: Closed ||  ||   ||   ||
 * 11/24/2010 || RI Team || Messaging Platform || **Document Section Excerpt –**

The assumption made for common trusted Certificate Authority is Entrust. Please confirm.
 * Question:**

ejh: **Incorrect. The Certification Authority (not a Certificate Authority) is NOT assumed to be any particular vendor. It may change to another vendor, or it may be someday hosted by the ONC using other software implementations. Question to the RI team: Why do you need to know this information?**
 * Response:**

From the RI team: They are seeking to learn the details of the CA, such as the services they provide, the CRL, the OCSP responder network details, etc.


 * Status: On going issues** ||  ||   ||   ||
 * 11/24/2010 || RI Team || Messaging Platform || **Document Section Excerpt –**

3.3.1 Certificate Verification and Revocation
… NHIO’s initiating and responding gateways MUST support NHIN policy with respect to latency, frequency of updates, and availability, as contained in the DURSA.
 * OCSP…**
 * CRL…**

We understand the DURSA link is as follows: @http://healthit.hhs.gov/portal/server.pt/document/910759/dursa_2009_version_for_production_pilots_20091118_pdf Please provide the sections in the DURSA which refer to the NHIN policy mentioned above.
 * Question:**


 * Response:**
 * Ejh: The text probably should change slightly to reflect that the DURSA is a document outside of our strict control. A number of similar policy issues that have technical implementation overlap are referenced in the various NHIN specifications as well. I suggest that we have some standard text such as “as may be contained in the DURSA. In the absence of such policy in the DURSA, implementors must x, y, and z.”.**


 * John M: Suggested this be categorized as an operational issue, and potentially be removed from the technical specifications. Should this be moved into an operational document of some type? Should be also driven by the life-critical nature of the NHIN Exchange. Is it 99.9% availability for all services? 99.99%.. Suggests that we make these types of parameters configurable. Ex. "If you are caching OCSP or CRL caching, it should be configurable".**


 * Benson: "Performance requirements will be defined by use cases". Probably pull this content into a new operational document.**


 * Update: I added a suggestion in a new Wiki page regarding NHIN Documentation Guidelines.**

ejh: Suggested that the RI provide configuration options for the 1) ability to check for each request (Bool), and 2) max time allowed between cert revocation checks. And that this be moved to the new doc guidelines page. A) The RI should first enxure the cert was issued by a trusted CA, b) that the cert is within its validity period; and c) has not been revoked as per a CRL or OCSP check.


 * Status: Pending; issue needs to be moved to the operational guidelines page.** ||  ||   ||   ||
 * 11/24/2010 || RI Team || Messaging Platform || **Document Section Excerpt –**

…
The cipher suite recommendation from the OASIS committee for SAML2.0 over the TLS protocol was for forward looking applications to implement TLS_RSA_WITH_AES_128_CBC_SHA, which has both speed and security strength. 1 This translates to the Basic128 algorithm suite as defined in the WS­SecurityPolicy 2 and is declared within the sp:AlgorithmSuite assertion …

Please confirm the Implementation of TLS_RSA_WITH_AES_128_CBC_SHA and sp:AlgorithmSuite asserting Basic128 is a requirement.
 * Question:**

Ejh: This is a known problem. The intent behind this was to establish a baseline, not a single accepted method. It has been proposed that all FIPS-approved crypto modules be listed in the WSSecurityPolicy. The implementations would be guided to ensure their TLS encryption is properly configured to only support those algorithms actually supported by their specific implementation. The Spec Factory should publish the associated WSDLs. I suggest that the MP spec be modified to remove this and instead to state that the implementation must implement TLS or SSL per the Authorization Framework. The AF will probably have text similar to the following in the next iteration:
 * Response:**

“Normative: Organizations utilizing this specification MUST employ an x.509 mutually authenticated secure channel using a FIPS-approved implementation of SSL or TLS. Organizations MUST use a NIST validated cryptographic module for encryption of data on this channel and MUST use a FIPS-approved key exchange method. This secure channel MUST be operating in FIPS-approved mode as per [] or its successor document.

Non-normative: This list, which is actively maintained by the NIST as of this writing, is the authoritative source of which products, modules, and modes are approved for use by the NIST for Federal Information Processing. This list, or its successor, should be periodically reviewed for updated information as part of each organizations' internal best practices. Since security is a very dynamic area of the industry, we anticipate that the FIPS guidelines will change while this specification is still in effect and implementers are cautioned to create their implementations in such a way that the version of SSL and or TLS, and its associated configuration, can be changed to reflect updated NIST / FIPS security requirements and best practices.”

John M/Tom D: Suggests that we list a specific set of security policy AlgorithmSuites and that the operational guide (to be written) states "implement anything you want provided it is at least a superset of the listed suites, and is compliant with NHIN policy".

From Tom D (is this the FIPS list as of a certain date):             <sp:TripleDesSha256 /> <sp:Basic256Sha256Rsa15 /> <sp:Basic192Sha256Rsa15 /> <sp:Basic128Sha256Rsa15 /> <sp:TripleDesSha256Rsa15 /> </wsp:Policy>

Proposed resolution: Update the WSDL to an agreed upon set of AlgorithmSuites. Reference the op guide in the spec test. A given organization can implement a different this list operationally as per current FIPS approved algorithms. John M> suggests separating capabilities from operations of an implementation. Perhaps have a single algorithm capability (for testing purposes), and one list for operations purposes.

Joe L: Would be satisfiable with a single algorithm for now for testing purposes.

Michael will determine which of the above algorithms are supported by their crypto family. ||  ||   ||   ||
 * 11/24/2010 || RI Team || Messaging Platform || **Document Section –**

3.4.2 Digital Signature Specification
Please provide an example with strong security measures for validating the signature of Assertion token.
 * Question:**

ejh: Please clarify the request. Are you seeking pseudocode, Java code, sample messages, or something else?
 * Response:**

Update: It was determined that the RI Team is seeking, ideally, all of the above. This is currently an outstanding task.

Status: Pending ||  ||   ||   ||
 * 11/24/2010 || RI Team || Messaging Platform || **Document Section –**

3.4.3 Subject Confirmation

 * Question:** Please provide an example that demonstrates a secure approach for Subject confirmation.

ejh: Please clarify the request. Are you seeking pseudocode, Java code, sample messages, or something else?
 * Response:**

Update: It was determined that the RI Team is seeking, ideally, all of the above. This is currently an outstanding task.

Status: Pending ||  ||   ||   ||
 * 11/24/2010 || RI Team || Authorization Framework || **Document Section Excerpt -**

2.2 Design Principles and Assumptions
… • The r e i s not a ss u m ed to be C r o s s P r o v i s i o n i ng of u s e r s be t w e en N H I O s

Explain what Cross Provisioning means in the bullet above.
 * Question:**

ejh: This may require discussion by the Sec & Priv team, but an initial response just for me, as opposed to the team, is that "cross provisioning", in this context, is referencing the management of the same human user across multiple domains. We intended for this text to indicate, that at that time we designed the NHIN 2010 specification set, we were NOT designing a solution for the management of human users across NHIN Exchange gateways.
 * Response:**

It was anticipated that NHIN E specifications would need significant revision to support this requirement. For example, implementing cross-gateway user features would potentially require using SAML differently, using IHE's XUA++, having an ONC-Hosted user directory (LDAP), implementing a provisioning method, implementing a synchronization method, etc. All of these were deemed out of **scope at that time**, as as of 2010-12-10, they still are out of scope. I fully expect that we may need to revisit this issue; but we largely driving by a process whereby which a "Sponsoring Organization" is required to move some new capabilities like this into our active backlog.

Status: Put a better non-normative description of the trust model into the specs. Distinguish between system level trust model vs. a end-user trust model. ||  ||   ||   ||
 * 11/24/2010 || RI Team || Authorization Framework || **Document Section Excerpt -**

2.2 Design Principles and Assumptions
• The initiating NHIO must include all REQUIRED attributes in each request. It is at the discretion of the receiving NHIO to decide which attributes to consider in it’s local authorization decision • The a ss e r t i on a tt r i b ute de f i n i t i ons s pe c i f i ed i n t h i s d o c u m ent a r e not i n t en d ed t o b e an e x hau s t i v e and r e s t r i c t i v e l i s t of att r i bu t es that m a y b e s pe c i f i e d i n the S A ML a ss e r t i on s. A d d i t i o n a ll y, t h i s do c u m ent r e c ogn i z es t hat s o m e i nteg r a t i on p r o f i l es m a y h a v e a ne e d f or c u s tom a ss e r t i on s tate m ent s , and d oes n ot p r e c l ude th e i r u s e.

Please show how the SAML specification allows/constraints custom assertion statements. Custom Assertions statements are related to must-understand attributes. Please clarify the relationship. We understand the custom assertion statement(s) must be recognized and agreed upon by both parties (HIOs) otherwise a SOAP fault will occur with a “MUST UNDERSTANDS” attribute. Is this assumption correct? Suggestion: The statement “ Additionally, t h i s do c u m ent r e c ogn i z es t hat s o m e i nteg r a t i on p r o f i l es m a y h a v e a ne e d f or c u s tom a ss e r t i on s tate m ent s, and d oes n ot p r e c l ude th e i r u s e. ” appears to be informational as opposed to a specification. We suggest this be noted as informational. Please inform us if the above assumptions are correct.
 * Question:**

ejh: (Needs Sec/Priv team review) Agreed.
 * Response:**

Status: Pending ||  ||   ||   ||
 * 11/24/2010 || RI Team || Authorization Framework || **Document Section -**

What is the expiration time for the timestamp? It can be inferred from the example that it is 5 minutes. Please expand upon the representation of Time stamp expiration.
 * Question:**

ejh (Needs Sec/Priv team review). Should be configurable.
 * Response: **

Pending ||  ||   ||   ||
 * Status: **
 * 11/24/2010 || RI Team || Authorization Framework || **Document Section Excerpt –**

3.2.2 Timestamp
… The w ss e11: T o k en T y pe at t r i bute i s u s e d to de cl a r e t h e t y p e of the r e f e r en c ed to k en f or S A ML v 2 .0. T h i s i s de f i n e d to be: [] [|. T]he <wsse: Ke y I d e nt i f i e r > has a V a l ue T y p e att r i b u te wh i c h de f i nes t h e t y pe of v a l ue c o nta i ned i n t h i s e l e m ent. F or S A ML v 2. 0 t h i s i s d e f i n ed to be: [|http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-] [|1.1#SAMLID] [|. T]he v a l ue c o nta i ned w i l l r e f e r en c e t h e S A ML A ss e r t i on ’ s i d e nt i f i e r. T he f o ll o w i ng i l l u s t r ates t he s y n tax of th i s e l e m ent:

The hyperlinks in the above paragraph are not working. Please provide correct links.
 * Question:**

ejh (Needs Sec/Priv team review). Propose to update the links ensuring that the referenced text has not changed. If the text has changed, then more review is needed.
 * Response: **

Closed ||  ||   ||   || **//3.3. 4 .1 S i gn e d I nf o E l eme n t//** The < d s : S i g n ed I n f o> e l e m ent i s a c on t a i ner w h i c h s p e c i f i es the < d s : C an o n i c a l iz at i o nM e th o d >, t h e <d s : S i g natu r eM e th o d > , a n d a < d s :Re f e r en c e >. It i s r e c o m m ended t h at E x c l u si v e C an o n i c a l i z a t i o n b e u s ed, [|h][|ttp://www.w3.org/2001/10/xml-exc-c14n#] [|.] U s e of E xc l u si v e C an o n i c a li z at i on e n s u r es t h at s i g na tu r es cr eated o v er S A ML m e ss ages e m bedded i n an X ML c o nte x t c a n be v e ri f i ed i n de p en d ent of that c o nte x t.
 * Status:**
 * 11/24/2010 || RI Team || Authorization Framework || **Document Section Excerpt –**

We assume the use of Exclusive Canonicalization is mandatory. Please confirm.
 * Question:**

ejh (Needs Sec/Priv team review): Agreed. This is also consistent with the current implementations in production today, and with the trial II implementations. I propose we change the spec text from:
 * Draft Response: **

<!--[if gte mso 10]> "It is recommended that Exclusive Canonicalization be used, [|http://www.w3.org/2001/10/xml-exc-c14n#]. Use of Exclusive Canonicalization ensures that signatures created over SAML messages embedded in an XML context can be verified independent of that context. "

to

"Normative: E x c l u si v e C an o n i c a l i z a t i o n MUST b e u s ed for XML-DSig as specified by the //W3CExclusive XML Canonicalization Version 1.0// specification..

Non-normative: Use of Exclusive Canonicalization ensures that signatures created for any sub-document (apex) of an XML document can be verified independent of the context. This capability is important to ensure that the substantive content of an XML sub-document can be validated as unmodified even if that sub-document is moved into a new document, or moved in relation to other content in the same document. One anticipated use of this capability is to allow intermediaries to add additional signatures or XML wrappers."

[Need to add to corrected references to this spec in the reference section section of the AF .]

Note: the URL has changed for the referenced W3C spec, http://www.w3.org/TR/2001/WD-xml-exc-c14n-20011120 with an automatic redirect to http://www.w3.org/TR/xml-exc-c14n/. The spec itself has changed from a status of "Working Draft" to "Recommendation". Need to determine if the associate spec text has changed as well. In general, I propose that we remove URLs from the body of the spec, and include them in the references section. Thoughts??

Pending ||  ||   ||   ||  The v a l ue of t h e R o l e att ri b ute s h a l l be a u r n :h l 7 - o r g : v 3:CE e l e m ent, s pe c i f y i n g t h e c od e d v a l ue r ep r e s en t i ng the i ss u i ng u s e r 's r o l e, c h o o s i n g f r om the v a l ue s et l i s ted i n the s pe ci f i c at i on. T he c ode S y s tem att r i b u te of t h i s e l e m ent m u s t be p r e s ent, and m u s t s pe c i f y the O ID of the S N O M E D CT c ode s y s te m, 2.16. 8 4 0.1 .1 138 8 3.6 . 96
 * Status:**
 * 11/24/2010 || RI Team || Authorization Framework || **Document Section Excerpt –**

In bullet 9, should Role element as opposed to a Role attribute be specified? See highlight above.
 * Question:**

Draft Response: ejh: (Needs Sec/Priv team review) Agreed. This is a class of similar issues that I've recently discovered as an implementer. The attributes all need an improved description.

Pending ||  ||   ||   ||
 * Status:**
 * 12/23/2010 || Joan Duhaime || Patient Discovery || **Document Section Excerpt -**

2.2 Design Principles and Assumptions
…
 * The initiating NHIO has identified other NHIOs likely to hold a specific patient’s information. Patient Discovery requests are not intended to be broadcast across the NHIN.

Please clarify what is meant by broadcast in the bullet above. Does this mean multi-cast is supported? We assume the Gateway PD initiation service will accept exactly one target HIO identifier.
 * Question:**

In this sentence "broadcast" means "sent to every NHIO participating in the NHIN". I don't know what exactly you mean by multi-cast as when a message is sent to many places there is some peice of software which does this distribution. Multi-cast might mean a particular way of doing this and broadcast does not imply any particular technology as it is implemented by the NHIO and not exposed in the transaction. What a "Gateway PD initiation service" will accept is internal to the NHIO and not defined or restricted by the specification. In fact, I can't say I know what a "Gateway PD initiation service" is, so I'm using guesswork in that last answer.
 * Response:**

Complete ||  ||   ||   ||
 * Status:**
 * 12/23/2010 || Joan Duhaime || Patient Discovery || **Document Section Excerpt -**

2.3 Triggers
An edge system seeking sources of health information for a specific patient which may be held by other NHIOs submits a patient discovery query to its NHIO’s Gateway.

Assumption made is that PD Request is provided to the Gateway using HL7 format. Please confirm.
 * Question:**

The implementation of that request is internal to the NHIO and not defined or restricted by the specification.
 * Response:**

Complete ||  ||   ||   ||
 * Status:**
 * 12/23/2010 || Joan Duhaime || Patient Discovery || **Document Section Excerpt –**

2.4 Transaction Standard
… XCPD has been constrained within this NHIN specification to exclude one of the described transaction modes.

Please confirm that the transaction mode excluded by this specification is Shared/National Patient Identifier Query and Feed. Reference to the section where it is described would provide clarity.
 * Question:**

Correct. This is described in Section 3.1.3.
 * Response:**

Complete ||  ||   ||   ||
 * Status:**
 * 12/23/2010 || Joan Duhaime || Patient Discovery || **Document Section Excerpt – **
 * 3.1.4 Specifying Patient Identifier in the Request**

When using the Demographic Query and Feed mode, Initiating NHIOs must provide the “primary” patient identifier within the Patient Discovery request.


 * Question:** Please confirm this is a requirement of the HIO and not the Gateway**.**

The requirement is on the transaction. The transaction has an initiator and a responder. I believe Gateway is a general term for both the initiating and responding parts, but generally the term is NHIO Gateway or NHIO Initiating and NHIO Responding Gateways. I have no definition of an HIO so cannot for sure answer this question but all requirements of the specification are on the gateway so I don't believe it puts any requirements on anything else, except in the sense that an NHIO contains a Gateway and therefore is bound by all requirements placed on the gateway. I recommend reading the NHIN Architecture document and hope someone on the NHIN team can provide a link. This may help explain the terminology being used in the specifications.
 * Response:**

Complete || : ||  ||   ||
 * Status:**
 * 12/23/2010 || Joan Duhaime || Patient Discovery || **Document Section Excerpt –**
 * 3.1.4 Specifying Patient Identifier in the Request**

When using the Demographic Query and Feed mode, Initiating NHIOs must provide the “primary” patient identifier within the Patient Discovery request. … In this independent query the roles of initiator/responder are reversed (reverse query).


 * Question:** Please confirm that the initiation of a reverse query is an option for the HIO and not the Gateway**.**

The initiation of a reverse query is an option. The specifications make not distinction between HIO and Gateway.
 * Response:**

Complete ||  ||   ||   ||
 * Status:**
 * 12/23/2010 || Joan Duhaime || Patient Discovery || **Document Section Excerpt –**

3.1.5 Demographic Requirements in Request and Response
… Required values //if available and if allowed// for the Patient Discovery Request and Response: (in both the request and response). · Address · PatientTelecom · Social Security Number

The ‘if’ qualification in the above statement contradicts the ‘required’ clause. Also, please clarify ‘if allowed’ clause, allowed by whom, and by what means? Referring back to the HL7 question -
 * Question:**

The value ARE required ONLY if they are available and they are allowed by policy. So, if the community/NHIO/Gateway is initiating a request, has access to the data for the attribute AND the policies of the community/NHIO/Gateway allow sharing of the data, then it is required to share it. If, on the other hand, either the data is not available, or a policy restricts sharing of this data, then it is not required. The same rules apply to the response.
 * Response:**

Complete ||  ||   ||   ||
 * Status:**
 * 12/23/2010 || Joan Duhaime || Patient Discovery || **Document Section Excerpt –**

3.1.5 Demographic Requirements in Request and Response
… Others values as listed in the IHE XCPD Cross Gateway Patient Discovery Transaction [ITI-55] are allowed but not listed here.

Please confirm if the above statement refers to the details listed under Section 3.55.4.1.2.1 in IHE document. Reference to the section that details the other values allowed would be useful. Table 3.55.4.1.2-1 lists all the attributes for a request. Figure 3.55.4.1.2-1 shows a diagram of these attributres. This content is in Section 3.55.4.1.2.2. The section you reference only lists the major attributes but not necessarily all of them.
 * Question:**
 * Response:**

For the response Table 3.55.4.2.2-1 lists all attributes, Figure 3.55.2.2-1 shows this in a diagram and this content is in 3.55.4.2.2.2.

Complete ||  ||   ||   ||
 * Status:**
 * 12/23/2010 || Joan Duhaime || Patient Discovery || **Document Section Excerpt –**

3.1.6 Returning Multiple Entries
**…** It is recommended that if the responding gateway has more than one close match it should return the special error condition, described in Section 4 “Error Handling”, which will suggest that the requesting community may want to address the matching issue through manual means

Please clarify that sub-section 4.2 describes the required error code “answer not available” for the situation described.
 * Question:**

No, that is not correct. That recommendation is referring to section 4.1 which requests the initiator to provide more demographic attributes so a better match can be identified. The wording is definately confusing there, since it refers to "manual means". The correct error with multiple matches actually depends on how close the match is. If the multiple matches difer by an attribute that the initiator chose not to provide, the Section 4.1 response would be appropriate, asking the initiator to provide this missing attribute. If no further attributes will help identify a single match then the "Answer not available" response would be appropriate. In fact, both errors should probably be accepted for testing but use of the 4.1 response may allow more matches outside of manual means.
 * Response:**

Complete ||  ||   ||   ||
 * Status:**
 * 12/23/2010 || Joan Duhaime || Patient Discovery || **Document Section Excerpt –**

3.1.6 Returning Multiple Entries
**…** It is recommended that if the responding gateway has more than one close match it should return the special error condition, described in Section 4 “Error Handling”, which will suggest that the requesting community may want to address the matching issue through manual means.

If Section 4.1 is the intended section, why does Section 3.1.6 refer to addressing the matching issue through manual means? Section 4.1 provides means for addressing the matching issue in an automated fashion. I agree the statement is misleading. In fact, it depends on the exact situation whether the 4.1 or 4.2 answer not available response is appropriate. If more attributes will allow for a match without manual intervention it would be good to attempt that, but it is not required of the responder.
 * Question:**
 * Response:**

Complete ||  ||   ||   ||
 * Status:**
 * 12/23/2010 || Joan Duhaime || Patient Discovery || **Document Section Excerpt –**

3.1.6 Returning Multiple Entries
**…** It is recommended that if the responding gateway has more than one close match it should return the special error condition, described in Section 4 “Error Handling”, which will suggest that the requesting community may want to address the matching issue through manual means.

If Section 4.2 is intended, is the code value ‘Answer Not Available’ error message to be used in this instance? Seems like a duplicate question. Please refer to other answers on this section.
 * Question:**
 * Response:**

Complete ||  ||   ||   ||
 * Status:**
 * 12/23/2010 || Joan Duhaime || Patient Discovery || **Document Section Excerpt –**

3.1.6 Returning Multiple Entries
**…** It is recommended that if the responding gateway has more than one close match it should return the special error condition, described in Section 4 “Error Handling”, which will suggest that the requesting community may want to address the matching issue through manual means.

The above contradicts IHE XCPD Section 3.55.4.2.3 Expected Actions Case 3. Please explain. I agree the wording is misleading. Case 3 assumes "more attributes might allow the Responding Gateway to return a match". That section should clarify wither this assumption is in play or not.
 * Question:**
 * Response:**

Complete ||  ||   ||   ||
 * Status:**
 * 12/23/2010 || Joan Duhaime || Patient Discovery || **Document Section Excerpt –**

3.1.7 Support for Health Data Locator
This transaction will not support designation as a health data locator. All responses will indicate “NoHealthDataLocator” as described in HE XCPD Cross Gateway Patient Discovery Transaction [ITI-55] section 3.55.4.2.2.5.

What is the Gateway to do upon receipt of a response indicating designation as a health data locator? Ignore it.
 * Question:**
 * Response:**

Complete ||  ||   ||   ||
 * Status:**
 * 12/23/2010 || Joan Duhaime || Patient Discovery || **Document Section Excerpt –**
 * 4.1** **Special Handling for More Attributes Requested**

If a responding gateway determines that additional attributes may help to achieve a match, it may respond with a specialized set of error codes. Refers to Table 3.55.4.4.2-4

The Gateway cannot determine that additional attributes may achieve a match – this is an HIO function. What is the Gateway processing sequence in response to these codes in a Response?
 * Question:**

If the initiator (whether Gateway or whatever an HIO is) cannot supply additional attributes then it must take alternative handling, presumably flagging the situation for manual processing.
 * Response:**

Complete ||  ||   ||   || The X509SubjectName format is used by nearly all Exchange participants for the Issuer and Subject elements, but we see some variations in how it is used. For example (taken from a single SAML assertion): <saml2:Issuer Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"> CN=John Miller,OU=Harris,O=HITS,L=Melbourne,ST=FL,C=US </saml2:Issuer> <saml2:Subject> <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">UID=kskagerb</saml2:NameID> ...
 * Status:**
 * 1/4/2011 || Joe Lamy || Authorization Framework || [authfw-8]

In RFC 4514, it doesn't appear that there are any restrictions on which relative distinguished names (e.g. CN) are included, and an empty string even appears to be legal. So we could see something like this: <saml2:Issuer Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"> ST=FL,C=US </saml2:Issuer>

As this name ID is being used to identify an individual (or a system), should the Exchange specs define some constraints on x509 attributes? Or do they already exist somewhere I haven't discovered?


 * Response**: The likely root issue is we are not using the SAML subjectConfirmation method correctly. We are "really" using the Sender-Vouches method, but our syntax is Holder-of-Key. Also, we are not clearly specifying which aspects (name/value pairs) of the x.509 cert are not specified for the NHIN. Outstanding: What should the test team validate vs. the the responding gateway? Suggested solution: "clean up" the specs to specify the use of sender-vouches subjectConfirmation method.

We plan on suggesting that the Test Team continue to inspect the x.509 Subject Name for certain requirement components. ||  ||   ||   || As per the SAML schema, the Assertion is a as: <element ref="saml:Issuer"/> <element ref="ds:Signature" minOccurs="0"/> <element ref="saml:Subject" minOccurs="0"/> <element ref="saml:Conditions" minOccurs="0"/> <element ref="saml:Advice" minOccurs="0"/> But it appears that some NHIN gateways are sending elements in a different order. ||  ||   ||   || - For the Reference/Transforms element, it lists 3 transforms that are allowed – this directly follows the list in saml-metadata-2.0-os.pdf, section 3.1.4. However, the WS-I Basic Security Profile, section 9.3, provides a list that only overlaps with the SAML list on one value: @http://www.w3.org/2001/10/xml-exc-c14n - Assuming both the SAML and WS-I specs are adopted in full, should NwHIN only allow the single value? - ||  ||   ||   || http://nhin-exchange.wikispaces.com/Auth+subject-id+Research There is a response suggesting that if an organization provides a lookup function to get from the Assertion/Subject element to the descriptive name, then subject-id (in the Assertion/AttributeStatement) should not be mandatory. 1. Is this the official spec factory position? Effective when? 2. Will there be language added to the specs? If it is effective now, will a tech note or errata be issued in the interim? 3. What does this mean for testing? If we find a missing subject-id attribute, should we in some way attempt to determine the existence of a lookup function? Will there be requirements on this lookup function that it be able to lookup any historical identity given the identity info supplied in the Assertion/Subject? Should we expect organizations to attest to the existence of such a lookup? ||  ||   ||   ||
 * 1/4/2011 || OCHIN || CONNECT? || The order of the elements appears to be incorrect as being sent by CONNECT.
 * 1/10/2011 || Joe Lamy || Messaging Platform || 3.4.2 Digital Signature Specification
 * 1/10/2011 || Joe Lamy || Messaging Platform || 2.4.2 Security Profile - Lists WS-I Security Profile 1.1, containing X.509 Token Profile 1.0, but in the WS-I Security Profile (Appendix A and others) it references X.509 Token Profile 1.1. Which version is correct? ||  ||   ||   ||
 * 1/10/2011 || Joe Lamy || Authorization Framework || Please clarify resolution of the subject-id issue, via a vis testing:
 * 1/12/2011 || Joe Lamy || Architecture || What would be the effect of a single system exposing two gateways? Would it be legal? Would it work? The intent would be that each partner would only use one of these gateways, and apply some criteria to determine which one to use. Would multiple HCIDs be needed or would there be multiple endpoints under the same HCID? If multiple HCIDs, would there be a problem with duplication of data, as both gateways would expose identical patient and document information?

Answer: It would be legal and confusing. I think different HCID's would be needed, while one gateway can service more than one HCID, the other way around would be confusing. Our current design assumes that if you have a HCID and query the Services Registry you will get at most one entry per type of service requested. Returning multiple entries for the same HCID and service requested will pose a challenge for other partners as they will not know how to decide between the services. On the other hand, if two services with different HCID return the same, or overlapping data, this is also confusing to partners using that service. It boils down to being confusing to partners wishing to communicate with duplicate services. If each of the gateways provides a distinct and non-overlapping set of services then the confusion is significantly reduced.

In your questions you state "The intent would be that each partner would only use one of these gateways". Well, if that is the intent then this would work. Expressing this intent introduces lots of fun challenges as it is a conceptual intent that we can't express in our current Services Registry. But at the end you say "If multiple HCIDs, would there be a problem with duplication of data, ..." which suggests that some partners might use both gateways, resulting in duplicate data. So, you can't have it both ways, either all partners magically know which gateway to ignore, or there is a confusing situation.

Status: Pending ||  ||   ||   ||

Answered Questions
Note: this section will disappear once we have agreed on a process for this. For now, kept previous items for historical puposses only.

The Query For Documents specification indicates the following in Section 3.2: Query Parameters, and am currently assuming that this applies to the XDS metadata that is returned in the Query for Documents response (even though it isn’t explicitly stated).“HITSP C80 defines value sets for document metadata elements requiring a coded vocabulary term for its value. This specification adopts the vocabulary for document metadata elements defined in HITSP C80.”
 * Tom Davidson || Query For Documents || XDS metadata:

Is there a mapping the explicitly states which HITSP C80 vocabulary set should be used for which IHE XDS DocumentEntry attribute? ||

The Query For Documents specification indicates that the HITSP C80 vocabulary sets should be used for the XDS Metadata attributes. - Is it permissible to use coded concepts that are not currently identified in the C80 document but are part of the same base vocabulary coding system? - Is it permissible to use a different vocabulary system other than the ones identified in C80? ||
 * Tom Davidson || Query For Documents || XDS metadata:

The IHE XCPD specification indicates that SOAP faults should be used to return internal errors (line 919 – 921). The current WSDLs do not define a SOAP fault, should they? ||
 * Tom Davidson || Patient Discovery || SOAP Faults:

What should the format code(s) be when the document entry is a native document and not a file that is wrapped in a CDA (e.g. – Word Documents, PDF, TIFF, etc)?
 * Tom Davidson || Query For Documents || DocQuery-3: XDS metadata:
 * [spec factory discussion] Considered using a copy of the mimeType content, an empty string or a specific format code indicating something described fully by the mimeType. Did not reach conclusion on this issue and will revisit next week. Revisited the issue and realized this is a new requirement and should be put through that process. ||

There appears to be a conflict between the point-to-point nature of mandated communication (no broadcasts) and the reference to the Cross-Community Patient Discovery protocol that suggests multi-node transactional processing of a single request. Also, the XCPD Draft itself seems quite unfinished and not worked on recently. We are trying to understand why an open-ended usage model would be forced upon an interface specification. Discussion key takeaways: - Specifications will be reviewed as Informative versus Normative. Informative sections serve to further describe the sepcifications. Coding will not be based on these Informative sections. - Reference (underlying specifidcations) documents should not be older than one year and should not be draft documents. If either situation occurs, locate a newer version of the document. ||  ||   ||   ||
 * 11/16/2010 || Joan DuHaime || Patient Discovery || PatDisc-2: Question discussed at 11/16/2010 Spec Factory Meeting:

1. If a PD request yields a match for this patient, are they required to return both PIDs in a PD response, or does local autonomy allow them to return two/one/none at their discretion, assuming there are no policy or access control problems? 2. Assume they only return one, then the initiator follows up with a QFD request with that PID. Are they permitted to return docs for both PIDs? 3. What is the requirement of returning addresses, must every address be returned, a single address?
 * 12/2/2010 || Joe Lamy || Patient Discovery, Query for Documents || Assume a NHIE has the same patient in two assigning authorities. A couple of questions:
 * Answer:** A variety of policies may inhibit return of both values but outside of policy I don't know how a implementation would make any decisions about this.
 * Answer:** As long as the PatientID metadata attribute references the single identifier sent in the QFD this conforms to the specification.
 * Answer:** The specification requires return of addresses that are available and "allowed" which means that no policy inhibits returning the address ||  ||   ||   ||

 **…** 9) **Org/SDO name:** OASIS
 * 11/24/2010 || RI Team || Messaging Platform || **Document Section Excerpt -**
 * Reference # / Spec Name:** WS-Security Policy
 * Version #:** v 1.2
 * NHIN Deviations or Constraints:**
 * Underlying Specs:**
 * Link:** [|http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/ws-securitypolicy-1.2-spec-cd­01.pdf]

The link provided above is not working. Please confirm link []. is correct:
 * Question:**

The link in the specification is incorrect. [] is the correct link. A change request needs to be created to address this for the specification.
 * Response: **


 * Ejh: Also need to update any other specs containing this link. I suggest that all specs, as part of their standard publication process, include a QA step to confirm that all embedded links are (still) functional and correct. Les Westburg suggests making a local copy which was agreed to as part of the NIEM process. **


 * Update: I added this to the new draft NHIN Documentation Guidelines page. ** ||  ||   ||   ||


 * 11/24/2010 || RI Team || Messaging Platform || **Document Section Excerpt –**

2.4.1 Basic Profile
… Use of WS-RM will be constrained to specific NHIN profiles and is not intended for use as part of every NHIN message…..
 * WS-Reliable Messaging**

For WS-Reliable Messaging the assumption made is, whatever App Server the RI runs in, must support WS-RM if specified in a WSDL. Please confirm.
 * Question:**


 * Response: KW: ** Yes – If specified in a WSDL, WS-RM is required. ||  ||   ||   ||

In a cross gateway query, supplying HCID in the AdhocQuery "home" attribute is optional. It is required to be specified in queries not taking a patient id (which take an entryUUID or uniqueID), so it is not required for FindDocuments. In a FindDocuments doc query, if it is supplied, does it have to be correct? //**Answer:**// It is not a valid argument to a FindDocuments query. So, strictly speaking, specification of home= on a FindDocuments query is not defined. This could be interpreted as an error or as something to be ignored. In any case, whether it contains the correct value is irrelevant. Whether it is an error to be there at all, or whether it should just be ignored, I don't know. I was looking for a statement about what happens to query arguments which are not valid ... is that an error or simply ignored. I cannot find the answer to that. I think they are ignored. But in this case maybe it should be an error, could be misleading to have the wrong one there. I will ask the larger IHE community on this one.
 * 12/10/2010 || Joe Lamy || Query for Documents || This is in the context of testing:

In the IHE XCA supplement, Figure 18.3.3 shows that the HCID in a doc query or retrieve is only used internally within a community, to allow a document consumer to tell its local gateway which remote gateway it wants to send a message to. Once the gateway sends the cross-gateway message, the remote endpoint is known and the HCID is not needed. //**Answer:**// This is just one use of the value but there are others. Beware that this section is INFORMATIVE and should not be taken as if it is normative specification material.

So if the local gateway finds the remote gateway correctly, why should we care if they pass an incorrect HCID? //**Answer:**// The XCPD specification states that the HCID specified for a query by entryUUID or uniqueID shall be the one corresponding to the Responding Gateway. So to supply a different one is not conformant with the XCPD specification. You should care because there are cases where the Responding Gateway may choose to use that HCID for its own internal processing and the specification was written to enable those use cases. For instance, a Responding Gateway may be supporting two local groups and using different HCID's to distinguish between them. In this case the HCID is used by the Responding Gateway to further route the query. ||  ||   ||   ||