CH eToc Service Request - Definitions note (Walter Wellauer, Cistec AG)

[ig-feedback]

ch.fhir.ig.ch-etoc#0.1.0 /StructureDefinition-ch-etoc-servicerequest-definitions.html

http://fhir.ch/ig/ch-etoc/StructureDefinition-ch-etoc-servicerequest-definitions.html#ServiceRequest.note
should be omitted
The information is already part of the QuestionnaireResponse
The ServiceRequest as pure workflow item should'nt contain redundant medical information
(a part of the referenced supportingInfo)
Presenting medical information as part of a worklfow could even be a data protection issue at the Questionnaire Receiver, as you might not want doe display such information in a overview of received referrals e.g.

Walter Wellauer, Cistec AG

[JBleuer]

Tel. mit Walter Wellauer 3.11.21: Grundsatzfrage: Walter will nicht alle Attribute in die Resources kopieren, sondern nur strukturierte Daten. Grund: Cistec füllt Resources unabhängig vom Questionnaire aus; diese Daten werden im Questionnaire angezeigt, sind aber nicht editierbar. Eingaben in den Questionnaire sollen beim Empfänger ausgelesen werden. Cistec will diesen Aufwand als Sender nicht machen.

[walterwellauer]

According to http://build.fhir.org/ig/HL7/sdc/workflow.html#form-filling the form filler may $extract after completing the QuestionnaireResponse, but with no interaction with the form receiver actor. The purpose is probably to add resources for its own further use.
The other actor performing the $extract operation is the form receiver upon receiving a QuestionnaireResponse. This makes sense, because the form receiver knows what to extract for its own needs.
To oblige the form filler to extract data from a QuestionnaireResponse before transmitting to the form receiver or form archiver in contradiction to SDC as stated in this IG makes no sense and produces a very remarkable and therefore expensive overhead on the form filler side, especially if not the strucure map approach for constructing a bundle ist applied, which would only be faisible if the end user had to fill the entire Questionnaire manually by himself which in reality never will happen. Obliging the form filler to extract data from a QuestionnaireResponse before transmitting to the form receiver as a a priori extraction of any data, independently whether it is useful for further use (strucured resources) or not (free text, chosen readio buttons and so on) makes implementation of eToc very expensive on the form filler side and may lead to non implementaion of this IG by some vendors because of too high complexity.
Instead I suggest to focus on Designing Questionnaires to support data extraction with Definition-based extraction according to https://build.fhir.org/ig/HL7/sdc/extraction.html#definition-extract to ease the extraction of the really needed data on the form receiver side @ig-feedback @oliveregger @JBleuer

[oliveregger]

@walterwellauer thank you for your input.

I think we should not first discuss about the technical extraction process, but focus on what we want to achieve with eTOC:

• Interoperable exchange of health data for transition of care as it was stated in the eTOC Implementation Guide should adhere to the IPS as it was stated in the Implementation Guide and there was no negative feedback coming up for this design principle.
• This obliges the sender to provide the exchanged information according to the IPS resources (and not on QuestionnaireResponses). The Implementation Guide also precises that the "The Questionnaire resource gives guidance for the implementation of the user interface."
• In the "Swiss eHealth ExchangeFormat Handbook. Part I: Service Requests" it is stated that an implementation without Questionnaire and QuestionnaireResponse is possible and therefore the filler needs to provide the exchange format.
• All international activities for exchanging health information are currently converging to IPS, I see absolutely no value in defining exchange formats based solely on Questionnaires. This was also feedback from the ballot now integrated into CH RAD Order and CH Lab Order that it should be possible to exchange only the exchange format with ServiceRequest etc and not necessarily including Questionnaire, QuestionnaireResponse.
• If the complexity is too high to provide for the sender FHIR Resource according to the IPS profile I'm not quite sure what we are trying to achieve with eTOC. Meaningful use in the US requires the hospital to provide data to patients in FHIR Resources according to US Core, why should we not be able to handle this complexity in Switzerland?

1. Do we find here a common ground on what we want to achieve with eTOC and that the Sender is responsible for providing the data according to the IPS as it is defined in the eTOC Implementation Guide? I yes, I would like to reaffirm this principle at the next telco with the HL7 FHIR group working members with a consultative vote.

Concerning the extraction process what kind of extraction should be used:

For CH-ORF (not CH-eTOC) wie tried the different extraction option at the HL7 FHIR connectathons and settled with the StructureMap base approach because the Definition-based approach was not able to handle the complexity of the ORF exchange format (PractionierRole, Practitioner nested in the Bundle). To handle the complexity of the mapping the maps was were developed within the IG for CH:ORF and is included. From my point of view we could also make this required mapping binding optional that people do not have to use those mappings and can use other mappings if they prefer that. Important is the result (see above) which can be checked for correctness.

I agree that a Questionnaire based definition for certain IPS resources might be complex and not necessary because the primary system has the information in the future already in a structured way, however I think that should be handled and included in the design of the Questionnaire. I would suggest making the Questionnaire and Mapping optional and state it explicitly for Trail Use that we get more feedback during the next projectathons and put a first focus that the eTOC exchange format based on the IPS concept gets prioritized.

[walterwellauer]

Dear @oliveregger,
thank you for your statement. In general I unterstood balloting as the process to achieve the best possible IGs in an agile sense and not to refer unchangeably what was written in a document or said in one day at a meeting under partial information. Regarding the above mentioned "Swiss eHealth ExchangeFormat Handbook. Part I: Service Requests" there is inconsistency in the argumentation as metionned in hl7ch/ch-lab-order#81 for example. On the other hand I never doubted the good reason to rely also on the IPS, I even suggested its utilization in the temporary working group in autumn of 2019.

