ABCDEFGHIJKLMNOPQRSTUVWXYZAAABACADAEAFAGAHAIAJAKALAMANAOAPAQARASATAUAVAWAXAYAZBABBBC
1
Please complete this spreadsheet by March 6, 2020.
To submit your entry, scroll right and add your votes/comments in your column...
2
3
4
Organization-->ahdis agahdis ag
BORS Consulting GmbH
Advanced Concepts
CistecCistec BFHBFHELCA AGeHealth SuisseeHealth SuissePostPost NetcetereaMarcel HanselmannArpageJuerg BleuerSuva
5
HL7.org usernameswitzerland_3Michaela_ZieglerFelix_Fischerstefan_csomorWalter_WellauerEmmanuel_Eschmann1François_von Kaenelheg2@bfh.chpaul_bernetPero_GrgicTim_Dornerdmytro_rudSwitzerland_1Marcel_Hanselmann1Roeland_Luykx
6
E-Mail
oliver.egger@ahdis.ch
michaela.ziegler@ahdis.ch
felix.fischer@borsconsulting.ch
csomor@advancedconcepts.ch
walter.wellauer@cistec.com
emmanuel.eschmann@cistec.comfrancois.vonkaenel@bfh.chgabrielimmanuel.hess@bfh.chpaul.bernet@elca.chpero.grgic@e-health-suisse.chjuerg.bleuer@e-health-suisse.chtim.dorner@post.chdmytro.rud@post.chbeat.heggli@netcetera.chmarcel.hanselmann@ganimedes.chroeland.luykx@arpage.chbleuer@healthevidence.chbeatrice.fust@suva.ch
7
Y/N/AProject idDescr.ProfileDoc updatedYesAbstainNoYour name-->Oliver EggerMichaela ZieglerFelix FischerStefan CsomorWalter WellauerEmmanuel EschmannFrançois von KaenelGabriel HessPaul BernetPero GrgicJuerg BleuerTim DornerDmytro RudBeat HeggliMarcel HanselmannRoeland LuykxJuerg BleuerBeatrice Fust-Kyburz
8
2020/02/141603HL7 CH-Core: Base FHIR profiles for SwitzerlandThe primary goal of this project is to represent Swiss concepts defined via FHIR processable artefacts; these are collaborative outputs with agreed approaches to varied kinds of healthcare related information based on the core FHIR R4 specification.http://fhir.ch/ig/ch-core/index.html1304
Yes/Abstain/No
YesYesYesYesNoNoYesYesNoYesYesYesNoYesYesYesYes
9
Comments:
(Req'd if No)
incorporate https://github.com/hl7ch/ch-core/issues/32 if possible
Patient.identifier:LocalPid.type is missing in an example, see https://github.com/hl7ch/ch-core/issues/30
ich schliesse mich Emmanuels Ausführungen und Überlegungen an.

Zusätzlich füge ich noch folgendes an:

ChCorePractitionerRole
 PractitionerRole.code: unvollständiges Valueset
o In den HL7v2 ADT Nachrichten zwischen Admin- und z.B. KIS Systemen werden auch prozessorientierte Rollen von Gesundheitsfachpersonen ausgetauscht wie z.B. Hausarzt, einweisender Arzt, behandelnder Arzt, mitbehandelnder Arzt, Belegarzt o.ä.
o Wenngleich das Binding nur (preferred) auf HCProfessional.hcProfession ist, so ist sein Werteset doch schon viel eingeschränkter als in http://hl7.org/fhir/R4/valueset-practitioner-role.html, wo man zumindest für den Hausarzt mit dem general practitioner oder family medicine specialist eine in etwa Entsprechung
o Vorschlag Erweiterung des value sets um die prozessorientierten Rollen oder (da code card. O..*) Angebot eines zusätzlichen prozessorientierten valuesets, und/oder feedback in die Patient Administration Workgroup, wo das maturity level offenbar noch 1 ist.
(formattierte Version per Mail an O. Egger)

CHCorePatient

 Patient.name, Verwendungszweck («use»): Fehler und Problem
o Die FHIR-Ressource «Patient» erlaubt es, im Element «name» mehrere Namen aufzulisten (Kardinalität 0..*). Das Element «use» definiert dabei den Verwendungszweck des betreffenden Namens (z.Bsp. «official» oder «maiden»).
o In CHCorePatient extenden wir jedoch mit der «StructureDefinition: CHCoreHumanName» die Unterelemente «family» und «given» von Patient.name so, dass wir als Verwendungszwecke für den Familiennamen den ValueSet http://fhir.ch/ig/ch-core/ValueSet/ech-11-namedatatype und für den Vornamen den ValueSet http://fhir.ch/ig/ch-core/ValueSet/ech-11-firstnamedatatype verwenden können.
o Daraus resultierender Fehler:
 Das Element Patient.name[*].family bleibt auch nach unserer Extension ein «primitive type».
 Die CHCoreHumanName-Extension fordert dagegen für das Element Patient.name[*].family einen «complex type» mit den Unterelementen id, extension[{url, valuecode}] und value.
 Als Folge liefert der Validator für Instanzen, die der CHCoreHumanName-Extension folgen den Fehler «This property must be an simple value, not an object».
o weiterer Fehler:
 im ValueSet http://fhir.ch/ig/ch-core/ValueSet/ech-11-firstnamedatatype fehlt im Code "officalFirstName" das «i» bei official.
o Daraus resultierendes Problem:
 Die FHIR-Ressource «Patient» definiert «use» als Unterelement von Patient.name[*].
 In CHCorePatient definieren wir einen weitgehend mit «use» übereinstimmenden Namen-Verwendungszweck auf zwei weiteren Ebenen: als neues Unterlement von Patient.name[*].family und von Patient.name[*].given
 Wir bilden damit eine neue Modell-Struktur, die den Namen-Verwendungszweck verdreifacht. Dies erhöht die Komplexität ohne Erhöhung des Nutzens, erschwert den grenzüberschreitenden Datenaustausch und erlaubt sich widersprechende Einträge.
o Vorschlag:
 Verzicht auf die Extension CHCoreHumanName, dafür Erweiterung oder Ersatz des von Patient.name[*].use referenzierten ValueSets http://hl7.org/fhir/ValueSet/name-use um die für die CH relevanten Werte.
 Patient.name, Anrede und Titel («prefix»): fehlende Datenstruktur
o Das FHIR-Element Patient.name[*].prefix[*] erlaubt es, dem Namen eine beliebige Anzahl von Präfixe voranzustellen (wie akademische Titel, …).
o In der Schweiz gängige Spital-Administrationssysteme liefern Anrede und Titel als zwei voneinander unabhängige klar bezeichnete Elemente. «Anrede» lässt sich nicht immer aus dem Geschlecht des Patienten ableiten (z.Bsp. im Verlauf von Geschlechtsumwandlungen, bei denen die Anrede vorübergehend nicht dem offiziellen Geschlecht entspricht).
o Eine inoffizielle oder eine Patient.name[*].prefix[*] hinterlegte Bemerkung, wonach Patient.name[*].prefix[0] der Anrede und Patient.name[*].prefix[1] dem Titel entspricht, genügt nicht.
o Vorschlag: Extension von HumanName um die beiden «primitive type»-Elemente (vom Typ string oder code) Anrede und Titel.
 Patient.maritalStatus (unvollständiges ValueSet):
o Das ValueSet http://fhir.ch/ig/ch-core/ValueSet/ch-core-maritalstatus führt nur die Haupt-Zivilstände gemäss «BFS Amtlicher Katalog der Merkmale» (https://www.bfs.admin.ch/bfsstatic/dam/assets/349276/master) S. 26 auf. Das Teilmerkmal «Trennung» fehlt jedoch in unserem ValueSet (z.Bsp. «getrennt lebend», was z.Bsp. für die allfällige Kontaktaufnahme mit dem noch verheirateten Partner relevant ist).
o Das ValueSet http://fhir.ch/ig/ch-core/ValueSet/ch-core-maritalstatus führt nur die Schweizer Zivilstände auf. Für Ausländer, die sich in der Schweiz behandeln lassen fehlen die Zivilstände ihrer Länder wie Konkubinat und Polygamie.
o Vorschlag: Ergänzen des ValueSets http://fhir.ch/ig/ch-core/ValueSet/ch-core-maritalstatus um getrennt lebend, Konkubinat und Polygamie
 Patient: Religion: unvollständiges ValueSet
o http://fhir.ch/ig/ch-core/ValueSet/ech-11-religion führt mit 1 reformierten, 2 katholischen und 3 jüdischen Konfessionen nur sehr wenige Konfessionen und Religionen auf.
o Das Wissen um den Glauben des Patienten ist im Spital relevant (z.Bsp. für Aufbieten der korrekten Seelsorge bei Komplikationen).
o Folge das sehr unvollständigen ech-11-ValueSets: Die Schweizer Systeme verwenden das vollständigere ValueSet http://terminology.hl7.org/CodeSystem/v3-ReligiousAffiliation (wird durch die Extension ChCorePatientReligion nicht verhindert).
o Vorschlag: Verbleib beim vollständigeren ValueSet http://terminology.hl7.org/CodeSystem/v3-ReligiousAffiliation und Verzicht auf ein Schweizer ValueSet.
 Patient.address: Die Extension ECH0010AddressLine wird nicht berücksichtigt (Fehler)
o Patient.address bezieht sich in CHCorePatient nirgends auf die Extension ECH0010AddressLine (zumindest konnte ich keine entsprechende Referenz finden)
o Ich konnte keine Bsp-CH-Patienteninstanz bauen, die addressLine2 oder postOfficeBox in Patient.address aufführt (zumindest habe ich es trotz einigen Versuchen nicht geschafft)
o Vorschlag: die Extension ECH0010AddressLine in CHCorePatient einbauen
 Patient.extension: patient-citizenship: Fehler: keine Terminologie hinterlegt
o Problem: Die patient-citizenship-Extension gibt nicht vor, aus welcher Terminologie «code» und «display» stammen, es können also für «code» und «display» beliebiger nicht aufeinander abgestimmter Freitext angegeben werden.
o Vorschlag: Die Extension an das ValueSet http://hl7.org/fhir/ValueSet/iso3166-1-2 binden (2-stellige Ländercodes und Display)
 Teilnahme am elektronischen Patientendossier:
o Problem: Ein Flag, welches die Teilnahme des Patienten am elektronischen Patientendossier beschreibt, wird in Schweizer Spitälern zwischen administrativem System und klinischem Informationssystem ausgetauscht. Er fehlt aber dennoch im CHCorePatient.
o Vorschlag: Erweiterung von CHCorePatient um dieses Flag.
 Frage:
o Wie sollen mit kantonsspezifischen Elementen umgegangen werden (in Zürich z.B. spezifische zusätzliche Elemente zur Erhebung der PRISMA Daten, siehe https://gd.zh.ch/dam/gesundheitsdirektion/direktion/themen/gesundheitsinstitutionen/spitaeler_kliniken/handbuecher_vorgaben_erhebungsunterlagen/handbuecher_und_vorgaben/prisma/handbuch_prisma_8.1.pdf.spooler.download.1563456657166.pdf/handbuch_prisma_8.1.pdf). Soll der CHCorePatient um all diese kantonalen Vorgaben ergänzt werden oder soll er für die kantonalen UseCase erweitert werden (Problem: Wartbarkeit der Profile)?
CHCoreEncounter
 Encounter.hospitalization.reAdmission: unvollständiges ValueSet
o CHCoreEncounter verwendet für dieses Element unverändert das Beispiels-ValueSet http://terminology.hl7.org/ValueSet/v2-0092 der FHIR-Ressource Encounter. Dieses führt ausschliesslich den Code «R» für «Re-Admission» auf.
o in Schweizer Spitälern wird zwischen administrativem System und klinischem Informationssystem oft auch der Wert «Verdacht auf Wiedereintritt» ausgetauscht.
o Vorschlag: Encounter.hospitalization.reAdmission soll sich in CHCoreEncounter auf einen anderen ValueSet beziehen, der die Werte «Wiedereintritt» und «Verdacht auf Wiedereintritt» aufführt.
 Unfallkennzeichen und Unfalldatum: fehlen in CHCoreEncounter
o viele in Schweizer Spitälern aktive administrative Systeme senden die zwei Attribute «Unfallkennzeichen» (ob ein Unfall zum Eintritt führte) und «Unfalldatum».
o Das Unfallkennzeichen könnte aus Encounter.reasonCode[*] abgeleitet werden, allerdings stellt sich die Frage, welche SnomedCT-Codes den Unfall als ursächlich für den aktuellen Fall kennzeichnen.
o Vorschlag: Ergänzen von Encounter.hospitalization um Extensions zur Übermittlung eines Boolean Elementes «Unfallkennzeichen» und eines dateTime Elements «Unfalldatum».
ChCorePractitioner
 Practitioner.name, Anrede, Titel («prefix»): fehlende Datenstruktur
o Das FHIR-Element Practitioner.name[*].prefix[*] erlaubt es, dem Namen eine beliebige Anzahl von Präfixe voranzustellen (wie akademische Titel, …).
o In der Schweiz gängige Spital-Administrationssysteme liefern Anrede und akadem. Titel als zwei voneinander unabhängige klar bezeichnete Elemente. «Anrede» lässt sich nicht immer aus dem Geschlecht des Practitioner ableiten (könnte z.Bsp. Name der Gruppenpraxis sein.).
o Eine inoffizielle oder eine Practitioner.name[*].prefix[*] hinterlegte Bemerkung, wonach Practitioner.name[*].prefix[0] der Anrede und Practitioner.name[*].prefix[1] dem Titel entspricht, genügt nicht.
o Vorschlag: Extension von HumanName um die beiden «primitive type»-Elemente (vom Typ string oder code) Anrede und Titel.
 Practitioner.address: Die Extension ECH0010AddressLine wird nicht berücksichtigt (Fehler)
o Practitioner.address bezieht sich in CHCorePractitioner nirgends auf die Extension ECH0010AddressLine (zumindest konnte ich keine entsprechende Referenz finden)
I suggest to make a dedicated workshop to discuss and resolve all comments. The workshop could be held at BFH in Biel or Bern1)
BFS Number eCH-0011: Extension to define a BFS Number for a municipality or a country

Attribute name "ECH011BFSNumber" may not be a suitable name for this extension:
http://fhir.ch/ig/ch-core/StructureDefinition-ch-ext-ech-11-bfsnumber.html
because it is applied to:
{"type"=>"Address.city"} //Semantic OK
{"type"=>"Address.country"} //Semantic NOK, because a country, where a person was born, does not have a BFS Number

Suggestion:
Only use extension for "Address.city" OR change the name of the attribute to include both cases


2)
Address line eCH-0010: Extension to define address lines

