Spec+Factory+FAQ

toc =Frequently Asked Questions=

The purpose of this page is to provide a knowledge base of questions and answers by Subject Matter Experts. The page is organized by the approximate domain each issue resides within (some issues may span multiple domains).

Process:

 * 1) Prior to submitting a question or issue please first review the list of answered questions on this page.
 * 2) Also please check to see if your question or issue is currently under discussion by the spec factory
 * 3) If your question was not previously answered or currently not being discussed, please post it to the the discussion tab of this page.
 * 4) Find the Widget at the top left of this page (look for "edit"). Click the 'thumb tack' logo directly to the right of "edit," that is for tacking a new question to the discussion board. When you hover your mouse over it, it will say "View ### Discussion Posts".
 * 5) Click the '+ New Post' button, to create a new discussion item
 * 6) In the 'Subject Field' enter a short title for your question, please try to limit the title to 140 characters or less.
 * 7) In the 'Message Field' enter the full text of your question.
 * 8) If you would like to be notified when there is an update to your discussion thread, click the 'Monitor this topic' radio button
 * 9) Click the 'Post' button to submit your question
 * 10) If you can not create a new discussion you probably do not have a wiki account and will need to get yourself a wiki account at www.wikispaces.com
 * 11) The team leads will periodically review the discussion page, triage, and assign the issue to the correct domain team.
 * 12) The domain team will acknowledge the issue, and draft a response.
 * 13) The resolution will be posted on this page, under the appropriate category.
 * 14) If you would like to be notified about changes to this page, please use the Wiki "Notify Me" feature.
 * 15) Generally questions and their associated answers will be posted ordered by the frequency of occurrence and/or impact of the issue.
 * 16) Questions are numbered within each domain for easier reference during discussions but the numbers will change over time as this page is reordered.

Maintainers: This page is primarily maintained by each team lead.

Authorization Framework
>> The text in Authorization Framework v 3.0 published in August 2011 has been updated: “There is not assumed to be Cross Provisioning of users between NHIOs. That is, human end users are not expected or required to have identities defined in any NHIO security domain other than in the NHIO initiating a request. This principle is designed to avoid the need for the difficult process of synchronizing end-user identities across organizational boundaries.
 * AuthFwk – 001 (Spec Factory Issue ID 19): Please explain the term “Cross Provisioning” in section 2.2 Design Principles and Assumptions.
 * Answer: At that time the NHIN 2010 specification set was designed, we were NOT designing a solution for the management of human users across NHIN Exchange gateways. It was anticipated that NHIN Exchange 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 of the 2011 publication cycle, they still are out of scope. The NHIN Exchange may need to revisit this issue; but the NHIN is largely driven by a process whereby which a "Sponsoring Organization" is required to move some new capabilities like this into our active backlog through the exchange governance process.


 * AuthFwk – 002: Do custom assertion statement(s) need to be recognized and agreed upon by both parties (HIOs)
 * Answer – Yes

>> 1.) >> [|http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#relaysoapmsg] >> Example 3: SOAP Header with a single SOAP header block >>  >> > env:mustUnderstand="true" > >> 5 >>  >>  >> >> 2.) >> [|http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#soapmu] >> Example 6: SOAP envelope that will cause a fault if Extension1 or Extension2 are not understood >>  >>  >>  >> > env:mustUnderstand='true'/> >> > env:mustUnderstand='true' /> >>  >>  >> . . . >>  >> 
 * AuthFwk – 003: If custom assertion statement(s) are not recognized and agreed upon by both parties (HIOs) will a SOAP fault occur with a “MUST UNDERSTANDS” attribute?
 * Answer - Yes.Detailed information about the mustUnderstand attribute can be found in SOAP v 1.2 section 5.2.3 SOAP mustUnderstand Attribute: [|http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#soapmu]
 * Two examples of a the use of mustUnderstand attribute:


 * AuthFwk – 004 (Spec Factory Issue ID 9): If a Responding Gateway is performing a reverse query/retrieve in order to obtain a referenced ACP, they could, in theory, pass their own ACP reference to the Initiating Gateway. If both parties do this it could cause an infinite loop.
 * Answer: While this situation is theoretically possible, it does not warrant a change to the specification. Rather, this issue is best resolved, based on current use cases, by requiring that higher-level profiles NOT reference an ACP when they do the query of the original Initiating Gateway.


 * AuthFwk – 005 (Spec Factory Issue ID 123): What are our requirements in terms of trust? Are the original security requirements complete and do they reflect our current environment?
 * Answer: The Exchange is a use-case driven in terms of our requirements. At this time, no use cases have been advanced and approved that introduce additional security requirements. If such a use case were to be advanced in the future, and our current trust model is insufficient, then these additional requirements would likely result in an enhanced trust model.


 * AuthFwk- 006 (Spec Factory Issue ID 46): Namespace definitions in the Authorization Framework.The xsi namespace definition is missing in the Authorization Framework Specification v20 document. The namespace for xsi should be defined as " [|http][|://][|www][|.][|w][|3.][|org][|/2001/][|XMLSchema][|-][|instance] ". In section 3.3.2.5 and section 3.3.2.6, the example shows xsi:type="CE".
 * Answer: Name spaces, such as S11, are inherited by the Exchange specifications from the underlying base specifications and standards. See table 3.2.1 in the Authorization Framework 2010 production specification v2.0.1 for a list of some commonly used name spaces.

>> >> However, individual use cases such as the SSA claims and disability determination workflow, or the VA treatment profile, may indeed require these parameters to be honored. >> > CN=John Miller,OU=Harris,O=HITS,L=Melbourne,ST=FL,C=US >  >  > <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">UID=kskagerb</saml2:NameID>
 * AuthFwk-007 (Spec Factory Issue ID 179): In the underlying SAML specifications the SubjectConfirmationData element contains optional parameters NotBefore and NotOnOrAfter. It is not clear whether these are to be verified in all cases, to be verified only for certain methods (e.g. holder of key) or only optionally verified.
 * Answer: It is correct that the Exchange currently does not further constrain these parameters. Where the SAML specification is saying is that they have provided the means to communicate this element, but have not specified a policy. The IHE specification said that they must be populated. But still the IHE specification does NOT declare a policy. At this time there is not a reason for the Exchange spec factory to declare a policy. It is perfectly logical for each Relying Party to declare the policy that they feel is correct for the information they are hosting.
 * AuthFwk-008 (Spec Factory Issue 1): 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">
 * Answer: Reference Authorization Framework Production Specification v3.0 Section 3.2 Paragraph 4.

Messaging Platform

 * MsgPlat-001: 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.
 * Yes – If specified in a WSDL, WS-RM is required.


 * MsgPlat-002 (Spec Factory Issue ID 11): The Messaging Platform specification states in section 2.2 “Messages between NHIOs must be secure. This will necessitate the use of encryption as part of the message transport layer.” The terms “Encryption” and “Secure” are too broad; can they be clarified?
 * Answer: The text in question has been deemed appropriate since it is included in a guiding principles (a "summary") section. Messages between NHIOs must be secure. The NwHIN 2010 and 2011 production specifications specify detailed information with respect to the use of secure transport, encryption, and digital signatures. Please especially see section //<span style="font-family: 'Calibri','sans-serif';">3 Transport Definition // in the Messaging Platform Production specification version 2.0 dated 1/29/2010 and sections //<span style="font-family: 'Calibri','sans-serif';">3 Framework Definition // in the NwHIN Authorization Framework Specification v2.0 dated 1/29/2010 (or in subsequent documents).


 * MsgPlat-003 (Spec Factory Issue ID 12): The Messaging Platform specification states in section 2.2 “In certain well-defined cases, an NHIO may assert specific policy constraints with respect to the invocation of their web services.” Is any coding effort necessary to support this requirement?
 * Answer: Yes – an implementation probably would be well advised to have some type of logic allowing for a policy decision point that is invoked prior to allowing access to the requested service. This allows for the enforcement of local policy. If the policy decision allows such, then service should be invoked. If the policy decision responds in the negative, service should not be invoked. Note: This is implementation guidance and is not normative text for inclusion in NwHIN specifications.

> "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? >> The NwHIN's intent is to provide sufficient information to the responding gateway that any reasonable access control determination can be made reflecting associated local policy. Such policy decision could, for example, be based on local opt-in/opt-out consent decision with exceptions for various types of data sensitivities. >> >> If NwHIN Exchange members find that a given policy is not enforceable due to lack of required message attributes, that (those) members should present a change request to the NwHIN governance bodies. >>
 * MsgPlat-004 (Spec Factory Issue ID 13): With respect to the NwHIN Messaging Platform version 2.0 1/29/2010 specification, the following text excerpt reads:
 * Answer:
 * MsgPlat-005 (Spec Factory Issue ID 14): Is Entrust the common trusted Certificate Authority? The assumption made for common trusted Certificate Authority is Entrust. Please confirm. We are seeking information on the CA, such as the services they provide, the CRL, the OCSP responder network details, etc.
 * The Certification Authority (CA) is NOT assumed to be any particular vendor. One of the NwHIN guiding principals is that we are vendor independent as much as possible. In the future: a) the CA may change to another vendor, b) or the CA may be hosted by the ONC using other software implementations, c) their may even be multiple CA vendors, or d) similar other scenarios such as the use of the FBCA.
 * This issue would be addressed via an implementation guide or similar information to be provided by the current CA implementation team or vendor. It is likely that the answers to these issues will change as the vendor changes over time. In addition, we STRONGLY advise implementers to not make their realization dependent on a specific CA vendor. For example, an isolation layer between the check for the revocation logic, and the calling function is advised. In addition, the services to be called (CRL vs. OCSP) should be configurable, or configured via the capabilities specified in the cert itself (there are slots for this type of information in the cert).

