ihe / qedm Goto Github PK

Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)

3.44.4.1.2.1

Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.

QEDm specifies which search parameters for which support is required, and also which combinations of parameters much be supported. This is good. However, it does not specify for which parameters multiple values should be supported (either AND or OR).

Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.

Consider specifying which search parameters should require servers to support multiple values. See https://build.fhir.org/ig/HL7/US-Core/general-guidance.html#search-syntax for how this is done in US Core, and http://hl7.org/fhir/us/core/STU3.1.1/SearchParameter-us-core-location-address-state.html for an example search parameter from US Core.

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Submitting our comments per John's request on the ITI Tech mailing list.

• Since HL7 IPA is now a standard for trial use, it would benefit interoperability to align QEDm to the HL7 IPA standard as much as possible. We recommend basing the required Resource search parameters and Resource profiles off of those in HL7 IPA.
• 2:3.44.4.1.2.2 states "The Clinical Data Source shall support the “:exact” parameter modifier on all query parameters of type string. When supplied by the Clinical Data Consumer, the “:exact” parameter modifier instructs the Clinical Data Source that exact matching shall be performed." However, none of the listed search parameters are of type string.
• Section 3.44.4.2.2 states "if a Data Source receives a Mobile Query Existing Data transaction for a resource related to a QEDm Option not supported, it shall return an operationoutcome.issue.code valued as: ‘not-supported’ and an operationoutcome.issue.details valued as: MSG_NO_MATCH No Resource found matching the query “%s”.". OperationOutcome.issue.details is of type CodeableConcept, and it is not clear how "MSG_NO_MATCH No Resource found matching the query “%s”" is intended to map to the CodeableConcept structure. In general, OperationOutcomes are typically only machine processed by the severity and code elements, so further specification seems unnecessary and potentially unwarranted.
• Section 3.2.2 specifies additional US National Extensions, but it is unclear to me how these differ from the base international profile.
• Since FHIR R4 section 3.1.0.9 mandates that FHIR servers support both the HTTP GET and POST methods for search, it is best for interoperability to carry this requirement into QEDm and allow the client to select the HTTP search method. This would also be consistent with the requirement that servers support both XML and JSON format, and clients can select the best option for their use case.
• For search parameters of type token, the FHIR R4 spec section 3.1.1.4.10 specifies that search can be done using only the code or only the system. We've found that search on only code or system can be burdensome for implementation. We recommend restricting support for this only to cases where the search parameter specifies both a code and a system for the value, unless the data is stored with a code only and no system.
• Section 2:3.44.4.1.2.2 states that "The Clinical Data Consumer should not use and Clinical Data Source may ignore any additional parameter modifiers listed in the FHIR standard, which are considered out of scope in the context of this transaction." Note that the base FHIR specification section 3.1.1.4.4 states that servers shall reject search requests that specify unsupported search parameter modifiers.
• 2:3.44.1 states "The QEDm Profile assumes that categories and codes referenced by these FHIR Resources need to be defined at the time of deployment. The specification of these FHIR Resources make recommendations on categories and codes that should be considered." The original QED deployment did specify valuesets for the most critical elements, and such specification is where much of the value of a profile like this comes from. IPA should be leveraged to provide terminology bindings where appropriate.

QEDm should define the use of the status query parameter as mandatory so as to assure that the client is being explicit that they want active, or wants different status. In the absence of the status element the results will very on if only active results are returned or not. For a system that only has active results, it should error when asked to return status other than active.

to enable getting a Provenance where one has a Resource, one should be able to query Provenance using the target query parameter. Today query is supported on Provenance but only on the _id parameter.

http://build.fhir.org/ig/IHE/QEDm/branches/master/volume-1.html

Table 1:8.1-1: QEDm Integration Profile - Actors and Transactions

Maybe in the reference column, make an HTML link instead of a textual reference without a HTML link.

http://build.fhir.org/ig/IHE/QEDm/branches/master/CapabilityStatement-IHE.QEDm.server.html

There is some "blah" "blah" text in the CapabilityStatement, I guess it will be handled later.

I remarked there is only the Patient resource as supported resources, however the Patient resource is not part of QEDm, and we are missing the other resources.

The same comments are for the CapabilityStatement of the consumer: http://build.fhir.org/ig/IHE/QEDm/branches/master/CapabilityStatement-IHE.QEDm.client.html

http://build.fhir.org/ig/IHE/QEDm/branches/master/volume-1.html#18111-clinical-data-source

The section references "Section 8.2", but without using an HTML hyperlink, maybe we should add it for better navigability.

Same comment for the section http://build.fhir.org/ig/IHE/QEDm/branches/master/volume-1.html#18112-clinical-data-consumer

http://build.fhir.org/ig/IHE/QEDm/branches/master/volume-1.html#182-qedm-actor-options

The table Table 1:8.2-1: QEDm - Actors and Options references other subsections, we may add here also some HTTP hyperlink to the referenced sections.