This heading suggests "address lines". However in the detail spec:
http://build.fhir.org/ig/hl7ch/ch-core/ValueSet-ech-10-line.html
it looks as if there are “address line types” defined.

Looking at the address structure in more detail:
http://build.fhir.org/ig/hl7ch/ch-core/StructureDefinition-ch-core-address-ech-10.html
in Tab “Differential Table” there is a: “iso21090-ADXP-postBox” as well as a “eCH-010 postOfficeBox”

Suggestion: Re-Discuss the need of having semantically structured address attributes vs going unstructured (eg. addressLine1-addressLine5)


3)
Name eCH-0011: Extension to define first name type

This seems to be a copy/paste error

Suggestion: Rename to "Extension to define name type", also accordingly in subpage:
https://fhir.ch/ig/ch-core/StructureDefinition-ch-ext-ech-11-name.html


4)
EPR Section ID Extension to define the section id
EPR Set ID Extension to define the set id of the document

What is the purpose of these extensions?

Suggestion: Please define the purpose in the subpage. Apparently they are designed to provide grouping.
IMHO all CH extensions should have an explanation (eg in a separate section "Purpose") WHY this extension is needed/introduced and what is the semantic relationship to similar attributes in the related “shadow standard” CDA-CH V2


5)
EPR Version Number Extension to define the version number of the document
http://fhir.ch/ig/ch-core/StructureDefinition-ch-ext-epr-versionnumber.html