I'd like to focus again on the original issue content, as I identified some missunterstanding regarding the respective idea of this issue in your reasoning which I know in part already orally from @JBleuer:

The usage of Questionnaire/QuestionnaireReponse in the Context of eTransistionOfCare has a added value which should be used, therefore I propose not to make it optional there (but in CH ORF and LabOrder), but

1. not o include all the information in the Questionnaire and
2. not to extract all the information of a QuestionnaireResponse in order to include in the bundle or ServiceRequest respectively, especially not information entered by free text as end user (the mentioned note in thi issue) or similar

=> that means a combination of the IPS with structured information useful for backend processing with a QuestionnaireResponse for front end presentation and filling, where certain structured resourcesbased on this IG with expression based population could be prefilled.

Whilst notes and similar (which are not part of the IPS as far as I know anyway) are part of the QuestionnaireResponse only (similar to PDF today).

I complement my argument in my mother tongue for better understanding of most of the participants of the balloting @ig-feedback:

Die fehlende tiefe Integration in Primärsysteme ist Stand heute das grösste Hemmnis, damit Zuweiser und Nachbehandelnde (Zentrumsspitäler, REHAs, Spitex, Fachärzte) mehr elektronisch austauschen. Plattformen und Intermediäre mit PlugIns o.ä. in Primärsystemen lösen den Medienbruch nicht, weshalb sie Stand heute sehr wenig in der Praxis verwendet werden.

Mit Hilfe der Questionnaires und ihrer frei verfügbaren (Open Source) Renderer für die QuestionnaireResponses könnte eine guter Anteil an nicht strukturierter Information durch die Endanwender kontextabhängig erfasst werden.

Zusammen mit strukturierter Informationen, die im System bereits vorhanden sind, im Austauschformat und Questionnaire spezifiziert sind (Allergien, Medikamente, Diagnosen, Problemlisteinträge, gewisse observations wie Gewicht, Grösse, die wesentlichsten Vitaldaten) und die im backend entweder mittels $polulate bei der Initialisierung den QuestionnairesResponse vorbefüllen können, sofern über einen Vorprozess bereitgestellt, oder direkt im Questionnaire ausgewählt werden, sofern mittels z.B. eventstream bereits als FHIR Ressource vorhanden, kann dann dem Endanwender, sei es der das Formular ausfüllende (Form Filler) oder der Empfänger der Zuweisung/Überweisung (Form Receiver) die wesentliche Information im GUI dargestellt werden, so wie das z.B. ein KISIM Bericht heute macht, nur dass keine propietäre Formularentwicklung mehr im Spiel ist.

Andere Informationen wir die vollständigen Stammdaten des Patienten oder der Gesundheitsfachpersonen oder –instutionen, Fillerordernumber oder die OID des Systems, dass die Fillerordernumber erzeugt haben hingegen nichts im Questionnaire/ im dargestellten Formular (QuestionnaireResponse) zu suchen und würden den Endanweder nur stören. Sie sollten nur via backend im Bundle untergebracht werden.

Handkehrum bringt es nichts, wenn freitextlich erfasste Information (Bsp. Bemerkungen – notes) aus der QuestionnaireResponse extrahiert würde, nur weil es dazu zufälligerweise auch eine FHIR Ressource gibt. Der Form Receiver wiederum wird solche freitextliche Information oder auch via Auswahlcheckboxen, Radiobuttons oder Drop down Listen erfasste Spezialinformation (Bsp. «Rollator» in einer REHA-Überweisung) nicht aus dem bundle oder dem ServiceRequest entnehmen wollen, sofern er dem Endanwender das in Form der ebenfalls übertragenen QuestionnaireResponse dem Endanwender präsentierten kann. Hingegen interessiert das empfangende System strukturierte Informationen (Allergien, Medikation, Diagnosen, Problemlisteinträge, gewisse observations wie Gewicht, Grösse, die wesentlichsten Vitaldaten) als Ressource im Bundle, damit es diese via backend in sein System importieren kann. Also die Entsprechung des IPS.

Aus diesem Grunde ist es auch keine gute Idee, wenn Questionniare/QuestionnaireResponse in CH eToc wie nun vorgeschlagen optional gesetzt würde, nur weil es im LabOrder sinnvollerweise gemacht wird. Eine gute Möglichkeit wäre, die Verwendung von Questionniare/QuestionnaireResponse im CH ORF optional, in CH eToc jedoch zwingend zu machen. Andernfalls – wenn ein Primärsystem das nutzt, das andere nicht - wird sich das nicht durchsetzen und es bleibt alles beim alten – der fehlenden tiefen Integration in den Primärsystemen mit je propietärer, nicht kompatibler Formularentwicklung und dem Austausch von PDF.

[oliveregger]

discussed at telco of Dec 15h in FHIR working group call but we did not come yet to a common agreement / understanding of this issue or a way how to proceed.

[JBleuer]

marked in changelog as:

• Issue #10: Question of principle: Extraction of all questionnaire items to corresponding items in resources at sender site or not. See discussion i t CH eToc Service Request - Definitions note (Walter Wellauer, Cistec AG) #10

[JBleuer]

Next step?

[JBleuer]

No final conclusion until now. Further disussion is postponed until funding is granted by eHealth Suisse.