FHIR Chat · Verlinkte Diagnosen · german (d-a-ch)

Stream: german (d-a-ch)

Topic: Verlinkte Diagnosen

Simone Heckmann (Mar 11 2016 at 16:53):

Ok. Lloyd hat uns zum Einreichen eines Change Requests ermutigt. Also: jetzt nicht nachlassen! Wir brauchen einen Plan, wie das related Attribut aussehen soll, das sowohl unsere Anforderungen abdeckt als auch Condition und Observation harmonisiert.

Stefan Lang (Mar 11 2016 at 19:04):

Als Ausgangspunkt würde ich relatedItem aus DSTU1 Condition nehmen ( http://www.hl7.org/fhir/dstu1/condition.html )

Stefan Lang (Mar 11 2016 at 19:09):

Die Idee, alternativ zu einer Referenz auch direkt einen Code setzen zu können, kommt einigen Anwendungsfällen in der Praxis sehr entgegen, auch wenn es nicht ganz der reinen Lehre entspricht. Das code Element passt aus meiner Sicht also

Stefan Lang (Mar 11 2016 at 19:12):

Für target sind in DSTU1 folgende Ressourcen möglich: Condition|Procedure|MedicationAdministration| Immunization|MedicationStatement

Stefan Lang (Mar 11 2016 at 19:19):

Da fehlt sicher noch die Observation. AllergyIntolerance wäre auch ein Kandidat. Und es wäre zu klären, ob es da spezifische Einschränkungen bei Condition oder Observation geben muss (ich sehe da erstmal keinen Grund)

Stefan Lang (Mar 11 2016 at 19:25):

Das Value Set für type wäre durch die actRelationships aus V3 zu ersetzen, ist m.E. allerdings Review-würdig, denn die im implementers-Thread genannten Schwierigkeiten, das auszudifferenzieren, kann ich teilweise nachvollziehen.

Stefan Lang (Mar 11 2016 at 19:30):

Evidence könnte hier ebenfalls berücksichtigt werden und damit als eigenes Element entfallen. Bräuchte dann einen eigenen Code in type, denn "evidence is what you think is causing the condition, not what actually is causing it"

Stefan Lang (Mar 11 2016 at 19:33):

Bei type sehe ich eventuell eher den Bedarf für unterschiedliche (Sub-)Value Sets bei Observation und Condition. Da wäre sicher der Input unserer V3/CDA-Gurus hilfreich

Simone Heckmann (Mar 14 2016 at 17:36):

Also eine Einschränkung gibt es: Und zwar sollten Referenzen immer (zeitlich gesehen) zurück zeigen., So dass die Referenz stets in der neueren Ressource gesetzt wird und nicht eine historische Resource geändert werden muss.

Simone Heckmann (Mar 14 2016 at 17:43):

Mein Vorschlag wäre, dass wir uns pro (aus unserer Sicht benötigter) Relation ein Beispiel nennen. Daraus leiten wir dann ab, was wir brauchen. Grundsätzlich sollte das Binding für das ValueSet von reference.type maximal "Preferred" sein. Man weiß ja nie was noch kommt ;-)

Simone Heckmann (Mar 14 2016 at 20:15):

Nach genauerer Betrachtung würde ich eigentlich die Mimik von Observation.related vorziehen. Dort gibt es nur typeund target. Der zusätzliche code stiftet nur Verwirrung, weil es dann jeder anders macht und niemand weiß, was das erwartete Verhalten ist. Außerdem würde das (Neben-)Argument, Condition.related einzuführen, um die Resource mit Observation zu harmonisieren m.E. unsere Chancen auf Erfolg erhöhen.

Stefan Lang (Mar 15 2016 at 10:15):

code könnte man natürlich im konkreten Use Case über ein Profil wegdefinieren. Aber stimmt schon, konsistenter ist es, genau einen Weg der Darstellung zu haben.