Does the same rule as for CDA CH V2 hl7:versionNumber apply here?
INT.NONNEG 1 … 1 M
The versionNumber element MUST contain the value 1 for the very first
version of that document. For later versions, the version number MUST
be increased by 1 each.

Suggestion:
If yes: should this be mentioned on this page?
If not: what is the difference?

6)
Birth Place according to eCH-0011 The registered place of birth of the patient. A sytem may use the address.text if they don't store the birthPlace address in discrete elements.

In eCH-0011 the name "placeOfBirth" is used
In linked original fihr extension the name “birthPlace” is used https://www.hl7.org/fhir/extension-patient-birthplace.html

Suggestion: Rename the attribute to "placeOfBirth" (would be in line with “placeOfOrigin”) or/and help the reader understand why the extension is needed
Typo: "A sytem may" -> "A system may"


7)
Relgion of patient Religion of patient according to eCH-0011

The suggested value set points to eCH-0011:
https://www.ech.ch/de/dokument/7f72f89f-d1e9-49f5-98cd-6ccf1a84065d
Chapter 3.3.4.1 religion - Konfessionszugehörigkeit
However, there are “only” the main religions in CH

CDA-CH suggests the English attribute name "ReligiousAffiliation" and this value set:
https://art-decor.org/art-decor/decor-valuesets--hl7chcda-?id=2.16.840.1.113883.1.11.19185&effectiveDate=

