CH eTOC (R4)
2.0.1 - trial-use
CH eTOC (R4)
2.0.1 - trial-use
This page is part of the CH eTOC (R4) (v2.0.1: STU 2) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions
All significant changes to this FHIR implementation guide will be documented on this page.
During the ballot, the following comments came in, which will be taken into account in the further development of CH ORF:
CH Core Organization Profile | CH Core Patient Profile to CH Core Practitioner Role Profile | CH Core Patient Profile | RelatedPerson and update the Questionnaire accordingly.Walter Wellauer, Cistec AG: The initial STU 1 ballot version of eTOC required the Form Filler / Questionnaire Filler actor to provide redundant information in the QuestionnaireResponse and in the transaction or document bundle, with the corresponding ressources referenced in the ServiceRequest Ressource. This hindered the Form Filler implementing a combined front end / back end data acquisition and thus providing the data with complementary processes, was not feasible for the user experience as the enduser was presented a lot of information of no interest at the form filler and form receiver side and required the Form Filler actor to extract alle the data of the QuestionnaireResponse before transmitting it to the FromReceiver, which is not foreseen be SDC. All these issues led to the implementation feedback from Projectathon 2021, where the most significant discussion was held in issue#10, corresponding to issue#17 and issue#18 - with emphasis of the missing usability.
None of the relevant suggestions of the feedback was adopted since then (we agree, that issue#19 needs more time to elaborate though). On the contrary there has been implemented a game changer, as in the ORF Composition profile the Questionnaire and QuestionnaireReponse Ressources have been changed to optionality (which makes sense for some derivates of the ORF profile like Lab Order), but have not been declared mandatory in the CH eTOC to restore the preconditions of the balloted version. The effect is worse than before. If Questionnaires / QuestionnaireResponses are optional, the main benefit of interchanging forms in the context of TransitionOcCare are gone, as it needs only one player who doesn’t provide a QuestionnaireResponse that all the other actors (any transaction receiver in B2B context, Form Receiver, QuestionnaireReceiver or EPR Document Consumer) to implement proprietiary form integration as it is the actual practise but has its well known downsides for the overall interoperability.
The IG author argues with a decision taken to adapt to IPS at one meeting with IPAG around a year ago. Whilst the concrete informative value of such a statement is marginal for the concrete implementation, we state that the actual IG and post balloting version corresponds very little - if even – to the IPS. The IPS does not address e.g. ServiceRequests or notes (see issues#10), Notes are not part of the IPAG recommendation neither, maybe the IG authors choice, and could be extracted out of a form (QuestionnaireReponse) by the Form Receiver, be it in a B2B transaction or as a EPR document consumer if needed, if the QuestionnaireResponse was mandatory, but only with the essential information needed to be presented to the end user in the UI.
The actual version is not considered ready for implementation as Standard of Trial Use on one hand and on the other hand differs in the very essential optionality of QuestionnaireResponses from the initially balloted version tested at Projcetathon 2021 by our company. Issue #10
Daniel Ratschiller, Cistec AG: From an HIS provider’s point of view, the current state of IG eTOC is still too immature to be used concretely in everyday hospital life. Perhaps too many different ingredients have been thrown together to do justice to everyone and everything, but it will be very difficult to find a uniform line for referral processes across different systems. Primary care providers will have a difficult time developing healthcare solutions on this basis that will be accepted by healthcare professionals. I would recommend reviewing the original intended goals of IPAG, possibly reducing its scope and focusing on promising use cases. Issue #21