Stefan Lang (Mar 15 2016 at 10:19):

Damit wären wir von der Struktur her ohnehin identisch mit Observation.related, daher ein "ja" für den Bezug darauf

Stefan Lang (Mar 15 2016 at 10:23):

Die fixe Zeitrichtung dürfte unkritisch sein, weil grundsätzlich ja jede Beziehung in beide Richtungen ausdrückbar ist. Man muss sich nur klar machen, dass (zum Beispiel) "has-cause" zulässig wäre, "is-cause-of" aber nicht.

Stefan Lang (Mar 15 2016 at 10:29):

Das einzige, was ich da sehe, wäre ein Use Case, in dem z.B. die Frage besteht "Welche Folgeerkrankungen wurden durch Erkrankung X verursacht?". Das als Query darzustellen, stelle ich mir etwas komplexer vor. Die Frage ist allerdings, ob es einen Use Case gibt, in dem das mit FHIR abgebildet werden muss.

Stefan Lang (Mar 15 2016 at 10:36):

Allerdings entspricht das dem CAUS type code aus V3 ("is etiology for")

Stefan Lang (Mar 15 2016 at 10:47):

Demzufolge müssten wir gegenüber V3 die Richtung umdrehen. Beispiel: Nierenversagen "has-cause" => Referenz auf Tumorerkrankung

Stefan Lang (Mar 15 2016 at 10:55):

RSON in V3 dagegen hat schon die aus FHIR-Sicht korrekte Zeitrichtung. Soweit ich sehe, bedeutet RSON den Grund warum ein Actor etwas unternimmt (z.B. eine Medikation oder Prozedur), während CAUS Ursache und Wirkung ausdrückt

Stefan Lang (Mar 15 2016 at 10:59):

In dem Sinn würde sich die Liste der Resourcen weiter ausdehnen auf Procedure und MedicationOrder, z.B. Verordnung von Trastuzumab "has-reason" => Brustkrebs

Stefan Lang (Mar 15 2016 at 11:02):

MFST hat ebenfalls die "richtige" Zeitrichtung. Beispiel: Lebermetastase "is-manifestation-of" => Brustkrebs

Stefan Lang (Mar 15 2016 at 11:17):

SPRT ist z.B. in der CDA-Spezifikation des TNM verwendet (http://wiki.hl7.de/index.php?title=Datei:Diag_tnm_v2.gif). Beispiel: UICC Stadium IV "is-supported-by" => Metastasen vorhanden (M1)

Stefan Lang (Mar 15 2016 at 11:20):

Condition.evidence wäre ebenfalls so abbildbar: Grippe "has-evidence" => Fieber

Stefan Lang (Mar 15 2016 at 11:29):

REFR ist das generische "hat irgendwas damit zu tun". Dafür kann man 1000 Beispiele finden oder auch keins

Stefan Lang (Mar 15 2016 at 11:42):

Was das Binding angeht, würde ich das Value Set allerdings _mindestens_ auf preferred setzen, eher auf required. Der type bestimmt ja letztlich die Semantik der Referenz

Simone Heckmann (Mar 15 2016 at 16:38):

Danke, Stefan, ich denke, daraus lässt sich ein Change Request formulieren.
Bezüglich des Bindings:
Ich meinte eigentlich "Extensible" -heißt: Wenn es im ValueSet einen Code gibt, der das beschreibt, was ich meine, dann muss ich den auch verwenden. Einen abweichenden Code zu verwenden ist nur zulässig, wenn das ValueSet nichts passendes für meinen UseCase enthält.

Stefan Lang (Mar 15 2016 at 17:04):

Aber bitte erstmal als Draft eines Change Requests, da haben sicher auch noch andere eine Meinung. Sollten wir auf jeden Fall in der Arbeitsgruppe abstimmen.

Stefan Lang (Mar 15 2016 at 17:05):

Mit extensible kann ich leben

Stefan Lang (Mar 15 2016 at 17:11):

Minimal aber nicht ganz off topic: eine interessante Diskussion zum Thema "Condition vs Observation" ist in den letzten Tagen auf der fhir@lists.hl7.org . Man darf gespannt sein, was sich daraus noch entwickelt.

Simone Heckmann (Mar 20 2016 at 10:31):

Ich plane, am 7.4. um 9h unsere nächste TelKo abzuhalten und dort dann den ChangeRequest abzustimmen.
Ich habe mir fest vorgenommen, bis dahin die Zeit zu finden, das alles zusammenzuschreiben, Amtshilfe nehme ich jedoch gerne an :)