In the Post E-Health platform this attribute is not displayed (according to our knowledge)

Suggestion: Re-Discuss the medical need of this (optional) attribute vs the implications of having this information.
If this attribute is needed for BFS purposes as suggested in “shadow standard” CDA-CH V2 in chapter “Mapping zu eCH-0011 religion – Konfessionszugehörigkeit” please let the reader know.

Typo: "Relgion of patient" -> "Religion of patient"
http://fhir.ch/ig/ch-core/index.html: Section 1.4 Governance: Links to Wiki and Core are obsolete1. In StructureDefinition-ch-ext-ech-11-bfsnumberl: Für Länder kann es keine BFS-Nr. geben.

2. In StructureDefinition-ch-core-address-ech-10: Das Zusammenspiel zwischen dem Inhalt des Elements "line" und seinen Erweiterungen soll geklärt werden. Zurzeit sind inkonsistente Kombinationen möglich.

2a. Das CodingSystem "http://fhir.ch/ig/ch-core/CodeSystem/ech-10" soll entweder nur Teile der Adresse benennen (PostBox, Strasse, ...) oder die Reihenfolge vorgeben (AddressLine1, AddressLine2, ...), aber nicht gleichzeitig beides, weil es ist sonst unklar ist welche Reihenfolge der Elementen sich am Ende im Briefkopf ergeben soll.

3. Bei vielen Extensions fehlt die Beschreibung wofür man sie braucht.

4. Information zu Mappings im Dreieck XDS-CDA-FHIR were sehr sinnvoll.
10
2020/02/141604CDA-CH V2.1 (2020)The primary goal of this project is to represent Swiss concepts defined via CDA exchange artefacts; these are collaborative outputs with agreed approaches to varied kinds of healthcare related information based on the HL/7 CDA specification.
http://e-health-wiki.ch/index.php/Ehscda:CDA-CH_V2.1_2020_(specification)
1510
Yes/Abstain/No
YesYesYesYesAbstainYesYesYesYesYesYesYesYesYesYesYes
11
Comments:
(Req'd if No)
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100