> Example: > <soapenv:Envelope> > <soapenv:Header> > <NS3:Action>urn:ihe:iti:2007:CrossGatewayQueryResponse</NS3:Action> > ... > <NS6:To> > https://...<incorrect URL omitted> > </NS6:To> > ... > > What is the impact of this being incorrect? It doesn't appear to affect successful exchanges.
 * MsgPlat-006 (Spec Factory ID 130): Issue: In the context of a synchronous NHIN response message, we are seeing an address in the To element which appears to be invalid.
 * Answer: If a response message is flowing over an http backchannel (i.e. synchronous response) then its wsa: To MUST be some variant of Anonymous (e.g. WSA's Anon or WS-MakeConnection's Anonymous). It could also be absent- in which case the implied/default value is WSA's Anonymous.

Patient Discovery

 * PatDisc-001: SOAP Faults: 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 t hey?
 * Answer: ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2010/CPs/FinalText/CP-ITI-518-FT.doc changes to return an error response rather than a soap fault. This CP has several important fixes to Patient Discovery that implementors should review.


 * PatDisc-002: General: 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.
 * Answer: a) There is no mention of "multi-node transactional processing" in the specification and no clarity on what that concept means to the author of the comment. In discussion it seemed like Section 27.3.2 was being interpreted to imply some normative behavior. This section is labeled "Informative" and is useful only as an example of what could be accomplished using the specification, not what is required. b) The current XCPD Specification is a Trial Implementation version which means it is complete and ready for testing. It is not Final, in that if significant problems are identified it may be updated in technically significant ways. At this time no significant problems have been identified and it should be considered stable.


 * PatDisc-003: Multiple Assigning Authorities: Assume a NHIE has the same patient in two assigning authorities. A couple of questions: Part: 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?
 * Answer:
 * 1) A variety of policies may inhibit return of both values but outside of policy I don't know how an implementation would make any decisions about this.
 * 2) As long as the PatientID metadata attribute references the single identifier sent in the QFD this conforms to the specification.
 * 3) The specification requires return of addresses that are available and "allowed" which means that no policy inhibits returning the address.


 * PatDisc-004: Values for Option Column in Auditing Section: In section 5 of the Patient Discovery spec version 1.0.0.7 dated 02/07/2011(Tables 3.55.5.1.1 and 3.55.5.1.2) the RI team needs clarification. The values for column 'Opt' are not defined.
 * >Assumptions made are as follows:
 * >>'M' - mandatory
 * >>'C' - conditional
 * >>'U' – undefined


 * In the ‘Value Constraints’ column, some of the values appear to be ‘static’. Can those values be bolded and noted as ‘static’? Other values appear to be variable; can those be italicized? This would remove ambiguity in the spec. Where values are listed like E,V(2, RFC-3881, “Patient Number”) which value is used? Is it EV or one of the values in the parentheses? Also, for Table 3.55.5.1.1, ‘Where’ statement used for ‘Source’, ‘Human Requestor’, ‘Destination’ in each separate table, does this imply an ‘excusive or’ (XOR)?
 * Answer: The assumptions are correct as stated in the question. In version 2.0 of the Patient Discovery Specification dated 7/27/2011, the definition of the “Opt” column and its values has been included. U indicates that the optionality is inherited from the core specification and nothing is constrained at this level. The Event ID is a triplet. The notational convention of “EV(x, y, z)” is borrowed from the mathematical domain and is only intended to serve as a convent method to denote the options. The triplet is (Value, Code system, and Description of the Value.


 * PatDisc-005: Definition of Broadcast: 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.
 * Answer: 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 piece 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.


 * PatDisc-006: Is PD Request provided to the Gateway using HL7 format?
 * Answer: The implementation of that request is internal to the NHIO and not defined or restricted by the specification.


 * PatDisc-007: When using the Demographic Query and Feed mode, Initiating NHIOs must provide the “primary” patient identifier within the Patient Discovery request.Please confirm this is a requirement of the HIO and not the Gateway.
 * Answer: 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.


 * PatDisc-008: 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). Please confirm that the initiation of a reverse query is an option for the HIO and not the Gateway.
 * Answer: The initiation of a reverse query is an option. The specifications make no distinction between HIO and Gateway.


 * PatDisc-009: 3.1.5 Demographic Requirements in Request and Response: 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.
 * Answer: 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 attributes. 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.


 * PatDisc-010: 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.
 * Answer: 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 definitely 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 differ 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.


 * PatDisc-011: 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.
 * Answer: 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.


 * PatDisc-012: The below contradicts IHE XCPD Section 3.55.4.2.3 Expected Actions Case 3. Please explain. " 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."
 * Answer: 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.


 * PatDisc-013, Issue 74: Background: Our requirement CR_PD_5_003: The Audit log requires specific parameter values to correctly identify a transaction and log the Patient Discovery requesting and responding transactions in the audit log (Audit Record Repository).
 * 1) Are the following ATNA parameter values mapped correctly? Transactions in the Audit log (Audit Record Repository: Event – EventID for Patient Discovery is 110112, Event – EventTypeCode for Patient Discovery is ITI-55, Source – RoleIDCode for Patient Discovery 110153, DCM equals “Source”, Destination – RoleIDCode for Patient Discovery 110152, DCM equals “Destination”.
 * 2) How do we determine whether the Source is a Human Requestor?
 * Answer:
 * 1) These parameters are correct, review the XCPD profile p. 53 to see the complete information. If there are questions regarding understanding of this table please explain in detail any concerns.
 * 2) The “Human Requestor (if known)” (0..n) is there to hold a user identity “if one is known”. This recognizes that sometimes the requesting side could be a batch job that is doing pre-fetch based on the day’s caseload, thus there is no user initiating the request. If no user is initiating a request, then none is KNOWN.


 * PatDisc-014, Issue 99: Please check our understanding of the following: While testing with a gateway that omits the authorOrPerformer element from the Patient Discovery response, we discovered that CONNECT requires it to be present. Based on reviewing Patient Discovery, Version 1.0, Section 3.1.4 and "IHE IT Infrastructure Technical Framework Supplement, Cross-Community Patient Discovery (XCPD), Trial Implementation Supplement, August 10, 2009", Section 3.55.4.1.2.4, it would seem that it is NOT required in the response.
 * Answer: Section 3.55.4.1.2.4 specifies the PD request message so has no bearing on the PD response message. In “MFMI_MT700711UV01.xsd,” it says it is not required, and that it is defined as: <xs:element name="authorOrPerformer" type="MFMI_MT700711UV01.AuthorOrPerformer" nillable="true" minOccurs="0".


 * PatDisc-015, Issue 190: The following ticket has been created on the CONNECT Jira site: <<https://issues.connectopensource.org:8443/browse/GATEWAY-387>>.During the normal workflow the Responding Gateway generates a Patient Correlation record prior to the Response-Message going out the door. Once the Initiating Gateway receives the response it begins the verification process. If the verification process is unsuccessful (or FAILS) the Initiating Gateway does not create a Patient Correlation record. However, a valid and active Patient Correlation still remains with the Responding Gateway. The Patient Correlation record on the Responding Gateway remains active and would support future requests such as for Query for Documents (and subsequent Retrieve Documents requests once Query has completed successfully). We believe this represents a potential patient safety issue, as the initiating gateway determined they were not the same patient and should not be correlated.
 * Answer: This is a design challenge that can be solved in many different ways. The original Exchange approach was that the Responding Gateway which has saved the patient correlation record uses it only as knowledge that a correlation might exist in the initiating community. Before it were to initiate any query for documents type service towards the original initiating gateway community it would initiate a new patient discovery and use those results, replacing its prior patient correlation. In the IHE specification another approach was allowed for and not adopted by the original Exchange Patient Discovery Specification. This approach supports a "revoke" message which can be used by the original initiator to tell the responder to remove the patient correlation. Use of revoke eliminates the necessity of checking prior to use of each patient correlation.


 * PatDisc-016, Issue 192: XCPD constrains the underlying HL7 message types, for example in section 3.55.4.2.2.2 for the response message, it omits asPatientOfOtherProvider. However, in the table 3.55.4.2.2-1, there are more items missing than those specifically omitted, for example: patientPerson/asOtherIDs/scopingOrganization, or patientPerson/employee/employerOrganization. How should we interpret the items missing from this table?
 * Answer: The items are only omitted from the table for brevity; all items in the HL7 schema types not specifically omitted are inherited, and we will evaluate them.


 * PatDisc-017, Issue 195: Are coded fields in Patient Discovery request and response messages constrained by the values in the referenced HL7 code sets? For example, are the values for livingSubjectAdministrativeGender limited to "F", "M" and "UN"?
 * Answer: The standard allows extensions. Of course, if a system sends a query using an extension the responder knows nothing about the system may get fewer results than it would if it did not specify a value for that attribute. So, it would generally not make much sense, but it is not in violation of the standard. For example: http://www.hl7.org/v3ballot/html/domains/uvpa/editable/PRPA_HD201306UV-NoEdit.html#LivingSubjectAdministrativeGender. Which says "{CWE:D:AdministrativeGender}” . The "CWE" means it is a coded value "with extensions (WE)". CNE is No Extensions.


 * PatDisc-018, Issue 199: In HL7, the acceptAckCode element in the transmission wrapper tells the receiver whether to send an acknowledgement message. In the context of Patient Discovery (and IHE XCPD) deferred messaging, is this element intended to be used consistently with HL7, or is it unused/ignored in this context?
 * Answer: The change 2010 to 2011 on acceptAckCode was unrelated to the adoption of deferred. CP 557(ftp://ftp.ihe.net/IT_Infrastructure/TF_Maintenance-2011/CPs/Integrated/CP-ITI-557-FT.doc) documented a concern regarding acceptAckCode and research suggested that NE was a typo and it should always have been AL. The reason for this is that there is always an ask sent. In immediate it is an ack containing the response and in deferred it is only an ack. This value is not about whether a response is sent now or in the future but whether the sender should wait for an ack, which, in the case of the Exchange is always yes.


 * PatDisc-019, Issue 205: The Patient Discovery and IHE XCPD specs refer to a reverse Cross Gateway Query. Please clarify how this is used. IHE XCPD 3.55.4.1.2.4: "...a reverse Cross Gateway Query in search of data about the patient identified in the Cross Gateway Patient Discovery request". This implies that the reverse query is somehow related to the initial request (otherwise it wouldn't be a "reverse" anything, it would just be a Cross Gateway Query). Is it the intent that the reverse query is performed while in the process of responding to a Cross Gateway Query?
 * Answer: A "reverse query" is a Cross Gateway Query used after receipt of a Patient Discovery request.A Cross Gateway Patient Discovery request is very different than a Cross Gateway Query. Specifically:1.System A sends PATIENT DISCOVERY (NOT CGQ!!!) to System B.2. System B decides it CAN make a match and saves System A's homeCommunityId, patient id assigning authority, and patient identifier associated with system A's patient id assigning authority (see Section 3.55.4.1.2.4 in XCPD).3. System B decides at some random time (could be immediately or could be days/months/years later) to send a CGQ to System A by using homeCommunityId to find System A's service and the patient's identifier in the query. Both of these were found through the Patient Discovery request message (this is what is referred to as a "reverse query" for lack of a better term).


 * PatDisc-020, Issue 85: Is the asAgent element required in the sender element of a Patient Discovery response? CONNECT treats the asAgent element as required, but one of the applicants completing validation asserts that is not. The relevant specs seem to be: IHE Technical Framework Supplement, Cross-Community. Patient Discovery (XCPD) Rev. 2.1 2010-08-10, Sections 3.55.4.1.2.4 and 3.55.4.2.2.4.
 * Answer: asAgent in the sender element of the response is not constrained by the IHE XCPD specification or the Exchange specification. That means it reverts to following the HL7 V3 messaging standard, where it suggests it’s optional.As a follow up to this, the underlying Patient Discovery response XSD has the following definition for the asAgent element. <xs:element name="asAgent" type="MCCI_MT000300UV01.Agent" nillable="true" minOccurs="0" maxOccurs="1"/> Which indicates that the element IS optional.


 * PatDisc-021, Issue 25: Definition of Broadcast: 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.
 * Answer: In this sentence "broadcast" means "sent to every NHIO participating in the NHIN". I don't know what exactly is meant by multi-cast as when a message is sent to many places there is some piece 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.


 * PatDisc-022, Issue 26: Is PD Request provided to the Gateway using HL7 format?
 * Answer: The implementation of that request is internal to the NHIO and not defined or restricted by the specification.


 * PatDisc-023, Issue 164: When using the Demographic Query and Feed mode, Initiating NHIOs must provide the “primary” patient identifier within the Patient Discovery request. Please confirm this is a requirement of the HIO and not the Gateway.
 * Answer: 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 Exchange Architecture document and hope someone on the Exchange team can provide a link. This may help explain the terminology being used in the specifications.


 * PatDisc-024, Issue 30: 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). Please confirm that the initiation of a reverse query is an option for the HIO and not the Gateway.
 * Answer: The initiation of a reverse query is an option. The specifications make no distinction between HIO and Gateway.


 * PatDisc-025, Issue 31: Demographic Requirements in Request and Response: 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.
 * Answer: 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 attributes. This content is in Section 3.55.4.1.2.2. The section that’s referenced only lists the major attributes but not necessarily all of them.


 * PatDisc-026, Issue 32: 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.
 * Answer: 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 definitely 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 differ 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.


 * PatDisc-027, Issue 33: 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.
 * Answer: 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.


 * PatDisc-028, Issue 34: The statement below contradicts IHE XCPD Section 3.55.4.2.3 Expected Actions Case 3. Please explain." 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."
 * Answer: I agree the wording is misleading. Case 3 assumes "more attributes might allow the Responding Gateway to return a match". That section should clarify whether this assumption is in play or not.


 * PatDisc-029, Issue 36: What is the Gateway to do upon receipt of a response indicating designation as a health data locator?
 * Answer: Ignore it.


 * PatDisc-030, Issue 37: What is the Gateway processing sequence in response to these codes in a Response? The Gateway cannot determine that additional attributes may achieve a match – this is an HIO function.
 * Answer: 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.

> > Answer: Leaving out the entire element is what the specification intends. If one does specify the element, they must specify both root and extension. This is actually stated in several places in the IHE documentation, one of which is in the IHE PIX/PDQ V3 Section 23.5.
 * PatDisc-031, Issue 50: What is/are the accepted forms of leaving out the patient ID in a Patient Discovery request (i.e. using query only mode)? Since LivingSubjectId itself is optional, omitting the entire element seems to be what the spec intended. But a question came up about passing LivingSubjectId with a root and leaving the extension empty. The only clarification I could find is in the HL7v3 schema (II type), which says extension is optional. So the following would be legal in LivingSubjectId- Which of these are allowed for a Nationwide Health Information Network PD request, and what would each imply?
 * <value root="1.2.840.114350.1.13.99997.2.3412" extension="1234"/>
 * <value root="1.2.840.114350.1.13.99997.2.3412" extension=""/>
 * <value root="1.2.840.114350.1.13.99997.2.3412"/>


 * PatDisc-032, issue 35: "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.

Question: The above contradicts IHE XCPD Section 3.554.2.3 Expected Actions Case 3. Please explain. 12/23/2010, Joan Duhaime, Patient Discovery


 * Answer: I agree the wording is misleading. Case 3 assumes "more attributes might allow the Responding Gateway to return a match." That section should clarify whether this assumption is in play or not.

Document Query
See also Query for Documents Guidance and Query Guidance.


 * DocQuery-001: XDS metadata: 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. Is there a mapping the explicitly states which HITSP C80 vocabulary set should be used for which IHE XDS DocumentEntry attribute?
 * Answer: This mapping did not exist but has been created in response to this question, see XDS Metadata


 * DocQuery-002: XDS metadata: The Query For Documents specification indicates that the HITSP C80 vocabulary sets should be used for the XDS Metadata attributes. a)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? b) Is it permissible to use a different vocabulary system other than the ones identified in C80?
 * Answer: No, to allow this flexibility interferes with interoperability so participants must use the codes from C80. The codes are not intended to be universal, only to be high level. Right now this is what we must live with but expect a vehicle to be born to adjust the current set of codes. Also any sponsor can submit a new use case to adjust the set of codes.


 * DocQuery-003: XDS metadata: 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)?
 * Answer: At this time the values of format code are restricted to those specified in HITSP C80. The need for exchanging content that is not CDA should be submitted as a new requirement.


 * DocQuery-004: homeCommunityId: In a cross gateway query, supplying HCID (homeCommunityId) 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. A change proposal will be submitted to IHE requesting guidance on this undefined behavior. Pending that resolution the group has agreed that the home attribute should be not specified on a FindDocuments or equivalent query but if it is specified it should be ignored.


 * DocQuery-005: homeCommunityId: 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.


 * DocQuery-006: homeCommunityId: 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.


 * DocQuery-007: Incorrect doc ID format: We are seeing an incorrect format for the document unique ID value, where instead of an OID or OID^ext it is a UUID. This does not appear to affect the doc ID's subsequent use in Retrieve Documents requests. What is the impact? In cross gateway interactions, is the doc ID ever treated as anything other than an opaque string?
 * Answer: On the surface this is looks harmless. Except that many XDS/XCA/XDR mplementers validate the data format of all fields received in which case the message containing this identifier would be rejected as invalid. Interoperability requires the sender to conform to the defined data formats.


 * DocQuery-008: Patient ID: Query for Documents is intended to be patient specific. It is not clear from a review of the underlying IHE specs that non-patient ID specific queries are to be for objects which are all associated with the same patient.
 * Answer: ITI TF7-2a 3.18.4.1.2.3.5 - includes new language that requires responder to verify that all docs returned have the same Patient ID. Else NotSinglePatient error.


 * DocQuery-009: Missing XDSDocumentEntry attributes in TF3: Table 4.1-3. 1) parent DocumentRelationshipCode, parentDocumentRelationship and parentDocumentId are not in table 4.1-3, although two are mentioned in Table 4.1-8. Also, the reference in Table 4.1-8 says, "one of our values" when it should be five. 2) Are parentDocRelationshipCode and parentDocumentRelationship the same thing?
 * Answer:1) the "parent" in information was removed from the attribute list because it is not kept as an attribute but through an association object which is described elsewhere. A significant re-write of the documentation is being done and will address such errors. 2) ITI TF-3:4.1.6.1 page 11 (example directly after first instance of parentDocumentRelationshipCode, provided in the Wiki FAQ and available here: http://exchange-specifications.wikispaces.com/message/view/Spec+Factory+FAQ/50291730). parentDocumentRelationshipCode is the Classification within the Association. Nowhere in any XML are the names of these attributes ever used.


 * DocQuery-010, Issue 52 : Implementers (CONNECT and Kaiser) have raised two issues: Part 1- The language used in the spec to explain the condition for which this error code should be returned is unclear. Part 2- The requirements introduced by the specification of this error code extend well beyond the gateway and may even be incompatible with current Nationwide Health Information Network Gateway design. Broadly speaking, CONNECT presents the PID included in a QfD request to the Policy Decision Point (PDP), seeking an Approve or Deny to use that PID to obtain any and all information associated with the patient (including PID validity history). If the PID is invalid for whatever reason, it will not be recognized by the PDP, a Deny will be returned to the Gateway, which will return an empty list. In order to accommodate this (or any similar) error code, Implementers would be required to maintain a list of PIDs which are not currently valid, but that were previously valid and make that list accessible to the PDP. The PDP would have to be configured to return an Approve to the Gateway for whatever further processing would be required to return the error code. Kaiser dealt with the possibility of 'stale' PIDs by configuring their Gateway to re-discover when a blank list is returned. They only make a single attempt to rediscover so as not to get caught in a loop.
 * Answer: Initiator knows that if they get an empty list one of the following is true:
 * 1) a recognized PID has no records available. No further action is required, there are no records available.
 * 2) an invalid, never known PID was sent. This suggests the initiator is either on a fishing expedition or has an internal error. The first case we don't support and the second requires manual intervention to identify the internal error. Initiator knows that if they get an XDSUnknownPatient Id one of the following is true:
 * 3) A stale PID was found suggesting there might be a new patient identifier for the patient. In this case the initiator could send a patient discovery to find the new PID.


 * Whether to send a patient discovery request depends on the state of initiator. For instance if the PID is very fresh, i.e. just received in the last few minutes, then sending another patient discovery request might result in an infinite loop. Better to flag a potential error on responder side, as they should not be sending PIDs that become stale so quickly. b) The responder can't distinguish between a stale or invalid PID. In this caseinitiator must assume there is a stale PID, unless its internal state suggests otherwise. The cost of sending a redundant patient discovery request on an invalid PID is negligible and preferred over missing the data for a patient in the case of a stale PID. In fact, since an invalid PID should only happen from initiator fishing or internal error, it seems safe to assume that most of the time this indicates a stale PID. This approach simplifies processing by initiator and accommodates the needs of the responder. The cost of this approach is slightly lower security as fishing is not as easily discouraged if fishing attempts return errors rather than an empty list. Because of the many other mitigations in effect the risk of fishing is already sufficiently low that the mitigation of empty lists is already of only nominal effect.


 * DocQuery-011, Issue 87: On the QD wiki page (http://exchange-specifications.wikispaces.com/Query+for+Documents+Home) there is a helpful mapping from the XDS document metadata elements to the HITSP C80 values and schemes. Two questions:
 * The mapping for eventCodeList is TBD. Please provide this mapping.
 * Will this information be rolled into the QD spec at any point?
 * Answer: The mapping for eventCodeList has been updated.Integration into the QD spec is a process question (not a technical question) which is not covered here. A helpful discussion to reference:Discussion:
 * Exchange use of XDS
 * XDS introduces the concept of an “affinity domain”, where members agree to use the same vocabulary etc...
 * An affinity domain holds to the following principles:
 * At any given point in time there is a defined vocabulary for all new coded metadata for the affinity domain.
 * This vocabulary can and will change over time.
 * The vocabulary currently in effect SHOULD be used when adding new documents (either through XDR or via other means). Non-normative: this supports the use caseof merging existing systems, allowing mass imports of documents from systems with non-conformant metadata.
 * The vocabulary currently in effect MAY be used when querying for documents and responding to queries. -Non-normative: this allows flexible querying of the longitudinal record.
 * The Exchange constitutes an XDS affinity domain.
 * The vocabulary is defined as follows (insert table from QFD wiki with references to C80).
 * Document Submission: If documents are submitted with non-conformant coded values, the Document Receiver SHOULD return a warning. Non-normative: this could be a case where the submitter has simply failed to adopt new values and needs to change them, or where there are new proposed values that have yet to be added to the affinity domain, but should be accepted. A warning allows either case.
 * Query For Documents: Initiating communities are not required to limit their searches to the vocabulary currently in effect. Responding communities are not required to return XDS metadata conformant to the vocabulary currently in effect.


 * DocQuery-012, Issue 87b: Could the vocabulary version change within a given Exchange Specification period? e.g. If a gateway is operating the Exchange Query for Documents V3.0 (Exchange Summer 2011 or V2.0) is it expected that HITSP C80 version would remain consistent across these gateways that operate at the same Exchange spec level? I noted that the HITSP C80 version 2.0.1 was published Jan 2010.
 * Answer: Vocabulary at the XDS/XCA level is a very fluid thing. These are typically not nailed down until specific document content is defined. And one must always recognize that a query in XDS/XCA is a query into the longitudinal record, thus all historic vocabularies must be supported. See an article on these topics: http://healthcaresecprivacy.blogspot.com/2011/11/xdsxca-testing-of-vocabulary.html


 * DocQuery-013, Issue 217 : Does support for On-Demand imply there’s support for concepts in queries (IHE ITI TF Vol2b)?
 * Answer: Initiating Gateways: Not required to formulate a query about “replace” associations. Responding Gateways- use on-demand and should be able to respond correctly to queries that target a “replace” association. It may choose to never return an on-demand entry in which case returning no elements to association queries is still valid. For responders, it’s pretty clear in the specsthat submission sets, associations and document replacement (via associations) are required to be supported by responding gateways.


 * DocQuery-014, Issue 217b: XCA Responding Gateway- are implementers allowed to substitute an internal mechanism that doesn’t reflect these XDS registry objects on subsequent queries?
 * Answer: An implementer of XCA Responding Gateway must only: “make available, as a Stable Document Entry in response to a Cross Gateway Query, every document created as a result of receipt of a Cross Gateway Retrieve which specified the uniqueID of an On-Demand Document Entry"..The question only really applies to XDS Actors. Perhaps the context is not clear.The requirement of an Association is coming from the Exchange spec only since IHE does not require the new version to be a replacement. There may be consequences of adding that additional requirement on top of IHE, but there’s not a need for a submission set because there’s no requirement saying an XDS system must perform that replacement.


 * DocQuery-015, Issue 149 : What is the relevance of/ rules around the requirements to support all 13 of Registry Stored Queries specified in IHE ITI TF-2a 3.18.4.1.2.4?
 * Answer: Addressed in IHE, see XCA Supplement section 3.38.4.1.2.3 Special handling of some stored queries. No update to the specification is needed.


 * DocQuery-016, Issue 143: Use of DeferredCreation for $XDSDocumentCreationStatus is implied, but is not included in the list of query parameters listed or referenced in the spec. Can it be used as a query parameter when seeking dynamic documents?
 * Answer: Exchange has extended the list of values In Query for Docs which may be used for the $XDSDocumentEntryStatus to include DeferredCreation, which may be used in Query for Documents query parameters.


 * DocQuery-017, Issue 144: Exchange Query for Documents is intended to be patient specific. It is not clear from a review of the underlying IHE specs that non-patient ID specific queries are to be for objects which are all associated with the same patient.
 * Answer: The ITI TF Vol. 2a documentation says that it restricts queries to be patient specific.


 * DocQuery-018, Issue 145: Practice Setting Code - no such listing in HITSP C80. Substitute Clinical Speciality instead?
 * Answer: C80 references can be found in the table at the bottom of http://exchange-specifications.wikispaces.com/Query+for+Documents+Home. This table may be a useful reference or even addition to the specification.


 * DocQuery-019, Issue 175: According to Query for Documents what is the correct response for the scenario when a person has been correlated but clinical data does not exist in the respective clinical repositories ergo the person is not a patient.
 * Answer: The proper response to a Query for Documents request which specifies a patient identifier that is known but has no clinical data is to respond with an empty list. Note: This does not mean a blank C32 can be returned, the Query for Documents transaction can never return a C32, blank or otherwise. Query for Documents returns a list of entries where each entry contains meta-data which describes an available document. An empty list is a list containing zero entries.


 * DocQuery-020, Issue 177: Section 3.38.4.1.4 in the IHE XCA Supplement states that the EventTypeCode the Initiating Gateway shall specify EV(“ITI-38”, “IHE Transactions”, and “Cross Gateway Query”). Just to be clear, is the "and" a requirement, or is this a conjunction added for better human readability?
 * Answer: The EventTypeCode is a complex data type (CodedValueType), not a string. EV is a type of macro we use in the documentation for more simple documentation. EV macro has three parameters: first the code value, second the code system identifier, and third a possible description of the code value used (descriptions are always informational as they are intended to be human readable, and recognizing global standards this human readability could be very different in different environments)


 * DocQuery-021, Issue 178 : When returning on-demand documents, what is an XCA responding gateway supposed to return for the problematic metadata values for on-demand docs: hash, size. Don't return anything, or use fake values like -1?
 * Answer: http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_On_Demand_Documents_Rev1-2_TI_2011-08-19.pdf, Section 3.61.4.1.2 lists the elements that are not applicable, i.e. not specified. Do not fill in -1 or similar fake values.


 * DocQuery-022, Issue 178b: Is the availabilityStatus constrained in any way for on-demand docs? In the supplement inserts for IHE ITI Vol3, section 4.1.2.1.1, a stable document can be approved or deprecated, but there are not any similar rules for on-demand in the following section.
 * Answer: availabilityStatus operates the same way as for stable documents. the prior use of it was found to be too confusing and clumsy for dynamic documents.


 * DocQuery-023, Issue 182: The IHE Supplement for On-Demand Documents calls out a new association type called "IsSnapshotOf". What is the ebRIM 3.0 Format of this association?
 * Answer: urn:ihe:iti:2010:AssociationType:IsSnapshotOf . This is not well documented and is being addressed in a re-write of the IHE specification.
 * DocQuery-024, Issue 182b: Query for Documents includes the On Demand Supplement, which "makes use of content from the Metadata Update Supplement". Does this imply that Query for Documents has incorporated the Metadata Update Supplement as well?
 * Answer: One can use Query for Documents with and without On Demand.Query for Documents includes the On Demand Supplement, which "makes use of content from the Metadata Update Supplement.” Does this imply that Query for Documents has incorporated the Metadata Update Supplement as well? What is the relationship between query for docs and metadata update? The actors involved - Document Consumer and Document Registry - both have options which declare their support for the new metadata update features. If the actor has declared the option, then the transaction "incorporates" the supplement. If the actors have not declared the options then it does not.


 * Yes, on-demand "makes use of content" from there, but the content it uses is well identified through the use of direct references to sections within that document. Any section not referenced is not used. Thus, the real question of what happens upon a mismatch is related to the on-demand supplement and this question is answered in the section "Compatibility with existing XDS/XCA Actors" on page 5 of the supplement.


 * DocQuery-025, Issue 183: It appears that the feature of associating documents from multiple patients with a single submission set creates downstream problems - please address these.Background:- IHE ITI TF Vol3: 4.1.4.1 says "All documents included by value in a Submission Set shall have their patientId attribute set to the same value. This restriction does not apply to documents included by reference." So a submission set may have documents from multiple patients- IHE ITI TF Vol2a: 3.18.4.1.2.3.7.9 (GetSubmissionSets) says: "If the Stored Query specifies a returnType of LeafClass then the Document Registry actor shall verify that all requested Submission Set objects to be returned will contain the same Patient ID. If this validation fails an XDSResultNotSinglePatient error shall be returned and no metadata shall be returned.". There is a similar restriction on GetSubmissionSetAndContents.Assume a document A (for patient C) that is associated with submission set B (for patient C) and submission set D (for patient E).
 * If a person calls for a GetSubmissionSet for document A and asks for LeafClass resultsit will fail with an XDSResultNotSinglePatient error. It appears the only way to query for its submission sets is to ask for ObjectRefs instead and then ask for LeafClass for one submission set at a time. Is this intentional?
 * If a person calls for a GetSubmissionSetAndContents for submission set D and asks for LeafClass results it will fail with an XDSResultNotSinglePatient error. It appears the only way to query for its contents is to ask for ObjectRefs instead and then ask for LeafClass for one object at a time. Is this intentional?
 * Answer: This is a problem that the IHE ITI technical committee needs to address through a change proposal.


 * DocQuery-026, Issue 183: Why do certain stored queries have this same caveat: If the Stored Query specifies a returnType of LeafClass then the Document Registry actor shall verify that all requested DocumentEntry objects to be returned will contain the same Patient ID. If this validation fails an XDSResultNotSinglePatient error shall be returned and no metadata shall be returned?
 * Answer: To meet the requirements of ATNA Logging, a SQ returning LeafClass metadata must return metadata for only one Patient ID. Any of the LeafClass objects (SubmissionSet, Folder, DocumentEntry)contain a Patient ID attribute. Associations do not. It looks like when this was written into the SQ definitions a sloppy copy/paste was done. Obviously, for a GetFolders query, it should say that all Folder objects returned must have the same Patient ID. Same logic for SubmissionSets. If a query returns multiples of SubmisionSet, Folder, DocumentEntry then those objects must contain the same Patient ID.


 * DocQuery-027, Issue 194: The Query for Documents and underlying IHE XCA/XDSspecs reference the ebXML 3.0 (ebRS and ebRIM) specs, but do not clearly constrain which parts of the ebXML specs are required. What is the extent of the scope required? Is a functioning ebXML registry required, or just something that behaves as one for the very limited transactions used by XDS? If a functioning ebXML registry, then which functions? Background: - IHE ITI1 states: "XDS…describes the configuration of an ebXML Registry in sufficientdetail to support Cross Enterprise Document Sharing.” This implies that what is required is not just the visible parts of the registry used by the transactions, but rather an entire functioning ebXML registry - otherwise no configuration would be necessary (nor possible, since the configuration itself uses other ebXML functions).- IHE ITI2a: 3.18.4.1.2.1: “This transaction uses ebXML Registry version 3.0.”- IHE ITI2a: 3.18.4.1.2.3: references "The ebXML Registry stored query facility (Invoke Stored Query transaction)"- The ebRS spec describes the stored query functionality in section 6.3, and iterative query support (which is also referenced by XDS) in 6.2. It also specifies many other functions for registries, for example SQL queries (6.4) and filter queries (6.5).
 * Answer: The intention is that the scope is something that behaves as if it were an ebXML registry (repository) for the limited transactions used by XDS. There are no behavioral requirement outside the transactions of XDS, like support for SQL query or precise configuration approach. But, in order to support the transactions the registry does require some configuration/initialization and this *could* be done through ebXML, or in some other way.


 * DocQuery-028, Issue 204: In IHE ITI TF3 are parentDocumentRelationshipCode and parentDocumentRelationship the same thing? If so, which is the correct name?
 * Answer: They are not the same. parentDocumentRelationshipCode was added in 2007 (it did not exist prior to that time).To show the distinction (documentation is extremely bad) see the example in ITI TF-3:4.1.6.1 page 11 (example directly after first instance of parentDocumentRelationshipCode).


 * Here is the example for reference:
 * <rim:Association id="ThisAssociation" associationType=" urn:ihe:iti:2007:AssociationType:XFRM" sourceObject="source" targetObject="target"objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Association” id=”ID_042”>
 * <rim:ClassificationclassificationScheme="urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3"classifiedObject="ThisAssociation"id=”ID_043”objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"nodeRepresentation="French"
 * <rim:Name>
 * <rim:LocalizedString value="Translation into French"/>
 * </rim:Name>
 * <rim:Slot name="codingScheme">
 * <rim:ValueList>
 * <rim:Value>Connect-a-thon translation types</rim:Value>
 * </rim:ValueList>
 * </rim:Slot>
 * </rim:Classification>
 * </rim:Association>


 * In this example parentDocumentRelationship is urn:ihe:iti:2007:AssociationType:XFRM.parentDocumentRelationshipCode is the Classification within the Association.Nowhere in any XML are the names of these attributes ever used.

> ebRIM 3.0 Section 2.5.9 states: "Each RegistryObject instance MUST have a life cycle status indicator." However, in the Query for Documents 3.0 Example Response (Appendix F), there are some RegistryObjects that do not emit the life cycle status (e.g. the rim:Classification and rim:ExternalIdentifier RegistryObjects). Further, the Association objects returned without status. >> >> Thus, by the rules of ebRIM, Classification and ExternalIdentifier are separately managed objects in the registry and carry the status attribute. They can be separately updated, deleted, versioned etc. >> >> This level of complexity was unmanageable in the early times of XDS so we settled on a subset of the semantics: >> >> XML nested form only (for these two attributes) >> Not separately manageable >> Don't carry the status attribute >> >> So in a sense, an XDS registry does a little less object management than a pure ebXML Registry in this area. Some registry implementations return the status attribute, some don't. The profile documents no reason for a client to look for it or any reason to interpret it. >> >> Obviously when XCA came along, this philosophy carried forward.
 * DocQuery-029, Issue 215: Question:
 * Answer: In ebRIM, there are two semantically identical but syntactically different ways to code the XML for Classification and ExternalIdentifier objects. They each contain an attribute indicating the object they annotate (either registryObject or classifiedObject). If they are coded as children of the object they modify (children as in their XML is nested inside the object they modify) then there is redundant indication of the modified object: by attribute pointer and by XML nesting.

As of 7/30, a CP was going to be submitted for this problem to IHE.

Document Retrieve

 * DocRetrieve-001: Both the February2010 and Summer2011 NHIN specifications support the concept of a document being generated at request time. The February 2010 specifications supported this via the Deferred Creation mechanism, while the Summer 2011 specifications provide support via IHE On-Demand and IHE Delayed Document Assembly Trial Implementation mechanism. Depending on a number of factors (number of documents, the volume of data, number of systems to interact with, and system load), the amount of time necessary to create these request time generated documents can vary greatly. In a production setting, we have seen times range from seconds to over 15 minutes. Additionally, for resource scalability purposes, many enterprises impose maximum transaction timeout limits that application cannot override (example: proxy servers will timeout an open socket after 5 or 10 minutes). Currently, the specification recognizes an XDSRepositoryBusy error code, but this error code may be too generic.
 * Answer: The current error code should be sufficient, as the requestor would not change its behavior if the repository for the responder were truly busy or was experiencing an expected delay assembling the response to the requestor…most likely the requestor would try their request again later. Having a more specific error code would only be necessary if the behavior of the requestor would change based on the different error code…in this case it would not.


 * DocRetrieve-002, Issue 207: Retrieve Documents, like Query for Documents, states that it "...does not require the “XDS architecture.” What exactly does this mean? More specifically, which of the following interpretations is valid:
 * A. For any implementation, the only thing required is external behavior functionally equivalent to the XCA Cross Gateway Retrieve transaction. What's inside the system (i.e. trigger + gateway + architecture + edge systems) is not in scope.
 * B. If an implementation uses XDS, then it is required to comply with all XDS requirements. If it does not, then interpretation A applies.
 * Answer: There is no functional difference between A & B as seen externally.


 * DocRetrieve-003, Issue 207: Is it the intent to require that an implementation that uses XDS MUST accept and process a Retrieve Document Set message from a Document Consumer as a trigger to its Cross Gateway Retrieve?
 * Answer: The assumption is too vague. An implementation may use XDS for some aspects and not XDS for others. If it is using XDS for the use case being tested, then it would naturally initiate retrieves through doc consumer. If not, then not. It doesn't matter externally how the transaction was initiated so it is a distinction without a difference.


 * DocRetrieve-004, Issue 219: RegistryError@location- Volume 3 (Section 4.1.13) states that the location attribute for registry errors should supply “the location of the error.. “ if appropriate.... In Vol. 2b (section 3.43.5) requires “@location contains the DocumentUniqueID of the document requested...In the XCA Supplement it mandates the location attribute to be set to homeCommunityID. Is the XCA supplement given preference over the others because it is the highest profile in the stack re: Retrieve Documents?
 * Answer: The language in Vol. 3 is generic across all uses of RegistryError and states that location is optional. For SPECIFIC uses of RegistryError there are requirements on the contents of location. Those requirements can be more strict than vol. 3, though, by making the value required and requiring specific contents.
 * Specifically- For Retrieve Document Set, a person MUST include in the location the DocumentUniqueId. The location attribute is any string so can be a concatenation of multiple types of information. For Cross Gateway Query a person sets the location attribute to the homecommunityid. For Cross Gateway Retrieve we see a perceptive conflict. This transaction inherits from Retrieve Document Set, so has the requirement on DocumentUniqueId, and also has the homecommunityId requirement. It’s preferable that the requirement reads "... shall include within the location attribute the ...". which would mean one would have both the DocumentUniqueId and the homecommunityId in the location element. This means the element is not machine processible, because how a person concatenates these values is not specified. But it is not our expectation that machines will be able to make use of this information and it still is the responsibility of the human debugger.


 * DocRetrieve-005, Issue 169: In Retrieve Docs 3.2: "The Retrieve Documents transaction can be described in the following three steps. Each step is described in detail in the XCA Supplement section 18.3.3." Where are the following 3 steps? Should this be reworded?
 * Answer: These three steps have been updated in the new version of Retrieve Docs and can be found there.

> > The use of the words "available until a subsequent request" is the reason for this question. Does this mean that an implementation could only persist the stable document until it is replaced by a subsequent Retrieve Document transaction? If so, this is a different interpretation of the On-Demand persistence that I had. I thought that once a retrieve was done and a document was created, the content must be saved for all future requests (see On-Demand Supplement Section 3.39.4.1.2). > > Just wanted to double check on that. Thanks.
 * DocRetrieve-006, Issue 216: Section 3.1.2 of NwHIN Retrieve Documents 3.0 states that "NHIOs that generate On-Demand documents by aggregating data from multiple sources must ensure that the generated document remains available until a subsequent request for that On-Demand document causes generation of a more recent version of the same content.."
 * Answer: Indeed, this is inconsistent. The Retrieve specification requires the implementation of the "Persistence of Retrieved Documents" which requires the availability as you describe.

Document Submission

 * DocSub-001, Issue 97: Doc Submission section 3.1 states "the Document Recipient is not required to register the document with XDS Registry and store it in XDS Repository upon receipt of document from Document Source". Later, section 4 adds error reporting requirements: "The conditions of failure and possible error messages are given in the ebRS standard and detailed in ITI TF-3: 4.1.13 Error Reporting". Drilling into these error requirements, the IHE specs require the "XDS Registry Adaptor" to validate the submission in ITI TF-3: 4.1.11, for example: "The adaptor shall verify that coded fields...contain valid XDS specified values..." Since there is no required XDS registry, is the intent of Doc Submission section 4 that the receiving NHIE MUST perform the validations, or MAY perform them?
 * Answer: The XDS Registry Adapter seems to be a component synonymous with XDS Registry actor, therefore, the requirement should not carry over to Document Submission. This opts for the MAY more so than the MUST.


 * DocSub-002, Issue 94: It seems that differences in auditing requirements exist between Doc Submission and the other specs like Patient Discovery and Query for Documents, beyond those which might normally be expected to be different. Are they intentional?
 * Differences:
 * 1) PD and QD have a section of the audit entry called "Query Parameters" (DICOM ParticipantObjectIdentification) that includes the actual query message, base64 encoded. The analogous Doc Submission audit section, "Submission Set" does not include the submission message.
 * 2) PD and QD have an optional section called "Human Requestor"; Doc Submission does not. Should there be a "Human Submitter"?
 * 3) In PD and QD, the Event section EventTypeCode matches the Query Parameters section ParticipantObjectIDTypeCode (for PD it is EV(“ITI-55, “IHE Transactions”, “Cross Gateway Patient Discovery”) ). In Doc Submission, the Event section EventTypeCode is EV(“ITI-41”, “IHE Transactions”, “Provide & Register Document Set-b”), while the Submission Set ParticipantObjectIDTypeCode is EV(“urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd”, “IHE XDS Metadata”, “submission set classificationNode”)
 * Answer:
 * 1) These differences are because a Query is different than a document submission. A document submission is easy to log exactly what happened. Whereas with a Query, the results of the query could be very large and include PHI. Thus when recording an audit event for a query we record only the query parameters and not the result. This presumes that if there is a question about what was returned, the query could be re-executed to see what the result would have been. This presumption does assume that the system being queried can be reset back to the state it had at the time the query happened. Generally Queries are interesting, but not as interesting as outright publication or use of full fidelity data. Generally the Query parameters are useful enough themselves, it takes a crafty person to do a query that is not self-incriminating.
 * 2) One is always free to add any information they have to the audit message. The templates urge that 'at least' x amount of information be 'attempted to be recorded'. This is also related to a case in document submission that’s very likely to occur- is not directly accountable to a human. They tend to be done based on event triggers. For example the internal submission and approval of the document will -trigger- the document submission. Is the human really submitting in this case? Their actions were used as a trigger, but the actual submission is more of a system submission. Either way it is expected that review of the audit event will show the submission, and if there is cause to wonder who caused the submission that other audit events elsewhere would indicate who. But as I said at the beginning, the human should be included.
 * 3) This question is unclear there is no answer for it as asked.


 * DocSub-003, Issue 88: The most recent version of Document Submission refers to IHE ITI TF Vol 6 and HITSP C80 1.2. Since the other specs (QD, RD) that utilize these have moved to Vol 7 and 2.0 respectively, should Document Submission do so as well?
 * Answer: C80 is providing the information for how to code the metadata carried in document submission. A table on the bottom of http://exchange-specifications.wikispaces.com/Query+for+Documents+Home has a clearer map to the relevant parts of C80.

