Stream: german (d-a-ch)
Topic: Umgang mit Profilen
André Sander (Jun 25 2020 at 14:42):
Liebe Community,
ich habe eine Frage zum Umgang mit Profilen, wenn ein FHIR Server als Facade implementiert wird, also gegen ein existierendes System geht.
Nehmen wir das Beispiel „Observation“. Dort können ja sowohl Laborwerte als auch z.B. Scores abgespeichert werden.
Nehmen wir zwei konkrete Observations (Instanzen)
O1. Kaliumwert=6.1 mmol/ml
O2. APGAR 5min=9
Und zwei Profile:
P1. Laborwert
P2. Score
Wenn ich nun die Ressource O1 abfrage, dann muss ich die in Profil P1 zurückliefern. Wenn ich Ressource O2 abfrage mit Profil P2. Wenn ich alle Ressourcen abfrage, dann muss ich gemischte Profile zurückgeben. Wenn ich alle Ressourcen mit Profil P1 abfrage, bekomme ich nur Ressource O1. Wenn ich Ressource O2 mit Profil P1 abfrage, darf ich eigentlich nichts zurückliefern, obwohl die Ressource existiert.
Wenn ich noch ein Profil definiere:
P3. Neo-Score
das auch auf Ressource O2 passt, wie liefere ich dann die Ressource O2 zurück, wenn kein Profil bei der Abfrage angegeben wurde?
Wenn ich z.B. den LOINC Code als Basis für eine Entscheidung habe, dann muss ich zunächst voraussetzen, dass alle Observations einen LOINC Code haben. Außerdem müsste ich umfangreiche Maps pflegen. Und was passiert, wenn ein LOINC Code mehr als einem Profil passt?
Aufgefallen ist das initial bei den teilweise widersprüchlichen Definitionen des KDS, der MIOs und der "ambulanten KBV Profilen" für ein und dieselbe Ressource. Und aktuell habe ich das Problem beim Implementieren der unterschiedlichen Fall-Profile, die alle auf Encounter angewendet werden und eine völlig unterschiedliche Transformation der zugrunde liegenden KIS-Fälle erfordert.
Hat da jemand einen Leitfaden oder irgendeine Doku oder möglichwerweise sogar schon eigene Erfahrungen mit gemacht?
René Spronk (Jun 26 2020 at 07:15):
Any FHIR resource type could have lots of profiles associated with it, even for one specific LOINC code. The conformance layer exists to express a 'contract' between two or more systems. As such the set of profiles to use depends on the system/organization you're communicating with, that context (mostly implicitly) defines the set of profiles to use. If the context doesn't imply/specify the use of a particular profile (let's say for your P3) then you're free to use any profile you want, or to use none, because there has not been any prior agreement on the use of specific profiles.
René Spronk (Jun 26 2020 at 07:16):
(Obviously it would be nice to have one set of profiles in a country, and for those to be fully harmonized and synced. But that's unlikely to happen)
Sven Helfer (Jun 26 2020 at 07:18):
You would have something like https://www.ohdsi.org/data-standardization/the-common-data-model/ less flexible, more harmonized ;)
Simone Heckmann (Jun 29 2020 at 07:04):
André Sander said:
Wenn ich z.B. den LOINC Code als Basis für eine Entscheidung habe, dann muss ich zunächst voraussetzen, dass alle Observations einen LOINC Code haben. Außerdem müsste ich umfangreiche Maps pflegen. Und was passiert, wenn ein LOINC Code mehr als einem Profil passt?
Ich denke nicht, dass an solchen Mappings irgendein Weg vorbeiführt, da man bei Fassaden immer damit rechnen muss, dass für unterschiedliche Messungen unterschiedliche Transformationen vorgenommen werden müssen.
Man könnte sich die Sache mit Hilfe eines mehrstufigen Mappings erleichtern, z.B. erst Prüfen, ob auf Ressourcentyp-Ebene bereits ein Mapping festgelegt ist, falls nicht, dann auf Kategorie-Ebene, falls nicht, dann auf Code-Ebene.
Wenn es konkurrierende Profile (z.B: MI-I Patient und eRezept Patient) gibt, wäre es m.M.n. der beste Ansatz, ein neues Profil zu erschaffen, das die Anforderungen beider UseCases vereint und alle Instanzen passend zu diesem Profil zu erzeugen.
Falls das nicht möglich ist, weil (wie im Fall MI-I vs. eRezept) die Übermittlung bestimmter Felder in einem Szenario aus Datenschutzgründen verboten im anderen jedoch erforderlich ist, wäre der einfachste Weg vermutlich die Implementierung eines generischen Filters, der als Input eine Instanz und ein Target-Profil entgegennimmt und als output eine auf die "Must-Support"-Felder reduzierte Instanz zurückgibt.
Damit könnte man dann relativ einfach viele verschiedenen Output-Kanäle bedienen, muss die (aufwändigere) Transformation von proprietärer Datenbank nach FHIR aber nur einmal implementieren.
...ist allerdings, zugegeben, nicht die performanteste Lösung.
Simone Heckmann (Jun 29 2020 at 07:06):
FHIR-native Systeme, die beim Input der Daten bereits gegen alle in Frage kommenden Profile validieren und die erfolgreiche Validierung in den Meta-Daten der Ressourcen festhalten können, haben es da erheblich einfacher...
Simone Heckmann (Jun 29 2020 at 07:13):
Da aktuell viele der vorliegenden Implementierungsleitfäden noch "formbar" sind, sollte es jedoch das vorrangige Ziel der Community sein, konkrete Inkompatibilitäten zwischen den Profilen zu erkennen und hier zu diskutieren. Je mehr davon wir auflösen können, desto einfacher haben wir es hinterher bei der Implementierung!
Frank Oemig (Jun 29 2020 at 08:37):
Es gibt dazu Ausarbeitungen. Rob und ich haben das vor Jahren ausführlich beschrieben. Es gibt dazu auch Einzeldokumente wie das ECCF und RCnL.
André Sander (Jul 01 2020 at 10:24):
Vielen Dank soweit. Ich habe das mit dem Mappings schon befürchtet. Das macht aus Entwicklersicht FHIR wesentlich unattraktiver - zumindest, wenn man eine vorhandene Datenbank mit einer FHIR API versieht. Aber der Tipp mit dem generischen Filter ist gut - Danke!
"FHIR-native Systeme, die beim Input der Daten bereits gegen alle in Frage kommenden Profile validieren und die erfolgreiche Validierung in den Meta-Daten der Ressourcen festhalten können, haben es da erheblich einfacher..."
Was machen denn native FHIR Stores mit Profilen, die zum Zeitpunkt der Erfassung einer Ressource noch gar nicht bekannt waren? Das Datenschutzbeispiel ist ja der Klassiker. In Bundesland A muss der Name entfernt werden, in Bundesland B der ICD-Code verallgemeinert werden. Und beim nächsten DSGVO-Update werden alle Profile nochmal angepasst. Und das Beispiel illustriert auch, dass es nicht immer Sinn macht, die Ressourcen direkt zu bzw. in den Profilen zu speichern - denn primär macht es wohl keinen Sinn im Krankenhaus anonymisierte Daten zu speichern, nur weil ein "Anonymisierungsprofil" exisitiert. Und alle Ressourcen in allen Profilen zu speichern dürfte noch andere Probleme mit sich bringen.
Frank, wo finde ich denn ECCF?
André Sander (Jul 01 2020 at 13:08):
Ich habe noch ein weiteres, interessantes Beispiel:
Nehmen wir die Abfrage "Alle Observations zum Patienten x": soll die
- alle Ressourcen ohne Profil liefern
-
oder einen Mix aus Ressourcen jeweils mit den originären Profilen?
Und noch viel spannender:
Die Abfrage "Alle Observations zum Patienten x mit Profil y": soll die -
nur Ressourcen liefern, die mit Profil y erzeugt wurden
- Oder alle Ressourcen entsprechend transformiert
Simone Heckmann (Jul 01 2020 at 13:37):
André Sander said:
Vielen Dank soweit. Ich habe das mit dem Mappings schon befürchtet. Das macht aus Entwicklersicht FHIR wesentlich unattraktiver - zumindest, wenn man eine vorhandene Datenbank mit einer FHIR API versieht.
Wie sollte denn eine Lösung aussehen (und diese Frage ist absolut ernst gemeint, auch wenn's schnippisch klingt) die für Entwickler attraktiver wäre?
Simone Heckmann (Jul 01 2020 at 13:45):
André Sander said:
Ich habe noch ein weiteres, interessantes Beispiel:
Die Abfrage "Alle Observations zum Patienten x mit Profil y"
Ich weiß, dass das theoretisch in FHIR mit dem _profile-Parameter möglich wäre, aber was wäre dafür der UseCase?
Wenn ich alle "Blutdruckwerte" des Patienten haben möchte, dann würde ich nach dem LOINC-Code suchen, nicht nach Ressourcen, die dem Blutdruck-Profil entsprechen. Wenn ich gewisse Mindestanforderungen an Blutdrücke habe, würde ich die Ergebnisse meiner Suche gegen mein Blutdruck-Profil validieren und würde dabei evtl. feststellen, dass ich ein paar davon nicht gebrauchen kann. Aber in keinem Fall wäre die Behauptung des Servers, die Ressourcen seien gegen irgendein Profil valide, von Belang. Als Empfänger würde ich vor der Verarbeitung immer grundsätzlich gegen mein Profil validieren, das bestimmt, ob ich die Daten verarbeiten kann, oder nicht.
Christof Gessner (Jul 01 2020 at 13:54):
@André Sander ein möglicher Einstieg in die von @Frank Oemig angeteaserte Dimension der Conformance-Problematik ist sicher über die aktuellen Arbeiten der internationalen WG https://confluence.hl7.org/display/CONF/Conformance%2C+Guidance+and+Best+Practices+for+FHIR+Implementation+Guides+Project
ECCF & Co sind vorherige Produkte aus der langen Geschichte der Standardisierung in dem Bereich https://wiki.hl7.org/index.php?title=SAIF_ECCF, auch in DE verwendet z. B. zur Beschreibung der Fallakte https://wiki.hl7.de/index.php?title=HL7_Enterprise_Conformance_and_Compliance_Frameworks
Ob und wie die angesprochenen wichtigen grundsätzlichen Arbeiten hier konkrete Handlungsanweisungen für die Implementierung liefern, müsste vermutlich in einem separaten Thread mal diskutiert werden.
Christof Gessner (Jul 01 2020 at 13:57):
Eine andere Dimension und Sichtweise ist, dass FHIR technisch eigentlich auch komplett ohne Profile funktionieren könnte. Das lenkt den Blick vielleicht hin auf die eigentliche Zielsetzung von Profilen und Konformanzkriterien - und weg von der Notwendigkeit, für alles und jedes erstmal ein eigenes Profil zu benötigen.
André Sander (Jul 01 2020 at 14:40):
Eine Welt ohne Profile - würden auch alle Radfahrer gut finden ;-) Aber im Ernst: wenn die Profile keine implizite Filterung der Ressourcen vornehmen (Observations mit Profil A sind Laborwerte und Observations mit Profil B sind Vitalzeichen). D.h. Profile auf einer Ressource ohne weitere inhaltliche Abhängigkeit.
André Sander (Jul 01 2020 at 14:46):
Bzgl. der Abfrage: man kann auch Observation durch Condition ersetzen - dann funktioniert das Beispiel mit dem Blutdruck nicht mehr, denn ich frage ja nicht beim Patienten nach ICD-10 Codes ab (die eben bei Condition die primäre Codierung wären), sondern ich möchte halt alle Diagnosen haben. Gleiches gilt bei den vier Fall-Arten, die gerade entwickelt werden.
Und wie soll ohne "_profile" Parameter der Server wissen, wie er etwas zurückliefert? Ich bekomme die Daten per ADT, Direktimport und anderes direkt in eine relationale Datenbank. Dann fragt jemand meinen FHIR Server: gib mal alle Diagnosen zum Fall XY. Liefere ich jetzt MII-Diagnosen, oder KBV-Diagnosen? Oder Elga? Ich weiß doch gar nicht wer fragt. Oder liefere ich die Diagnosen in allen Profilen, die ich kenne?
Ich finde den Einwurf von Christof Gessner tatsächlich absolut richtig: Was wollen wir mit Profilen erreichen - warum holen wir uns diese Komplexität ins Haus?
Simone Heckmann (Jul 01 2020 at 14:48):
wenn die Profile keine implizite Filterung der Ressourcen vornehmen (Observations mit Profil A sind Laborwerte und Observations mit Profil B sind Vitalzeichen). D.h. Profile auf einer Ressource ohne weitere inhaltliche Abhängigkeit.
Das sollten Sie meiner (und Grahame's) Meinung nach in der Tat nicht. VitalSigns und Laborwerte erkennt man an Observation.category, nicht am Profil.
Allerdings hatten wir diese Diskussion letztens in Bezug auf die Covid-Conditions, in denen Profile tatsächlich verwendet werden, um Diagnosen thematisch zu gruppieren, die an sonsten nicht durch eine Kategorie unterscheidbar wären. (siehe https://simplifier.net/forschungsnetzcovid-19/~resources?category=Profile&corebasetype=Condition&sortBy=RankScore_desc). Ich habe das bemängelt, wurde jedoch überstimmt.
@dr Kai U. Heitmann @Julian Sass
Simone Heckmann (Jul 01 2020 at 14:54):
Dann fragt jemand meinen FHIR Server: gib mal alle Diagnosen zum Fall XY. Liefere ich jetzt MII-Diagnosen, oder KBV-Diagnosen? Oder Elga? Ich weiß doch gar nicht wer fragt. Oder liefere ich die Diagnosen in allen Profilen, die ich kenne?
ich würde die Diagnosen grundsätzlich so ausliefern, wie ich sie bestmöglich aus den vorhandenen Informationen erstellen kann.
D.h. ich muss dafür sorgen, dass die Instanzen - egal wer fragt - immer alle Anforderungen aller in Frage kommenden Profile erfüllen.
Wenn das nicht geht, weil die KBV z.B. die Belegung einiger Elemente aus Datenschutzgründen verbietet, dann muss ich einen Filter zwischenschalten ("generischer Filter", s.o.).
André Sander (Jul 01 2020 at 14:54):
Kann ich noch ein konkretes Beispiel beisteuern: in einem kleineren Projekt hatte ich die Forderung Conditions, die einen ICD-Code aus dem Kapitel C (Neubildungen) haben, sollen Profil 1 bekommen (da wurde z.B. TNM gefordert) und Conditions, aus dem Kapitel Q bekommen Profil 2 (Stichwort Orphacode) - die Diskussion ging dann soweit, dann man auf einzelne Krankheiten runtergegangen ist und meinte, für ein Leberkarzinom brauche ich das Informationsmodell und für ein Bronchial Ca jenes...
André Sander (Jul 01 2020 at 14:56):
"D.h. ich muss dafür sorgen, dass die Instanzen - egal wer fragt - immer alle Anforderungen aller in Frage kommenden Profile erfüllen." Und genau das geht nicht mit den jetzt definierten Fall-Arten (Abrechnungsfall, Versorgunsfall), wenn man nach Encounter eines Patienten fragt. Dann muss man nämlich je nach Profil die in der Datenbank gespeicherten Fälle ganz unterschiedlich zusammenbauen.
Simone Heckmann (Jul 01 2020 at 14:59):
André Sander said:
"D.h. ich muss dafür sorgen, dass die Instanzen - egal wer fragt - immer alle Anforderungen aller in Frage kommenden Profile erfüllen." Und genau das geht nicht mit den jetzt definierten Fall-Arten (Abrechnungsfall, Versorgunsfall), wenn man nach Encounter eines Patienten fragt. Dann muss man nämlich je nach Profil die in der Datenbank gespeicherten Fälle ganz unterschiedlich zusammenbauen.
Dann bitte Feedback an die Spezifizierer geben, dass das so nicht implementierbar ist und es ein konkretes Unterscheidungsmerkmal geben muss, das einen Versorgungsfall von einem Abrechnungsfall unterscheidet. Notfalls eine Extension. Oder man macht's gleich so, wie's die Spec fordert und modelliert den Abrechnungsfall als Account :smiling_devil:
Noemi Deppenwiese (Jul 01 2020 at 14:59):
Simone Heckmann said:
Das sollten Sie meiner (und Grahame's) Meinung nach in der Tat nicht. VitalSigns und Laborwerte erkennt man an Observation.category, nicht am Profil.
Allerdings hatten wir diese Diskussion letztens in Bezug auf die Covid-Conditions, in denen Profile tatsächlich verwendet werden, um Diagnosen thematisch zu gruppieren, die an sonsten nicht durch eine Kategorie unterscheidbar wären. (siehe https://simplifier.net/forschungsnetzcovid-19/~resources?category=Profile&corebasetype=Condition&sortBy=RankScore_desc). Ich habe das bemängelt, wurde jedoch überstimmt.
dr Kai U. Heitmann Julian Sass
Ich wäre auch dieser Meinung. Solche "selbsterfüllenden" Constraints (Eine gültige instanz ist eine, die sagt, dass sie gültig ist) finde ich persönlich hässlich. Gerade, wenn man davon ausgeht dass Ressourcen idR auch Profile erfüllen, von denen sie nichts wissen. Im COVID-Beispiel wird das meta.profile Feld im Prinzip zweckentfremded, um inhaltliche Aussagen zu treffen. dabei ist es ja ein Feld für meta-informationen.
Stefan Lang (Jul 01 2020 at 15:00):
André Sander said:
die Diskussion ging dann soweit, dann man auf einzelne Krankheiten runtergegangen ist und meinte, für ein Leberkarzinom brauche ich das Informationsmodell und für ein Bronchial Ca jenes...
Das ist in der Tat dann eine Überspezifikation und hat sich bereits in der Vergangenheit als schwer handhabbar und am Ende unwartbar erwiesen. Allein schon beim TNM.
Dennoch sind Profile ein sehr probates Mittel, um Interoperabilität (nicht nur syntaktische, sondern auch semantische) herzustellen.
Simone Heckmann (Jul 01 2020 at 15:01):
André Sander said:
Kann ich noch ein konkretes Beispiel beisteuern: in einem kleineren Projekt hatte ich die Forderung Conditions, die einen ICD-Code aus dem Kapitel C (Neubildungen) haben, sollen Profil 1 bekommen (da wurde z.B. TNM gefordert) und Conditions, aus dem Kapitel Q bekommen Profil 2 (Stichwort Orphacode) - die Diskussion ging dann soweit, dann man auf einzelne Krankheiten runtergegangen ist und meinte, für ein Leberkarzinom brauche ich das Informationsmodell und für ein Bronchial Ca jenes...
In gewissen Grenzen kann man so etwas besser mit Constraints modellieren ("wenn ICD-Code mit C beginnt, dann muss TNM gefüllt sein")
Dafür hat Gott die FHIRPath-Expression Language geschaffen :smirk:
Noemi Deppenwiese (Jul 01 2020 at 15:02):
André Sander said:
"D.h. ich muss dafür sorgen, dass die Instanzen - egal wer fragt - immer alle Anforderungen aller in Frage kommenden Profile erfüllen." Und genau das geht nicht mit den jetzt definierten Fall-Arten (Abrechnungsfall, Versorgunsfall), wenn man nach Encounter eines Patienten fragt. Dann muss man nämlich je nach Profil die in der Datenbank gespeicherten Fälle ganz unterschiedlich zusammenbauen.
Oder, man mappt größere "Informationseinheiten" (ich vermute, die gibt es in der Datenbank sowieso?) dann auf eine Struktur von Profilen wie zB. beim Fall. Dann müsste man bei Anfragen alle "Objekte" evaluieren, ob in ihrer FHIR Struktur eine der angefragten ressourcen vorkommt, und die dann mit allen für die einzelnen teile der Struktur passenden profilen zurückgeben. Oder ist das zu komplex?
Simone Heckmann (Jul 01 2020 at 15:02):
Stefan Lang said:
Dennoch sind Profile ein sehr probates Mittel, um Interoperabilität (nicht nur syntaktische, sondern auch semantische) herzustellen.
Absolut! Bitte lasst mir meine Profile :cold_sweat: !! Aber wir müssen hier Requirement Definition von Implementierung trennen.
Profile sind ersteres!
Simone Heckmann (Jul 01 2020 at 15:07):
Profile dienen dazu, dem Entwickler mitzuteilen, was zu tun ist und der Überprüfung ob man's richtig gemacht hat.
Zur Laufzeit spielen sie eine untergeordnete Rolle.
Klar kann man viel damit (auch zur Laufzeit) zaubern (Stichwort: "generischer Filter", UI-Generierung etc.), aber das sollte "internal" use sein, nicht Teil des Datenaustauschs.
Simone Heckmann (Jul 01 2020 at 15:08):
Noemi Deppenwiese [said](https://chat.fhir.org/#narrow/stream/179183-german-(d-a-
Oder, man mappt größere "Informationseinheiten" (ich vermute, die gibt es in der Datenbank sowieso?) dann auf eine Struktur von Profilen wie zB. beim Fall. Dann müsste man bei Anfragen alle "Objekte" evaluieren, ob in ihrer FHIR Struktur eine der angefragten ressourcen vorkommt, und die dann mit allen für die einzelnen teile der Struktur passenden profilen zurückgeben. Oder ist das zu komplex?
ich musste das jetzt dreimal lesen um es zu verstehen, von daher aus meiner Sicht: ja: zu komplex :laughter_tears:
Frank Oemig (Jul 01 2020 at 15:11):
Die Profildiskussion ist auf der einen Seite gut und wichtig, auf der anderen lenkt sie vom Thema/Problem ab. Wohin Profile führen habe ich in Kap.8 meines Buches beschrieben.
Fhir hat keinerlei Grundanforderungen. Deshalb braucht man Profile - mehr als vorher. Wenn aber - wie es gerade geschieht - jeder auf Teufel komm raus profiliert, dann sieht man den Wald vor lauter Profilen nicht mehr. Nochmal, Fhir ist nur eine Technologie, die laut RM-ODP ganz rechts angesiedelt ist. Die Lösung liegt links im Logikbereich, wo es um die inhaltliche Ausgestaltung geht. Es muss also darum gehen, möglichst wenige Profike zu erstellen. Hierbei sind die gegenseitigen Abhängigkeiten sowohl vertikal als auch horizontal herauszukitzeln. Und das geht nur als Abbildung einer vorher gemeinsam ausgearbeiteten Konzeptualisierung. Letzteres ist aber bisher nicht geschehen und wird außer von mir auch von niemandem gefordert.
Genau das ist im ECCF, dem Enterprise Compliance and Conformance Framework bei hl7.org, beschrieben. Das wurde im Rahmen von V3 ausgearbeitet. Mit Fhir ist das nicht veraltet, sondern aufgrund des fehlenden Architekturframeworks wichtiger als zuvor.
Simone Heckmann (Jul 01 2020 at 15:29):
Frank Oemig said:
Und das geht nur als Abbildung einer vorher gemeinsam ausgearbeiteten Konzeptualisierung.
Warum hätten wir da dann nicht das Problem, dass jeder sein eigenes Ding macht weil keiner die Autorität besitzt, solche Konzepte sektorenübergreifend und deutschlandweit festzulegen?
Frank Oemig (Jul 01 2020 at 15:39):
Das Zauberwort heißt 'gemeinsam'...
Frank Oemig (Jul 01 2020 at 15:39):
Ist vllt. in dem langen Text untergegangen.
Simone Heckmann (Jul 01 2020 at 15:44):
Jo ebent. Daher die Frage: wenn wir es schon nicht schaffen, gemeinsam FHIR Profile festzulegen, warum soll es dann einfacher sein, gemeinsam Datenmodelle festzulegen (wo potentiell noch mehr Parteien mitreden wollen).
Aber wir sollten diesen Thread besser der Lösung der praktischen Implementierungsfragen überlassen, der philosophisch-politische Exkurs führt hier zu weit. Wer daran Interesse hat kann ja wie von Christoph angeregt dazu einen separaten Thread eröffnen.
Frank Oemig (Jul 01 2020 at 16:19):
Message received
Julian Sass (Jul 01 2020 at 18:36):
Noemi Deppenwiese said:
Simone Heckmann said:
Das sollten Sie meiner (und Grahame's) Meinung nach in der Tat nicht. VitalSigns und Laborwerte erkennt man an Observation.category, nicht am Profil.
Allerdings hatten wir diese Diskussion letztens in Bezug auf die Covid-Conditions, in denen Profile tatsächlich verwendet werden, um Diagnosen thematisch zu gruppieren, die an sonsten nicht durch eine Kategorie unterscheidbar wären. (siehe https://simplifier.net/forschungsnetzcovid-19/~resources?category=Profile&corebasetype=Condition&sortBy=RankScore_desc). Ich habe das bemängelt, wurde jedoch überstimmt.
dr Kai U. Heitmann Julian Sass
Ich wäre auch dieser Meinung. Solche "selbsterfüllenden" Constraints (Eine gültige instanz ist eine, die sagt, dass sie gültig ist) finde ich persönlich hässlich. Gerade, wenn man davon ausgeht dass Ressourcen idR auch Profile erfüllen, von denen sie nichts wissen. Im COVID-Beispiel wird das meta.profile Feld im Prinzip zweckentfremded, um inhaltliche Aussagen zu treffen. dabei ist es ja ein Feld für meta-informationen.
Inwiefern unterscheidet sich denn das Covid Beispiel vom zuvor genannten Blutdruck-Profil? Hier trifft meta.profile ja auch keine inhaltliche Aussage nur weil die Canonical "bp" or "bloodpressure" enthält. Meta.profile sagt doch nur gegen welche Anforderungen die Instanz valide sein soll. VitalSigns teilen sich eine Kategorie, trotzdem gibt es für jeden Parameter ein eigenes Profil. Ebenso will man hier bspw eine Condition für lediglich ein bestimmtes Subset von Lungenerkrankungen, was über code etc definiert ist und nicht in meta. Die Semantik der Instanz bliebe darüber hinaus auch ohne meta bestehen. Ich lasse mich gerne vom Gegenteil überzeugen und bin der Unterscheidung über category nicht abgeneigt, mir erscheint aber das Diagnose Profil allein nicht ausreichend, und alles in einem Profil zu definieren würde dies überladen.
Noemi Deppenwiese (Jul 02 2020 at 06:38):
Beim Blutdruck-Beispiel kann man über den LOINC als Entscheidungskriterium gehen. Ob meta.profile das "bp-Profil" enthält ist dabei erstmal egal. Man kann die dann gegen das "bp" Profil validieren um zB sicherzustellen, dass bei der Verarbeitung keine unvorhergesehen Fehler auftreten, wenn man die Anwendung mit Blick auf das bp Profil entwickelt hat.
Im COVID-Beispiel ist die Erfüllung des Profiles Teil des Profiles (so verstehe ich zumindest das meta.profile 1..., ich schätze nicht, dass man hier ein Profil seiner Wahl angeben soll?) , d.h. wenn das System keine Sonderregel für meta.profile einbaut, wird keine der Instanzen als passend erkannt, obwohl es passende Daten geben könnte.
Eine Suche sollte sich wie schon diskutiert und auch nach meiner Meinung auf ein "Unterscheidungsmerkmal" inhaltlicher Natur (momentan wäre das in COVID wohl Condition.code?) stützen und nicht auf das _profile. Eine category wäre da wahrscheinlich praktisch, um nicht eine uU sehr lange oder-Abfrage bauen zu müssen (icd oder sct und dann jeweils noch das ValueSet...).
Julian Sass (Jul 02 2020 at 06:58):
Ja ok das ist ein gutes Argument für ein weiteres Merkmal wie Category :)
Christof Gessner (Jul 02 2020 at 07:04):
Drei unterschiedliche Strategien habe ich bei Implementierungen beobachten können (das betrifft jetzt FHIR-Profiles, aber auch CDA-Templates). Als Beispiel nehme ich mal "Severity". Siehe z. B. im Kontext der IPS https://art-decor.org/art-decor/decor-templates--hl7ips-?id=2.16.840.1.113883.10.22.4.25&effectiveDate=dynamic
-
XPath-Statements, die auf die templateID bzw. meta.profile referenzieren:
*[templateId='2.16.840.1.113883.10.22.4.25'] -
Ausführliche Adressierung der Position in einer Struktur anhand der element names:
Composition.section:sectionPastIllnessHx.entry:pastProblem.severity, oder/ClinicalDocument/[IPS History of Past Illness Section]/entry/[IPS Problem Concern Entry]/entryRelationship/[IPS Problem Entry]/entryRelationship/[IPS Severity Observation]- so z. B. in https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_IPS.pdf -
"Semantische" Adressierung über Merkmale wie Category oder entsprechende CDA/v3-Konstrukte:
*[@classCode='OBS'][@moodCode='EVN'][code[@codeSystem='2.16.840.1.113883.5.4'][@code ='SEV']]bzw.
*[@classCode='OBS'][@moodCode='EVN'][code[concat(@code, @codeSystem) = doc('vs_eHDSIVaccine.xml')//concept/concat(@code, @codeSystem)]]
Last updated: Apr 12 2022 at 19:14 UTC