Simone Heckmann (Mar 20 2016 at 10:52):

Ich hab da schon mal was vorbereitet:
http://wiki.hl7.de/index.php?title=FHIR-Kritzelblock_CRQ_Verlinkte_Diagnosen

Stefan Lang (Mar 20 2016 at 11:20):

Ich hebe mal den Finger bezüglich Amtshilfe ;)

Stefan Lang (Mar 20 2016 at 12:02):

@Simone Heckmann Direkt ins Wiki oder willst Du lieber ein offline-Dokument?

Stefan Lang (Mar 20 2016 at 19:27):

Ich hab mal einen ersten Entwurf im den Wiki-Kritzelblock gestellt. Da sind noch einige ToDos; vor allem wäre zu klären, ob wir das auch z.B. auf Procedure ausdehnen (für Trigger und Reason sehe ich im Condition/Observation Kontext keine echte Anwendung)

Simone Heckmann (Mar 21 2016 at 08:20):

Wir sollten auch schauen, ob wir bei den type-codes von Observation noch Änderungsbedarf sehen, wenn wir schon dabei sind. Die minimal-Version wäre m.E. die Änderung des Bindings auf "preferred". Auch das wiederum mit dem Argument der Harmonisierung von Condition und Observation.

Stefan Lang (Mar 21 2016 at 08:23):

Das "preferred" im Change Request hatte ich mal frech auf "extensible" gesetzt ;)

Simone Heckmann (Mar 21 2016 at 08:23):

Verwegener! ;-)

Stefan Lang (Mar 21 2016 at 08:23):

^^

Stefan Lang (Mar 21 2016 at 08:24):

Bei den type codes erhoffe ich mir sowieso noch ein wenig Feedback/Input aus der Runde

Stefan Lang (Mar 21 2016 at 08:24):

Das Value Set wie jetzt im CR ist erstmal Diskussionsgrundlage

Simone Heckmann (Mar 30 2016 at 19:03):