>> the audit log event. The fact that the security-relevant-event is a transaction being rejected vs. >> the same transaction being accepted is simply attribute values in the audit log message. In the >> case of the transaction being rejected this is simply setting the fact that it was rejected >> (EventOutcomeIndicator) and why (EventOutcomeDescription). >> >> No- Operationally, failure messages are often needed to be turned off because of policy. So the >> system should also be configurable. This is further elaborated on this website: >> http://healthcaresecprivacy.blogspot.com/2011/11/document-submission-audit-requirements.html
 * DocSub-004, Issue 98: When a receiver of a Document Submission request encounters an error, the entire submission is required to be backed out (i.e. the operation is atomic). Is the receiver still required to log audit data in this case? Required not to? Permitted, but not required?
 * Answer: 1) IMO. If you receive patient data you should be required to audit log that fact. Regardless of whether or not the transaction failed, there still could be artifacts left in your system (like application logging) which could contain references to that data.
 * 2) The answer is "Yes" and "No." Yes- a system needs to have the capability to record

IHE

 * IHE-001, Issue 218: Are XDS.b options supported or disallowed in XDR and XDM?
 * Answer: They are not defined for XDR or XDM... but they are not specifically dis-allowed. Since there is no 'registry' that would track these attributes about document relationships/lifecycle; one would get undefined behavior. CP 472 documents the question related to XDR, the decision was to NOT declare these things as an option but to put language into the Document Recipient expected actions that state that if the Recipient cannot process a folder or replace request it would return a warning. A subsequent CP extended the replace only warning to apply to any association change.


 * IHE-002, Issue 186: ITI TF-3: 4.1.2 states: "ITI TF-2x: Appendix H defines the metadata to initialize an ebXML registry to serve as an XDS Document Registry." But Vol 2x, Appendix H is blank.
 * Answer: IHE deleted Appendix H and forgot to fix that reference, this is being addressed by a change proposal. The content of Appendix H was moved to Vol. 3 Section 4.1.11.2


 * IHE-003, Issue 187: In ITI TF-3: 4.1.13, line 732: highestSeverity is described as an attribute of RegistryError, when it is actually an attribute of RegistryErrorList.
 * Answer: This typo is being addressed by IHE.

