TEST+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) Click the 'Discussion' tab at the top of this page
 * 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

 * Q: Sample question.
 * A: Sample response.

Messaging Platform

 * MsgPlat-1: 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.

Patient Discovery

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

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


 * DoocQuery-2: 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-3: 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-4: 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-5: 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-6: 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.

Document Retrieve

 * Q: Sample question.
 * A: Sample response.

HIEM

 * Q: Sample question.
 * A: Sample response.

include component="backlinks" page="TEST FAQ" limit="10"