Gibt es irgendwo einen geeigneten Link, der der geneigten internationalen Community die Logik von +/*-Diagnosen erklärt ?

Patrick Werner (Mar 31 2016 at 10:16):

hier ist ein wenig Kreuz Stern enthalten: http://www.daignet.de/site-content/die-daig/fachorgan/2005/ejomr-2005-vol.10/378(1).pdf

Patrick Werner (Mar 31 2016 at 10:20):

hier noch mehr: http://www.meditec.com/resourcestools/icd-codes/
sogar das DIMDI hat eine englische Erklärung: https://www.dimdi.de/static/en/klassi/icd-10-who/systematik/kategorie.htm

Kennt die internationale Community "dagger and asterisk" nicht? Ist soweit ich weiß doch auch in der ICD10 WHO Version enthalten

Stefan Lang (Mar 31 2016 at 14:11):

AFAIK hat das DIMDI sogar die ICD-10-WHO erstellt, insofern dürfte der DIMDI-Link die Primärquelle sein.
Allerdings sollte man entlastend bedenken, dass ICD-10 zumindest für die US Neuland ist ;-)

Simone Heckmann (Mar 31 2016 at 17:07):

...demnach kennt ICD 10 einzig die Relation "Manifestation of" ?

Patrick Werner (Mar 31 2016 at 17:51):

es kommen auf jeden Fall noch include und exclude1 bzw. exclude2 dazu
https://www.webpt.com/blog/post/how-select-right-icd-10-code-three-easy-steps

Stefan Lang (Apr 01 2016 at 00:09):

Include/exclude sind allerdings semantische Regeln, die global fix in ICD-10 stecken. Müsste m.W. auch im CLAML entsprechend definiert sein, wobei ich gerade nicht weiß, ob es ICD-10-WHO im CLAML-Format gibt.
Kreuz-Stern bildet die Beziehung in einer Instanz (also beim einzelnen Patienten) ab.
Was den Beziehungstyp angeht, ist die Definition bei DIMDI nicht so ganz eindeutig. Einmal heißt es dort "aetiology", das entspricht wörtlich V3 "CAUS", weiter unten dann "manifestation", eqv. MFST.

Stefan Lang (Apr 07 2016 at 07:44):

Ich nehme mir dann gerade mal das Wiki vor

Stefan Lang (Apr 07 2016 at 08:06):

... und done. Ich habe nochmal unten einen Block zum Thema "andere Resourcen" angehängt, damit Trigger und Reason nicht ganz untergehen

Simone Heckmann (Apr 07 2016 at 08:59):

Danke Stefan! Super Arbeit!

Simone Heckmann (Apr 07 2016 at 09:01):

Ich kippe das dann mal in den Implementer-Stream, mal sehen, was passiert...

Simone Heckmann (Apr 07 2016 at 09:10):

Done: https://chat.fhir.org/#narrow/stream/implementers/topic/Related.20Observations.2FConditions
...jetzt alle in Deckung!

Stefan Lang (Apr 07 2016 at 09:14):

Wir überraschen sie im Schlaf ;)

Pascal Pfiffner (Apr 07 2016 at 09:25):

Hatte verpasst, dass ihr das hier diskutiert habt; kurzer Kommentar ist im implementers stream. Danke für all die Arbeit, ich denke das ist eine sehr gute Idee!

Simone Heckmann (Apr 07 2016 at 10:34):

@Stefan Lang : Ist mit den Related Conditions unsere Diskussion zum Thema Todesursache eigentlich durch?

Simone Heckmann (Apr 07 2016 at 10:35):

Das müsste doch damit abgedeckt sein, oder? So sind wir ja erst drauf gekommen :)

Stefan Lang (Apr 07 2016 at 10:42):

So ist es. "caused-by" deckt den Fall ab.

Simone Heckmann (Apr 14 2016 at 16:27):

"caused-by" würde auch ICD-10 */ + abdecken...

Simone Heckmann (Apr 14 2016 at 16:41):

Wie wäre es denn, wenn wir unseren Request dahingehend ändern, dass wir die dueTo-Extension streichen (weil semantisch nicht präzise und nicht kompatibel mit V3) und durch causedBy ersetzen, was dann jedoch in den Core gehört (Begründung: ICD-10 + Todesursache >80%).

Simone Heckmann (Apr 14 2016 at 16:41):

Mit "evidence" und "causedBy" kämen wir ja schon ziemlich weit.

Simone Heckmann (Apr 14 2016 at 16:42):

Da ich eine Tendenz erkenne, Observation an Condition anzugleichen (eher so als anders herum), sollten wir überlegen, welche Relations wir in den 80% sehen.

Simone Heckmann (Apr 14 2016 at 16:43):

Grahame Grieve 7:12 AM
Observation related observations are a tricky beast. You absolutely need component and panel (member). I don't have a strong feeling for the others

Simone Heckmann (Apr 14 2016 at 16:44):

...muss gestehen: ich auch nicht...

Stefan Lang (Apr 27 2016 at 16:04):