> > Code example from specification follows: > > > – > > >  – > > > >
 * IHE-004, Issue 181: In XCPD Section 27.4.2: "All actors in XCPD shall be grouped with a “CT Time Client actor." Does this requirement apply to Exchange Gateways as well?
 * Answer: Yes. The requirement is there to assure that clocks within the system-of-systems are synchronized (capability to be synchronized) to a common time source. The reason is to assure that security audit logs can be correlated across the system-of-systems. It is also useful for other aspects of keeping good quality records.
 * IHE-005, Issue 209: 1) The PRPAIN201305UV02 request example on page 26 of the Patient Discovery Web Service Interface Specification V1.0.0.7 displays an Agent tag that is associated with the Device in the Sender element. When trying to replicate this tag using the HL7v3 API, a runtime error is thrown indicating that the Agent object cannot be associated with the Device object even though the API explicitly allows it.
 * IHE-005, Issue 209: 1) The PRPAIN201305UV02 request example on page 26 of the Patient Discovery Web Service Interface Specification V1.0.0.7 displays an Agent tag that is associated with the Device in the Sender element. When trying to replicate this tag using the HL7v3 API, a runtime error is thrown indicating that the Agent object cannot be associated with the Device object even though the API explicitly allows it.
 * IHE-006, Issue 232: I noticed that in section 3.18.4.1.3 of ITI TF Vol 2a, it says that the error code for a missing parameter in a stored query should be XDSStoredQueryParamNumber. However this contradicts the error code table in Volume 3 (Table 4.1-11), which states that the error for a missing required parameter should be: XDSStoredQueryMissingParam. Section 2.18 also contradicts the NwHIN spec which aligns with the information in Volume 3. Which spec is correct?
 * Answer: Vol. 3 is correct. 3.18.4.1.3 is a typo. The plan (per 8/1/2012) is to submit a CP to IHE to document this mistake.
 * IHE-006, Issue 232: I noticed that in section 3.18.4.1.3 of ITI TF Vol 2a, it says that the error code for a missing parameter in a stored query should be XDSStoredQueryParamNumber. However this contradicts the error code table in Volume 3 (Table 4.1-11), which states that the error for a missing required parameter should be: XDSStoredQueryMissingParam. Section 2.18 also contradicts the NwHIN spec which aligns with the information in Volume 3. Which spec is correct?
 * Answer: Vol. 3 is correct. 3.18.4.1.3 is a typo. The plan (per 8/1/2012) is to submit a CP to IHE to document this mistake.
 * IHE-006, Issue 232: I noticed that in section 3.18.4.1.3 of ITI TF Vol 2a, it says that the error code for a missing parameter in a stored query should be XDSStoredQueryParamNumber. However this contradicts the error code table in Volume 3 (Table 4.1-11), which states that the error for a missing required parameter should be: XDSStoredQueryMissingParam. Section 2.18 also contradicts the NwHIN spec which aligns with the information in Volume 3. Which spec is correct?
 * Answer: Vol. 3 is correct. 3.18.4.1.3 is a typo. The plan (per 8/1/2012) is to submit a CP to IHE to document this mistake.
 * Answer: Vol. 3 is correct. 3.18.4.1.3 is a typo. The plan (per 8/1/2012) is to submit a CP to IHE to document this mistake.


 * IHE-007, Issue 189: In the changes to ITI TF-3 in the XCA supplement, Table 4.1-11 is missing XDSResultNotSinglePatient for the XGQ and XGR transactions. Is this intentional?
 * Answer: As of the date of this writing, the table referred to only shows the changes to the table but was not the authoritative table. Since XCA is no longer a separate supplement as of August 2011, this problem no longer exists...there's one table.
 * Another error we identified is that every other error code that applies to SQ and /or RS is modified to also apply to XGQ and /or XGR. It is true that XDSResultNotSinglePatient. At last notice, the test team was to submit a CP to reflect this change.

