QEDm Epic Comments

[slagesse-epic]

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.

[JohnMoehrke]

These are good improvements beyond the simple conversion to IG. Which of these do we want to include in this conversion step, vs implement beyond? I expect we will base QEDm upon IPA in the next step. With this first step to get into an IG form. Which of the above improvements would come automatically with that basis upon IPA? It would seem these we should wait until we build upon IPA.