Die Frage ist zwar fast 2 Wochen alt, aber: ja, sehe ich genauso. Ohne zusätzliche Use Cases, die die 80% belegen, wird sonst nichts in den FHIR Core einfließen. Und in FHIR wird so etwas, wie der Diskussion im Implementers-Thread gezeigt hat, eben nicht über Type Codes, sondern über diskrete Elemente gelöst, sprich: wie z.B. Condition.evidence.
Ich kann den CR gern vor der nächsten Telko entsprechend umschreiben, falls niemand Einwände hat.

Simone Heckmann (May 08 2016 at 16:08):

@Stefan Lang : gerne! Ich werde mal sehen, was sich hier auf dem WGM noch diesbezüglich ergibt...

Stefan Lang (May 09 2016 at 09:34):

OK, dann warte ich das erst nochmal ab.

Simone Heckmann (May 12 2016 at 18:03):

For further reference:
http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=9970

Stefan Lang (May 31 2016 at 19:24):

[x] done. Viel ist vom ursprünglichen CRQ nicht übrig ...

Simone Heckmann (Jun 01 2016 at 13:48):

Hi,
folgendes Update diesbezüglich:

Proposed methodology:
The use of a "code + reference" pattern is discouraged,
particularly where the number of relationships is low.
The rationale is as follows:
- it creates more complex instances
- it requires slicing to apply constraints to what relationships are supported,
 what cardinalities are allowed, which resource types are permitted, etc.
- it creates the possibility of ambiguity as to what's in core.
Relationships that aren't part of core shouldn't be included as part of core
whether explicit relationships or the code+reference approach is used
code + reference is appropriate if the number of "core" relationship types is large (>~5)
and the referenced type choices make sense for all of the relationship types.
Should ideally be consistent across resources from the same "families" as per QA rules.

2016/05/31 Motion: Grahame Grieve/Rob Hausam: 4-0-0
Will send this out to FHIR list for discussion.

Damit kann ich persönlich gut leben. Sieht das jemand anders?
Passt auch ganz prima zu unserem überarbeiteten Change Request (Danke @Stefan Lang :wave: )

Simone Heckmann (Jun 01 2016 at 13:58):

Nebenbei: Wenn Observation gemäß der o.g. Kriterien angepasst werden sollte, muss man davon ausgehen, dass einige der Reference-Types zu Core-Elementen zerlegt, andere jedoch in die Extensions verbannt werden. Gibt es aus unserer Sicht "schützenswerte" Referenzen, die wir auf jeden Fall im Core behalten möchten?

Stefan Lang (Jun 01 2016 at 14:34):

... das wäre dann ggf. sinnvollerweise noch im CRQ unterzubringen; dort steht momentan, dass wir das Ausdifferenzieren für Observation der internationalen Community anheim geben

Grahame Grieve (Jun 01 2016 at 20:57):

yes. this was probably the reverse of what you wanted...

Simone Heckmann (Jun 16 2016 at 12:20):

zur Kenntnis:

Submitted on Fri, 03 Jun 2016 14:57:44 +0200 by

Lloyd McKenzie

The question isn't so much the commonness of the situation - one condition caused by another, 
is it is whether most systems support explicit linking between conditions 
(as opposed to simply capturing the situation in text).  
The belief of the work group is that this capability isn't wide-spread 
when you look at all of the different types of systems that capture diagnosis/condition/problem information.  
If we had strong evidence of widespread existing capability here in numerous countries, 
we could move the elements from being extensions.  
But, in the absense of that, general FHIR policy is to leave the extensions as extensions 
and monitor to see what production systems using FHIR tend to do.
Note that the ICD10 use-case could be met by simply conveying the dagger notation inside the "code" element.  
In this manner, ICD10 is behaving like a post-coordinated code system, much like SNOMED-CT
(which would also use terminology conventions, not modeling conventions to convey relationships between conditions).

Simone Heckmann (Jun 16 2016 at 16:48):