> > I have not been able to find any statement in the specifications (NwHIN or IHE) that indicates either direction, which one could interpret as being allowed since it isn’t explicitly denied. > > One possible scenario I can think of where this might occur would be after a patient merge. > > The documents that were created before the merge still contain the previous patient identifier, Or, in this scenario, would one expect the metadata to contain the correct patient identifier, but the sourcePatientId would then hold the previous identifier?
 * IHE-008, Issue 224: Is it legal for the patient identifier information in the XDS metadata that is included as part of the Query For Documents response to differ from the patient identifier that is specified in the Query For Documents request?
 * Answer: Depends on the environment:
 * XDS Compliant - The return result would always be the same XDS Affinity Domain scoped Patient ID. This is however the responsibility of the Registry, the XDS consumer should presume the registry did their job.
 * XDS Sometimes- Reality is that often times the patient ID values in the Registry are not mathematically identical, but are deemed the same individual by some Registry logic. For example there are HIE vendors that do late-matching of patient IDs, thus everyone publishes using their local identifier only. This makes publication time easy. They then correlate on query time. THIS IS NOT IHE COMPLIANT, but not necessarily something that should break a document consumer. Thus one should 'presume' that all documents returned from a XDS query ARE the same patient, even if they appear to not be.
 * XCA- We must recognize that there is no single Assigning Authority (XDS Affinity Domain ID); thus one must presume that the XCA gateways have done their job correctly and returned only documents for the identified patient. But this is not a single harmonized ID.
 * Even though two SMEs both searched through XCA, this is the response which they both agree remembering upon and is the best guess at this time. It is assumed that the patient ID values returned may not be the same.

