Create Named Options per discussion in #92

input/fsh/capability.fsh

@@ -110,7 +110,7 @@ Mobile Patient Demographics Query [ITI-78]
 
 Instance: IHE.PDQm.PatientDemographicsSupplierMatch
 InstanceOf: CapabilityStatement
-Title: "PDQm Patient Demographics Supplier Actor implementing Match Operation Option"
+Title: "PDQm Patient Demographics Supplier Actor Implementing Match Operation Option"
 Usage: #definition
 * description = """
 The PDQm Patient Demographics Supplier Actor (server) requirements CapabililtyStatement expresses the requirements that SHALL be provided. This capability statement implements the Match Operation Option.

input/pagecontent/ITI-119.md

@@ -1,4 +1,4 @@
-This section corresponds to transaction [ITI-119] of the IHE Technical Framework. Transaction [ITI-119] is used by the Patient Demographics Consumer and Patient Demographics Supplier Actors. The [ITI-119] transaction is used to query on patient identity information and get back resulting Patient resources.
+This section corresponds to transaction [ITI-119] of the IHE Technical Framework. Transaction [ITI-119] is used by the Patient Demographics Consumer and Patient Demographics Supplier Actors that implement the Match Operation Option. The [ITI-119] transaction is used to query on patient identity information and get back resulting Patient resources.
 
 ### 2:3.119.1 Scope
 

input/pagecontent/issues.md

@@ -35,7 +35,7 @@ These issues were known as part of the publication, and IHE invites comments.
 - PDQm_102: Normative vs Trial-Implementation - Currently the HL7 FHIR standard components used (e.g., Patient, Bundle, etc) in this profile are at Normative state. Some portions of PDQm are relying on STU content (such as query parameters, mothersMaidenName).
 - 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 and ITI-119, while Patient Demographics Consumers have the option to choose to support either one or both transactions. Is requiring support for both transactions a problem for any Patient Demographics Suppliers? We note that prior versions of the specification included only ITI-78, meaning this is new functionality existing suppliers will need to incorporate. Do we want named options here?
+- [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](https://build.fhir.org/ig/IHE/ITI.PDQm/branches/match/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.  

input/pagecontent/testplan.md

@@ -11,8 +11,8 @@ PDQm specifies a query transaction between two actors. The transaction between a
 
 ### Patient Demographics Query for Mobile [[ITI-78]](ITI-78.html) 
 
-* If supported, Patient Demographics Consumer initiates the ITI-78 queries with various combinations of parameters, as supported.
-* Patient Demographics Supplier responds to the ITI-78 queries as appropriate.
+* If supported, the Patient Demographics Consumer initiates the ITI-78 queries with various combinations of parameters, as supported.
+* The Patient Demographics Supplier responds to the ITI-78 queries as appropriate.
 * The Patient Demographics Supplier SHALL be capable of filtering the response search set by the following parameters individually, based on the content of the Patient resources it stores (it need not be capable of filtering on parameters where the corresponding data is never present in Patient Resources it might return):
   * `_id`
   * `active`
@@ -34,8 +34,8 @@ PDQm specifies a query transaction between two actors. The transaction between a
 
 ### Patient Demographics Match [[ITI-119]](ITI-119.html) 
 
-* If supported, Patient Demographics Consumer initiates the ITI-119 operation with a Patient resource containing various demographics, as supported, and possibly also specifies the `onlyCertainMatches` and `count` parameters
-* Patient Demographics Supplier responds to the ITI-119 requests as appropriate 
+* If supported, the Patient Demographics Consumer initiates the ITI-119 operation with a Patient resource containing various demographics, as supported, and possibly also specifies the `onlyCertainMatches` and `count` parameters
+* If supported, the Patient Demographics Supplier responds to the ITI-119 requests as appropriate 
 * If supported, the Patient Demographics Consumer MAY initiate the ITI-119 transaction with a Patient resource containing various demographics, as supported. When prompted with such a request, the Patient Demographics Supplier SHALL be able to respond with the set of matching patients from its database. The methodology the Patient Demographics Supplier uses to determine matches is not specified by this profile. 
 * The Patient Demographics Supplier SHALL populate Patient entries in the response Bundle with a `search.score` between 0 and 1, where higher values indicate higher match quality. The method used to compute the score is otherwise not specified by this profile. 
 * The Patient Demographics Supplier SHALL populate Patient entries in the response Bundle with the [match-grade]({{site.data.fhir.path}}extension-match-grade.html) extension containing an [appropriate code]({{site.data.fhir.path}}valueset-match-grade.html) to describe the match quality. The method the Patient Demographics Supplier uses to assess the match grade is not specified by this profile. 

input/pagecontent/volume-1.md

@@ -88,15 +88,19 @@ See [ITI TF-2: Appendix M.4](https://profiles.ihe.net/ITI/TF/Volume2/ch-M.html#M
 
 #### 1:38.1.1.1 Patient Demographics Consumer
 
-Two `requirements` CapabilityStatements are provided for the [Patient Demographics Consumer implementing Mobile Patient Demographics Query](CapabilityStatement-IHE.PDQm.PatientDemographicsConsumerQuery.html), which shows the query parameters available, and the [Patient Demographics Consumer implementing Patient Demographics Match](CapabilityStatement-IHE.PDQm.PatientDemographicsConsumerQuery.html).
+Two `requirements` CapabilityStatements are provided for the Patient Demographics Consumer. 
+The [Patient Demographics Consumer Implementing the Patient Search Option](CapabilityStatement-IHE.PDQm.PatientDemographicsConsumerQuery.html) statement shows the query parameters available and the requirements that need to be implemented by a Patient Demographics Consumer implementing the Patient Search Option. 
+The [Patient Demographics Consumer Implementing the Match Operation Option](CapabilityStatement-IHE.PDQm.PatientDemographicsConsumerMatch.html) describes support for the [PDQm $Match operation](OperationDefinition-PDQmMatch.html).
 
 #### 1:38.1.1.2 Patient Demographics Supplier
 
-A `requirements` CapabilityStatements is provided for the [Patient Demographics Supplier](CapabilityStatement-IHE.PDQm.PatientDemographicsSupplier.html) that shows the query parameters and operations to be supported.
+Two `requirements` CapabilityStatements are provided for the Patient Demographics Supplier.
+The [Patient Demographics Supplier](CapabilityStatement-IHE.PDQm.PatientDemographicsSupplier.html) statement shows the query parameters to be supported by all Patient Demographics Suppliers.
+The [Patient Demographics Supplier Implementing Match Operation Option](CapabilityStatement-IHE.PDQm.PatientDemographicsSupplierMatch.html) shows the additional capabilities of a Patient Demographics Supplier that implements the Match Operation Option, including support for the [PDQm $Match operation](OperationDefinition-PDQmMatch.html).
 
 The Patient Demographics Supplier SHALL publish an `instance` CapabilityStatement at the metadata endpoint following [ITI Appendix Z.3](https://profiles.ihe.net/ITI/TF/Volume2/ch-Z.html#z.3-capabilitystatement-resource) using the [FHIR capabilities interaction]({{site.data.fhir.path}}http.html#capabilities). 
 All supported search parameters and search methods (GET, POST) SHALL be specified. The [search parameters defined in \[ITI-78\]](ITI-78.html#23784121-search-parameters) SHALL be supported, other parameters MAY be supported.
-The [PDQm $Match Operation](OperationDefinition-PDQmMatch.html) SHALL also be supported. 
+The [PDQm $Match Operation](OperationDefinition-PDQmMatch.html) SHALL also be supported if the Match Operation Option is declared. 
 
 This capabilities response will typically include all of the capabilities inclusive of all grouped actors and additional functionality.
 
@@ -129,8 +133,14 @@ Patient Demographics Supplier |	Match Operation | 1:38.2.2
 {:.grid}
 
 ### 1:38.2.1 Patient Search Option
+The Patient Search Option is declared by Patient Demographics Consumers that search for patient information using the FHIR Search operation. 
+This option uses the [Mobile Patient Demographics Query transaction](ITI-78.html).
+The Patient Demographics Supplier is REQUIRED to support the Mobile Patient Demographics Query transaction, and thus there is no Patient Search Option on the Patient Demographics Supplier.  
 
 ### 1:38.2.2 Match Operation Option
+The Match Operation Option is declared by Patient Demographics Consumers that use, and Patient Demographics Suppliers that support locating patient information using the [PDQm $Match Operation](OperationDefinition-PDQmMatch.html). 
+
+Because this option is available for both the Patient Demographics Consumer and the Patient Demographics Supplier, Patient Demographics Consumers that implement the Match Operation Option but not the Patient Search Option can only interoperate with Patient Demographics Suppliers that implement the Match Operation Option. 
 
 ## 1:38.3 PDQm Required Actor Grouping