Zumindest ein System würde mir einfallen, das Diagnosen intern verlinkt: ISH. Jedenfalls muss man, wenn man +/*-Diagnosen per BAPI verbucht immer die Zeilennummer der referenzierten Diagnose angeben, anderenfalls erhält man einen Verbuchungsfehler. (Es sei denn, das ist nur eine Entwickler-Schikane :D )

Stefan Lang (Jun 17 2016 at 08:35):

Es ist zumindest mal davon auszugehen, dass z.B. Codiertools (3M KODIP u.a.) die Kreuz-Stern-Beziehungen abbilden und auch kommunizieren, sofern das KIS das verarbeiten kann.
Tumordokumentationssysteme (in Deutschland) bilden speziell die Todesursache-Beziehung praktisch immer auf die eine oder andere Weise ab und diese Information ist auch meist Bestandteil der Datenübermittlung. Ich fürchte allerdings, dass dieses Argument allein nicht reichen wird.

Zu den KIS-Systemen sollten wir auf jeden Fall nochmal recherchieren (Mailingliste?). Wenn da nichts zurück kommt, wird es wohl bei der Extension bleiben.

Peter Scholz (Jun 17 2016 at 10:05):

Wenn ich es noch einmal recht bedenke, so ist die kreuz-stern notation noch ganz brauchbar wenn es nur ein solches Paar gibt. Sobald man mal mehrere hat wird es putzig

Stefan Lang (Jun 17 2016 at 11:11):

Das ist allerdings (zumindest aus meiner Sicht) ein starkes Argument.
Der Punkt ist: wenn wir nicht nachweisen, dass eine nennenswerte Zahl Systeme das, unter anderem aus diesem Grund, intern abbilden (z.B. so, wie Simone es für ISH beschrieben hat), bleibt es Extension.
FHIR will nun mal die Möglichkeiten von Real-Life-Systemen abbilden, nicht ein möglichst umfassendes Modell.

Peter Scholz (Jun 17 2016 at 12:01):

Das ist auch nicht schlimm.
Über ein System wie IS-H müssen wir uns die nächsten 60 Jahre keine Gedanken machen, so lange werden die sicherlich eh keine FHIR Interface entwickeln ;)
Bei den meisten KIS/PDV Systemen sehe ich das ähnlich. Die haben existente Schnittstellen über die sie Diagnosen/Prozeduren etc gemeldet haben wollen, die werden keinen FHIR Server dafür aufsetzen.
Von daher trifft es eh eher Leute wie Simone oder meine Person, die im Bereich der Integration Server unterwegs sind, und uns kann das eigentlich solange egal sein, solange wir nicht mehrere verknüpfte Entitäten in einer Transaktion bekommen.

Ich bin mir momentan auch noch nicht über den wirklichen Use Case von Diagnose-Resourcen sicher. Probleme bekommen, die Applikationen die irgendwann mal eine Diagnosen-Liste abfragen wollen, da muss das mit der verlinkung dann sauber funktionieren, und nicht über +* da man dort nicht weiss welches + zu welchem Stern gehört

Peter Scholz (Jun 17 2016 at 12:03):

Ich denke hier müssen wir auch noch einmal in einen Findungsprozess eintreten was denn konkrete Szenarien für solche Resourcen sind. Und das vor der Frage : Welche Interaktionen mit einer bestimmtren Ressource werden wirklich stattfinden. Und nicht wie können wir die bisherige V2 Kommunikation mit FHIR ablösen, letzteres wird so schnell nicht passieren.

Wir haben immer noch einen holistischen Ansatz was solche Standards angeht und wollen uns für alle möglichen Fälle vorab absichern,

Stefan Lang (Jun 17 2016 at 14:08):

... und der holistische Ansatz funktioniert nicht, das ist ja die Grundannahme der FHIR-Philosophie ;-)

Bei der In-House-Kommunikation hast Du sicher Recht. Bis da v2 abgelöst wird, vergehen mehr als nur ein paar Jahre.

Spannend wird es halt dort, wo die internen Systeme nach außen geöffnet werden und (mobile) 3rd-Party-Systeme Daten ins KH oder in die Arztpraxis senden (chronische Erkrankungen, AAL usw. - die Beispiele sind praktisch täglich in der Fachpresse). Natürlich steht da in irgendeiner Form ein Proxy (aka Kommunikationsserver) zwischen dem externen Gerät und dem KIS/PDMS. Wenn das KIS (wie ISH) die Verknüpfung braucht (egal, ob als v2, v3, CDA, FHIR, xDT oder meinetwegen CSV-File), muss sie aus den eingehenden (FHIR-)Daten hervorgehen.
Insofern hat das also schon einen Einfluss ;-)

Stefan Lang (Jun 17 2016 at 14:11):

Wobei: konkrete Use Cases braucht es wohl schon. Da bin ich völlig bei Dir.

Peter Scholz (Jun 17 2016 at 14:27):

Wir müssen halt nur aufpassen, nicht in die alte Denke zu verfallen jedes mögliche Szenario abbilden zu wollen/müssen

Ich frage mich z.B. schon welche mobile App wohl verlinkte Diagnosen versenden möchte. Diagnosenstellung vor allem solch qualifizierter Art wie +* kommen doch eher von Ärzten und eher nicht aus irgendeiner App.

Daher auch mein Einwurf, das wir uns über die Use Cases vor dem Hintergrund der Nowendigkeit einer FHIR kommunikation Gedanken machen sollten. Dann kann es durchaus der Fall sein, das die Welt mit einem Mal deutlich simpler wird ;)

Stefan Lang (Jun 20 2016 at 08:14):

K.I.S.S. ;-)

Simone Heckmann (Jun 21 2016 at 08:48):

Also ich bin diesbezüglich auch noch mal in mich gegangen und zu folgendem Schluss gekommen:

Wenn es in einem bestimmten use case *wirklich* relevant ist, wie Diagnosen voneinander abhängen und solche Relationen wie "verursacht durch", "in Folge von", "Manifestation von" abgebildet werden sollen, die dann wahlweise auch noch auf Resourcen wie Allergien, Prozeduren und Medikamente referenzieren können, versuchen wir im Prinzip nichts anderes, als mit Hilfe von FHIR Resourcen eine klinische Terminologie nachzubauen. Dass das sehr schnell in exorbitante Komplexität ausartet, dürfte jedem klar sein. Das lässt sich dann auch nicht mehr mit Validierungsregeln einfangen. Da das am Ende dann auch keiner mehr kapiert, weder Anwender noch Implementierer, sind Tür und Tor offen für ein Datenqualität, die am Ende so miserabel ist, dass man sich die komplexen Auswertungen, für deren Zweck man sich das Ganze ausgedacht hat, ohnehin vors Knie nageln kann.

Also meine persönliche Meinung dazu wäre: Eine Condition besteht aus einem Code mit ein bisschen Deko drum herum und fertig. In 80% der Fälle genügt das. Wenn der Use case jedoch komplexe klinische Zusammenhänge darstellen soll und polyhierarchische Abhängigkeiten, Kausativitäten, Lokalisationen und weiss-der-Geier-was benötigt, dann:
Kauft euch eine SNOMED-Lizenz!
...und es kann selbst dann dabei bleiben: Eine Condition besteht aus einem Code mit ein bisschen Deko drum herum...

Stefan Lang (Jun 30 2016 at 11:14):

Ich denke, dann sind wir uns da einig. Lesson learned: Komplexität nur dort einfordern, wo sie nötig ist und wenn sie nötig ist.
Sonst versuchen wir am Ende, CDA nachzubauen.

dr Kai U. Heitmann (Aug 19 2016 at 07:21):

Hallo @Simone Heckmann und @Stefan Lang : wo findet man diese Erkenntnisse dokumentiert, zB im Wiki?

Last updated: Apr 12 2022 at 19:14 UTC