> > urn:ihe:iti:2010:StatusCode:DeferredCreation (Section 1.4 #3 Deviations, Section 2.3, and 2.6) > urn:ihe:iti:2010:StatusType:DeferredCreation (Section 3.2.2, Section 3.2.3 and Appendix examples) > > > Which is correct? >> >> IHE does not define this value so it is up to the NwHIN specification to decide what the correct one is. I can only reflect what would be most consistent with existing IHE specifications. IHE uses on-demand documents so does not use a value such as this and isn't expected to in the future.
 * IHE-009, Issue 225: The published Feb2010 Q4D spec provides two different URN's for the DeferredCreation constant.
 * Answer:urn:ihe:iti:2010:StatusType:DeferredCreation is the value most consistent with the style used for other values for availabilityStatus - example urn:oasis:names:tc:ebxml-regrep:StatusType:Approved.

> > I ask because in XCPD, assigning authority ID (used in a similar way to RID) is permitted to be equal to HCID, and there appears to be no architectural need for them to be globally unique, just unique within each context (i.e. HCID must be unique among other HCIDs; RID among other RIDs). > > My initial interpretation is that the spec wording is clear - regardless of whether it's architecturally necessary, HCID and RID are globally unique, while AAID is not, so HCID=RID would not be conformant. >> >> Globally unique is the terms we used to define the use of OID, UUID, GUID, URI, etc. These are schemes for arriving at a globally unique ID. The point is to make sure that the identifier can't be incorrectly used for two un-coordinated resources. If someone is going to go through the effort of coordinating, that is their choice. But if they assign the same value to two different things then they better take the responsibility for the problems that might bring. It should be discouraged, but I don't think it should be automatically considered a failure. Globally unique = unique in the context in which it is used, e.g. each HCID is unique among other HCIDs.
 * IHE-010, Issue 229: HomeCommunityID is described in IHE TF3: Table 4.1-5 as "globally unique", as is RepositoryUniqueID. Based on this, we should never see HCID=RID, but we have seen this. Would this be permitted?
 * Answer: Globally unique simply means that the value is unique, not that it is not used for multiple purposes. I am not sure that it should be viewed as invalid if a value for HomeCommunityID and RepositoryUniqueID are the same value.

Auditing
So one interpretation of the current requirements would be that the Exchange has already adopted the ATNA Audit Message spec, and that these mechanisms are required. Would this be the correct interpretation?
 * Aud-001, Issue 93: Numerous message specs that require audit logging refer to the ATNA Record Audit Event, in section 3.20 of IHE ITI TF Vol2a. This section defines not only information to be logged, but audit messages (with schema) and transport mechanisms as well. Do all these requirements apply to the Exchange, or is the intent to simply identify information to be logged? Other Exchange specs adopt the externally visible interfaces and behavior of IHE, but explicitly do not require IHE architectures like XDS repositories behind the scenes. Please clarify.
 * Answer: Yes, this is not well described. There used to be an Audit specification, but it was primarily a Query of the Audit Log. This model is totally different than IHE ATNA, and ultimately it was discarded as not describable or implementable.It would be ideal if the Exchange to adopt the IHE ATNA Audit Message specification formally. That is not to say that the Exchange must implement a central audit repository, the operational aspects on 'how' to make it work could be totally de-centralized, cascaded, or federated. The drawback to this is that the formal recognition would assure that everyone that is participating in the Exchange has the capability to be auditing in the fidelity defined in IHE ATNA, including the identified functional security trigger events.
 * Aud-002, Issue 93b: For testing purposes the following interpretation is given (of ATNA Record Audit Event, in section 3.20 of IHE ITI TF Vol2a), which seems to be a great balance between what is required today and what could be added in the future: “Validation testing will focus only on the information required for auditing, not the messaging nor the storage format used, as these are considered HIE- specific implementation details at the present time.” Some spec background/examples. Note that while this is a general question about auditing for all Exchange transactions, the pertinent requirements are at the transaction level. So using Query for Documents as an example:
 * Query for Documents: Appendix E: "Both the Initiating Gateway and Responding Gateway shall audit the Cross Gateway Query as described in Section 3.38.4.1.4 in the XCA Supplement."
 * IHE TF1 (from XCA supplement): Table 2-1: "Each XCA Actor shall be grouped with Secure Node Actor or Secure Application".
 * IHE TF2a: Section 3.20 defines the Record Audit Event transaction (which the Secure Node actor participates in), which specifies:
 * Two transport mechanisms (Syslog Messages over TLS or UDP) for the audit messages.
 * XML schemas for the audit records/messages.
 * The existence of an Audit Record Repository actor (but not necessarily a centralized one).
 * Behavior requirements on the Secure Node actor for transmitting the audit message.
 * Behavior requirements on the Secure Node actor for transmitting the audit message.
 * Answer: The IHE specification simply requires that the system be capable of recording the audit using the ATNA specification. It does not mandate that an operational environment use this specific audit logging method. The Exchange has not attempted to coordinate any security audit logging. The strategy is that everyone is responsible for their own audit logging. One would expect that operationally there should be some method defined for inspecting the audit log of a partner based on some specific evidence of abuse. At one point there was an audit log query transaction. This was withdrawn as it was not clear what the use-case was for this transaction. This transaction was the inspiration for an audit log query transaction that is specified in DSTU in HL7. To answer the question, yes, it should be tested for. The fact that there is no operational centralization, federation, query, or reporting; is simply a state-of-the-art. This is more due to security audit log not being high-priority right now. It will eventually become the highest-priority, and we will need to address it. This highest-priority will happen with some dispute, and we will need to figure out how to handle a dispute. Or it will be an accounting-of-disclosures or access-report; Ultimately something will happen and there will be a need to prove one way or the other.

Web Services Registry
>> >> However ONC will continue to collect the publickey values as part of the Nationwide Health Information Network on-boarding process in case it is ever decided to publish the information by some alternative means. Additionally, it should be removed because it is not needed the TLS SSL- They actually exchange the public keys as part of the handshake. There’s no use case for it right now, but the exchange is considering compatibility with the Direct project in the future. Thus, there is a potential future use case to store X509 public keys in the registry. Furthermore, the exchange has created a web services registry WG that is exploring this issue, and is currently seeking functional requirements from all production and candidate participants. >> >> Proposed Updated Version of the Specification can be found at >> http://standards-and-interoperabilty-specifications.wikispaces.com/file/view/NHIN%20Web%20Services%20Registry%20Production%20Specification%20v2.1.0.1.do
 * WebServices-001 (Spec Factory ID 146): Publickey Metadata for UDDI: According to the UDDI v3.0.2 the maximum field length for a tModel key value is 256 characters. Currently Web Services Registry Specification details the use of the publickey string to be stored at a tModel value for the tModle key uddi:nhin:nhie:publickey. The PKI certificates used by the Nationwide Health Information Network result in public key string greater than 256 characters, therefore they cannot be stored in raw string format in the UDDI.
 * Answer: The decision has been made to remove publickey information from the registry. The use cases for including such information have never been clearly defined, other than the desire for ONC to be a source of this information. Most uses of this information occurs during the initial 2-way SSL handshake usually by some mechanism within a Nationwide Health Information Network participants network (firewall, context switch, web server, ...). Other potential uses alluded to include the potential need for the information in some message encryption or digital signatures scenarios where that information is not available through other mechanisms.

>> >> In the scenarios #1 and #2, there should be a single entry in the UDDI registry pointing to the participants’ 2010 or 2011 endpoint respectively. In scenario #3, there are two potential implementations: >> >> No matter which implementation of scenario #3 a participant has, the best practice is to always have two entries in the UDDI registry to eliminate the need of any participant querying the registry to need to know ahead of time what implementation of scenario #3 has been selected by a participant. In the case Implementation Option #1, of a participant that supports both 2010 and 2011 versions of a web service on the same web service endpoint, those two entries would point to the same web service endpoint. In the case of Implementation Option #2, the two entries would point to the two separate web services endpoints that support the 2010 and 2011 version of the web services.
 * WebServices-002: Currently the Exchange supports two versions of specifications in production, January 2010 and August 2011. When searching the UDDI Web Services registry, how will an Exchange participant know which version of the specifications a particular web service endpoint supports?
 * Answer: There are 3 potential participant scenarios:
 * 1) support of just the 2010 specifications
 * 2) support of just the 2011 specifications
 * 3) support of both versions
 * 1) A participant supports both 2010 and 2011 versions of specifications on a SINGLE web service endpoint
 * 2) A participant supports the 2010 and 2011 versions of specifications on SEPARATE web service endpoints


 * WebServices-003, Issue 220: If the target-gateway generated the reference message woudl this be considered non-conforming against the specification (see below)?