Document Provenance (Note 1) : in the table 1:8-2-1, the Document provenance option was not part of the note in the PDF document (https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_QEDm.pdf), was this intentional ? (for both consumer and source)

http://build.fhir.org/ig/IHE/QEDm/branches/master/volume-1.html#18211-simple-observations-option

The referenced section 3.44.4.1.2.1.1 does not exist in the volume-2 : http://build.fhir.org/ig/IHE/QEDm/branches/master/PCC-44.html

But I think this is an error in volume 2 : the section "2:3.44.1.2.1.1 Simple Observations Option Search Parameters" should be "2:3.44.4.1.2.1.1 Simple Observations Option Search Parameters"

Maybe also hyperlink could be helpful for navigation. Same comment for all the sections describing the options (1:8.2.1.1 -> 1:8.2.2.10)

http://build.fhir.org/ig/IHE/QEDm/branches/master/volume-1.html#184211-discovery-and-retrieval-of-existing-data-elements-description

Maybe rename the section from "1:8.4.2.1.1 Discovery and Retrieval of Existing Data Elements Description" to just "1:8.4.2.1.1 Description"

http://build.fhir.org/ig/IHE/QEDm/branches/master/volume-1.html#184212-discovery-and-retrieval-of-existing-data-elements-process-flow

Maybe rename the section to simply "1:8.4.2.1.2 Process Flow"

For the SVG image, if you find it really big, you can use this in the value-1.md page :

{: width="80%"}

instead of

{%include usecase1-processflow.svg%}

http://build.fhir.org/ig/IHE/QEDm/branches/master/volume-1.html#184221-discovery-and-retrieval-of-existing-data-elements-with-source-document-links-description

Maybe rename to just "1:8.4.2.2.1 Description"

http://build.fhir.org/ig/IHE/QEDm/branches/master/volume-1.html#184222-discovery-and-retrieval-of-existing-data-elements-with-source-document-links-process-flow

Maybe rename to "1:8.4.2.2.2 Process Flow"

http://build.fhir.org/ig/IHE/QEDm/branches/master/PCC-44.html#23444-messages

The text within the Query in the Figure 3.44.4-1 is "Go Query"; we may keep "Mobile Query Existing Data Request" as it was in the PDF, same for the response.

http://build.fhir.org/ig/IHE/QEDm/branches/master/PCC-44.html#2344412-message-semantics

In the query template there are extra ""

GET [base]/[Resource-type]{?[parameters]}

Same remark for the different bullets to explain the query

A link was not well displayed : " [ITI TF-2: Appendix Z.6](https://profiles.ihe.net/ITI/TF/Volume2/ch-Z.html#z.6-populating-the-expected-response-format0", I think you need to replace the format0 by "format)" in the .md

http://build.fhir.org/ig/IHE/QEDm/branches/master/PCC-44.html#3444121-query-search-paramters

The table "Table 2:3.44.4.1.2.1-1" contains internal references to other sections, they can be internal hyperlink

All the rows of the table are in Bold, we may use simple formatting, not bold text format.

In the table, the column "Reference", all the references override the current page, they are referencing to FHIR or to US Core, they should have _target="blank" in the URL definition, as we go out from the website.

In the table, the cell QEDm Actor Option "Medications" should have a rowspan=3, but I don't know how to do it in .md. Same for the cell Occupational Data for Health.

http://build.fhir.org/ig/IHE/QEDm/branches/master/PCC-44.html#23441211-simple-observations-option-search-parameters

n the query template there are extra "", same as described before; and the issue is the same in the following sections (2:3.44.4.1.2.1.*)

Table 2:3.44.4.1.2.1.1-1 : there are some issues in the table, missing rowspan and colspan in some cells. And the issue is the same in the following sections (2:3.44.4.1.2.1.*)

http://build.fhir.org/ig/IHE/QEDm/branches/master/PCC-44.html#234441214-diagnostic-reports-option-search-parameters

Typo : Table 2:3.44.4.1.2.1.4-1: Diagnostic Reposts Option Search Parameters

http://build.fhir.org/ig/IHE/QEDm/branches/master/PCC-44.html#344422-message-semantics

Maybe an old typo: replace "operationoutcome.issue.code" by "OperationOutcome.issue.code" , and replace " operationoutcome.issue.details" by "OperationOutcome.issue.details".

Funny thing, in FHIR OperationOutcome: http://hl7.org/fhir/operationoutcome.html, the link to the valueSet "IssueDetails" is not working (404 page from HL7).

I see that the implementation guide force the "issue.details" to some specific format, I would prefer to have it as a recommendation, not as a requirement (unless there is clear need for this enforcement).

http://build.fhir.org/ig/IHE/QEDm/branches/master/PCC-44.html#234451-security-audit-considerations

Typo following the "Human Requestor (0..n)" (missing an arrow there, from original PDF format).

Abderrazek Boufahja