CH eTOC (R4)
3.0.0-ci-build - ci-build Switzerland flag

CH eTOC (R4), published by HL7 Switzerland. This guide is not an authorized publication; it is the continuous build for version 3.0.0-ci-build built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/hl7ch/ch-etoc/ and changes regularly. See the Directory of published versions

Changelog

All significant changes to this FHIR implementation guide will be documented on this page.

STU 3 (2024)

Open Issues

During the ballot, the following comments came in, which will be taken into account in the further development of CH eTOC:

  • #87: Revision (harmonization, usage SCT) of code system and value set ServiceRequest Category

See also open issues on GitHub.

Added

Changed / Updated

  • #94: Add dates to the versions in the changelog
  • #93: Broken links in Home/Foundation
  • #88: Update Coverage.type according to changes in parent profile CH ORF (see CH ORF #177)
  • #90: Update the documentation regarding the relationship with IPS (also taking into account new developments in the field of IPS)

Fixed

STU 3 Ballot (2024-05-17)

Open Issues

  • #87: Update Coverage
  • #88: Update ServiceRequest

Changed / Updated

  • #82: Move terminology to CH Term
  • #83: Use CH Core base profiles

Fixed

  • #81: Item attachment fixed; example added
  • #84: Typos in ids of profiles

STU 2 (2023-12-28)

  • #270: Technical correction for invalid package

Open Issues

  • Issue #80: Secondary Diagnosis Condition - support also the less specific value from the base spec: encounter-diagnosis

Fixed

  • Issue #75: Typo in example Biopsy Duodenum / Magen corrected.
  • Issue #76: Various typos on the home page corrected.

Added

Adopted from CH ORF
  • ORF Issue #71: Added Initiator and his relationship to to the patient.
  • ORF Issue #72: Added Patient consent.
  • ORF Issue #73: Added Entry date, discharge Date and Organization of stationary episode antecedent to requested service (e.g spitex).
  • ORF Issue #106: Changed Cardinality of Contact Person from 0..1 to 0... ORF Issue #61: Added Family doctor.
Added in CH eTOC
  • Issue #59: Added examples for AllergyIntolerance (Penicillin-Allergie), LabObservation(Haemoglobin), LabObservation (HbA1c), PathologyObservation (Biopsie Duodenum / Magen), RadiologyObservation (Thx ap / seitl.) and CardiologyObservation (EKG).
  • Issue #60: Added display values to CodeSystem Category of Condition.

Changed / Updated

  • Issue 78 - Added IG Fragments to the home page below
  • Issue 77: SCT code for DocumentEntry.typeCode adapted from 419891008 to 371535009.
Adopted from CH ORF
Changed / Updated in CH eTOC
  • Issue #38: Added sections in composition referencing clinical content.
  • Issue #39: April 7, 2022 the the HL7 Switzerland Technical Committee discussed #39 and finally voted to set cardinality for the questionnaire and questionnaire response to 1.. in the composition resource thus making the use of questionnaires and questionnaireResponses mandatory.
  • Issue #40: Cardinality of patient in questionnaire set to 1..1.
  • Issue #49: Careplan section dropped. Reason: It can be assumed that careplans will be available at best as pdf files for the foreseeable future. There is therefore a need to provide careplans as an attachment. This is what the Attachment section is for.
  • Issue #50: Dropped CH eTOC Attachment. Attachments are now mapped to Composition.section:orderReferral.entry:DocumentReference.
  • Issue #54: Improved text in index.html.
  • Issue #58: Corrected title of immunizationstatus in questionnaire to "Impfstatus".
  • Issue #61: Corrected receiver.organization.gln to Organization.identifier:GLN.
  • Issue #62: Corrected discrepancies between profiles and questionnaire.
  • Issue #63: Corrected cardinality of appointment.location to 0..1.
  • Issue #64: Corrected cardinality of purpose.aim to 1..1. Added purpose.aim.detail in order to allow multiple entries. should be: http://fhir.ch/ig/ch-core/StructureDefinition/ch-core-organization#Organization.identifier:GLN
  • Issue #65: Corrected "diagnosisList.primaryDiagnosis" and "diagnosisList.secondaryDiagnosis" to CamelCase.
  • Issue #67: Changed descriptions in ServiceRequest and questionnaire, details see Issue #67.
  • Issue #68: Title of QuestionnaireResponseEtoc changed from QuestionniaireResponse Radiology Order to QuestionnaireResponse Etoc.
  • Issue #69: : Changed questionnaire linkid's medication.statement.medication and medication.medicationstatement.dosage to medication.medication and medication.dosage in order to be inline with other. linkid's. Adapted representation in questionnaire.

STU 1 (2022-04-13)

Open Issues

During the ballot, the following comments came in, which will be taken into account in the further development of CH ORF:

  • Issue #10: Question of principle: Extraction of all questionnaire items to corresponding items in resources at sender site or not. See discussion in #10.
  • Issue #17: Restrict Questionnaire to information needed to display to the end user.
  • Issue #18: Questionnaire support for various specialties (use cases): The questionnaire(s) should be designed to support various different use cases in the sense, that only the relevant information per specialty (to be referred) is displayed, either by allowing more than one instance of questionnaires in the IG, each of them representing part of the "super questionnaire" or by using adaptive forms. Use case dependent constraints in the questionnaire will be subject of further discussions.
  • Issue #19: Questionnaire support for expression based population and advanced behavior.

Follow up of changes in CH ORF

Added

  • Issue #22: Various attachment now possible.

Changed / Updated

  • Issue #4: Reference to IPAG report added in home.
  • Issue #14: Definition of eTOC questionnaire corrected.
  • Issue #15: Examples: Incongruence between questionnaireresponse and servicerequest.
  • Issue #20: CH eTOC Service Request - Definitions medication statement instead of medication card.
  • Issue #39: Cardinality for Questionnaire and QR in Composition set to 1..1 after voting on objection 7.4.22.

Issues resolved without amendment

  • Issue #23: One recipient only.
  • Issue #42 Purpose (Wozu wird der Patient zugewiesen?) allows to indicate "type of Spitex required for the patient (child-spitex, longterm, acute transitional care)", however as free text. Reason: There are currently no generally accepted codes for spitex-services available.

Negative comments which could not be resolved during the ballot

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 resources referenced in the ServiceRequest Resource. 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 end user 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 QuestionnaireResponse Resources 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 proprietary 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 (QuestionnaireResponse) 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 Projectathon 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