WS-Addressing Action in Target-Gateway XDR Messages fo rREquest and REsponse respectively:

urn:ihe:iti:xdr:2007: ProvideAndRegisterDocumentSet-b

urn:ihe:iti:xdr:2007:ProvideandRegisterDocuemntSet-bResponse

WS-Addressing Action in Specification document for Request and REsponse respectively:

urn:ihe:iti:2007:ProvideandRegisterDocumentSet-b urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse
 * Answer: The urn without "xdr" is correct, the specification has the correct urn in it.

= =

ACCESS CONSENT POLICIES
> Part 2: Can we confirm that this scheme must be known, and must match? In other words, the party querying for the IACP cannot assume that a match on OID and a mismatch on scheme will return the document. = =
 * AccessConsent-001 (Spec Factory Issue ID 102): What scheme should be used for IACP OIDs?The $XDSDocumentEntryEventCodeList slot for document query requires both a code and a scheme according to IHE ITI TF Vol2a, Section 3.18.4.1.2.3.4: Coding of Code/Code-SchemePart 1: What scheme should be passed for IACP OIDs?
 * Answer: Currently people who are having this problem should refer to a document type (an IHE BPPC unstructured document, embedded PDF inside a CDA file) or document class code (57016-8). Be considerate that the updates to the latest BPPC IHE spec may change the vocab OID and may be too generic for a client’s purposes.

