Resolve #94

input/pagecontent/issues.md

@@ -36,7 +36,6 @@ These issues were known as part of the publication, and IHE invites comments.
 - PDQm_103: PDQm has a small volume 1 content. Thus breaking each H2 out into independent html files makes it harder to address. We might choose to do similar to PIXm and have just one volume 1 content with deep links.
 - [PDQm_issue_66](https://github.com/IHE/ITI.PDQm/issues/66): PDQm has allowed clients to use GET or POST search, and thus mandated that servers MUST support both GET and POST. The previous versions of PDQm had only mentioned GET search, but we learned that FHIR core mandated POST and does not allow us to not also mandate it. This leaves regions that want to use only one of these verbs for search seemingly forced to support both verbs for search. The current discussion in FHIR core offers that "support" could include implementing a "policy" that forces an http 405 response. This seems to be a workable solution, and the alternative would not be much different than this anyway.
 - [PDQm_issue_92](https://github.com/IHE/ITI.PDQm/issues/92): Currently we are mandating that Patient Demographics Suppliers support both ITI-78, with ITI-119 being OPTIONAL, while Patient Demographics Consumers have the option to choose to support either one or both transactions. Is requiring support for ITI-78 a problem for any Patient Demographics Suppliers?
-- [PDQm_issue_94](https://github.com/IHE/ITI.PDQm/issues/94): In PDQ, PDQv3, and PDQm ITI-78, we have the ability for the client to limit the search results to patients with an identifier issued by a particular patient identification domain. We do not have equivalent functionality in ITI-119. While a client could suggest that it is interested in a particular patient identification domain by including the assigning authority of that domain as an identifier system in the $match input parameters, the semantics of $match would not require the server to honor that request. Is this functionality needed in ITI-119?
 - [PDQm_issue_101](https://github.com/IHE/ITI.PDQm/issues/101):  Currently the expected actions for ITI-78 and ITI-119 require that all Patient Resources returned by the Patient Demographics Supplier conform to the [PDQm Patient Profile](StructureDefinition-IHE.PDQm.Patient.html). The PDQm Patient Profile inherits from IPA Patient, so the requirements for Patient in IPA are inherited. 
 Is this a reasonable requirement? While Patient Demographics Consumers SHOULD be robust in handling non-conformant Resources in the response, the intent of this requirement is to require that any Resources produced by the Patient Demographics Supplier are reasonably interoperable.  
 - [PDQm_issue_112](https://github.com/IHE/ITI.PDQm/issues/112) The `onlyCertainMatches` parameter MAY be optionally set to `true` to indicate that the Patient Demographics Consumer would only like matches returned when they are certain to be matches for the subject of the request. 
@@ -51,5 +50,6 @@ These issues have been decided and documented in the publication.
 - Upgraded to FHIR R4
 - Case 4, where one or more identifier domains are indicated by the client but are not authoritative by the server, has been extensively discussed. The conclusion is to stay with allowing a server to return 404 or 200, and to require an OperationOutcome to indicate a warning. There is concern that the clients might not notice that they did not get results for a domain they requested, the client MUST take the initiative to look for the OperationOutcome to determine if they got full authoritative results. This looking for an OperationOutcome SHOULD always be inspected to assure results are what was expected. As such we did update client requirements to explicitly look for patient safety reasons.
 - Removed the Pediatric Demographics Option as unnecessary and confusing. Most of the functionality needed for the use-case is natural part of the normal path of PDQm. The additional search parameters and extensions are allowed for those that need them. There has been little to no implementation of this option in the PDQ or PDQv3 environments. 
+- [PDQm_issue_94](https://github.com/IHE/ITI.PDQm/issues/94): In PDQ, PDQv3, and PDQm ITI-78, we have the ability for the client to limit the search results to patients with an identifier issued by a particular patient identification domain. We do not have equivalent functionality in ITI-119. While a client could suggest that it is interested in a particular patient identification domain by including the assigning authority of that domain as an identifier system in the $match input parameters, the semantics of $match would not require the server to honor that request. We do not believe this is likely to be an issue for real world implementations of ITI-119. 
 
 </div>