ADMINISTRATIVE DISTRIBUTION
> Is there a HITSP interop spec or capability that needs to be referenced by Admin Distribution, or does the Admin Distribution spec essentially fill this role?
 * AdminDist-001 (Spec Factory Issue ID 90): In HITSP T63 (referenced by Admin Distribution), section 1.4 says an implementation can only claim conformance to this spec in the context of conformance to an "overall HITSP Interoperability Specification or Capability".
 * Answer: Refer to the Exchange Administrative Distribution specification along with any Exchange profiles, it is likely they leverage this specification provide the required context.

> Please either provide the missing constraints in the text, or remove the reference to them. >> >> >> In Admin Distribution 2.0, the sample message in Appendix A shows a root element of t63Request: >> >> <t63Request xmlns="urn:oasis:names:tc:emergency:EDXL:DE:1.0"> >> <EDXLDistribution> >> ... >> </EDXLDistribution> >> </t63Request>
 * AdminDist-002 (Spec Factory Issue ID 89): Admin Distribution 2.0, section 3.6.7 includes this text: "For the purposes of this specification, at least one explicitAddress is required and those values are constrained as follows:". No constraints are provided, and the sentence is a fragment. It appears to be an editing error.
 * Answer: This was an editing error. At the specification level we only say that an explicitAddress is required. Profiles leveraging this specification are expected to provide guidance on the format and other constraints of the explicitAddress field


 * AdminDist-003 (Spec Factory Issue ID 92): Where is T63Request defined?
 * Answer: The underlying EDXL-DE specification only provides a schema to define this operation. Administrative Distribution had to use that schema to define a transport as well. T63Request is a carryover from previous iterations of the specification (wsdl) and can be ignored.


 * AdminDist-004 (Spec Factory Issue ID 100): This is RE: Version 2.0. When a receiver of an Administrative Distribution request encounters an error, is the receiver still required to log audit data in this case? Required not to? Permitted but not required?
 * Answer: Audit logging is required for the input and output of Patient data. It is not a rule, but suggested that a response that doesn't contain patient data is not strictly required. Of the options from the question "Permitted but not required" would be appropriate. The response would be at the HTTP level as defined by the specification.


 * AdminDist-005 (Spec Factory Issue ID 95): In Appendix A of the Exchange Administrative Distribution v 2.0 there is an example of a EDXL-DE request that contains a nonXMLContent block (see Binary document sample). This nonXMLContent block contains an embeddedXMLContent block. The underlying specifications (OASIS EDXL-DE v1.0 and HITSP T63 v1.1) and the schema does not suggest that the embeddedXMLContent block should be nested inside the nonXMLContent block. Please clarify why the example has this element inside the nonXMLContent block?
 * Answer: The example is incorrect. If one ignores the <embeddedXMLContent> element and treat its children as children of its parent then the example would be correct.

> 1. The only export and import audit events defined in table 3.20.6-1 of IHE ITI TF Vol2a are PHI Export and PHI Import. Since this spec is for pushing non-patient related messages, are these the correct audit events? If so, what should happen to the Patient section? > > 2. In other specs, more specific mappings from message concepts to DICOM structures are provided, either in the Exchange specs or in the underlying IHE spec. For example, the Patient Discovery spec repeats Section 3.55.5.1 of the XCPD Supplement, showing (among other things) that the EventTypeCode is EV(“ITI-55”, “IHE Transactions”, “Cross Gateway Patient Discovery”). I don't see a similar table anywhere for Admin Distribution; is there one? If not, please provide clarification for these logging requirements. >> EV("Exchange-AD", "Exchange Specifications", "Cross Gateway Administrative Distribution") would help clarify. Another option is to use a different Audit event with different metadata requirements. >> >> #2 - IHE constrains the EV values for both EventID and the EventTypeCode based on our reading of IHE section 3.41.7.1 of Vol 2b. I agree with you about your idea to specify AD values for the EV fields in the next version of AD. >> >>
 * AdminDist-006 (Spec Factory Issue ID 91): Two questions, regarding the Administrative Distribution 2.0 spec, section 5 auditing:
 * Answer: 1. The underlying specifications (see IHE Vol 2b Section 3.41), suggest the Patient section of the Audit entry is a required section. However, Admin Dist. messages are not patient-specific (see section 1.1 of Admin Dist. 2.0).2.In the next iteration of AD, Perhaps something like:

<span style="display: block; height: 1px; left: -40px; overflow: hidden; position: absolute; top: 11612.5px; width: 1px;">PatDisc-011: 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. <span style="display: block; height: 1px; left: -40px; overflow: hidden; position: absolute; top: 11612.5px; width: 1px;">Answer: 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.