Grahame Grieve hat einen Beitrag in seinem Blog über die Persistenz von FHIR-Ressourcen veröffentlicht — hier lesen. Die zentrale Frage, die er behandelt, lautet: Wie sollen FHIR-Ressourcen gespeichert werden — sollen wir sie „so wie sie sind" mittels JSON (ProtoBuf usw.) in eine Datenbank ablegen oder ein eigenes Schema erstellen?
Format für die Persistenz
Grahames erste These lautet, dass das FHIR-Format für den Informationsaustausch konzipiert wurde, nicht für die Persistenz. Wir (Health Samurai) diskutieren mit der FHIR-Community die Möglichkeit, die FHIR-Formatspezifikation für die Persistenz zu nutzen. Grahame schließt diese Möglichkeit in seinem Beitrag jedoch nicht aus! Damit ist dies eines der Themen, die wir auf unserem Connectathon-Track besprechen werden — Storage & Analytics on FHIR.
Spezialisierte vs. generische Systeme
Grahame unterscheidet zwischen spezialisierten Systemen mit festem Modell und eher generischen Systemen (z. B. Clinical Data Repositories). Im ersten Fall können Sie potenziell ein effizienteres Schema zum Speichern und Abfragen Ihrer Daten entwerfen. Je generischer Ihr System jedoch wird, desto attraktiver wird es, FHIR-Ressourcen unverändert zu speichern.
Ich möchte einige Gedanken dazu teilen.
Strukturelle Komplexität der Health-IT
Meiner Meinung nach ist ein gutes Informationsmodell eines der anspruchsvollsten Probleme in der Health-IT.
Was macht ein Informationsmodell gut? Ein gutes Modell ist gegenüber Änderungen in Anforderungen und Anwendungsfällen robust, weil es objektive Beziehungen zur realen Welt aufweist. Jeder, der in der Health-IT gearbeitet hat, weiß, wie schwierig es ist, dies richtig hinzubekommen. Unsere Domäne ist komplex. Einer der Werte, den FHIR bietet, ist ein sofort einsatzbereites Informationsmodell, das gut genug ist. Wenn Sie kein Health-IT-Experte mit langjähriger Erfahrung sind und die nächste Health-IT-Anwendung entwickeln möchten, empfehle ich, mit dem FHIR-Datenmodell zu beginnen, das viel Expertenwissen angesammelt hat. An diesem Punkt wäre ein gut abgestimmtes technisches Framework wünschenswert.
Isomorphismus und Transformationen
Wenn Sie ein eigenes Schema/Modell haben und FHIR unterstützen möchten, werden Sie mit der Transformation von Ihrem Modell zu FHIR und zurück konfrontiert. Eine solche Transformation ist trivial, wenn Ihr Modell zu FHIR isomorph ist. Wenn die zu übersetzenden Modelle jedoch nicht miteinander übereinstimmen, haben Sie ein großes Problem. Es gibt das bekannte Object-relational impedance mismatch. Ein weiteres Beispiel aus der Health-IT: Die Übersetzung von HL7 v.2 nach FHIR ist recht einfach — sie sind ähnlich —, aber eine Übersetzung von HL7 v.3 nach FHIR ist ein Albtraum — sie sind auf völlig unterschiedliche Weise konzipiert.
Dokumente vs. Tabellen
FHIR-Ressourcen sind als Aggregates aus dem Domain Driven Design konzipiert. Die NoSQL-Bewegung hat festgestellt, dass die Verwendung von Dokumentdatenbanken gut mit dem Aggregate-Ansatz harmoniert. Wenn Sie versuchen, eine normalisierte relationale Datenbank für FHIR-Ressourcen zu erstellen, erhalten Sie Tausende von generierten Tabellen. Die Arbeit mit so vielen Tabellen ist nicht trivial. Die meisten Operationen erfordern eine Ressource als Aggregat, und das Abrufen bzw. Bearbeiten einer Ressource aus einem Dutzend Tabellen ist aufwendig und hat Auswirkungen auf die Performance.
Offen vs. Geschlossen
Ein weiterer kritischer Aspekt, den es zu berücksichtigen gilt, ist die Frage, ob Ihr System offen oder geschlossen ist.
In einem offenen System ermöglichen Sie potenziell eine flexible Erweiterung des Modells — das Hinzufügen neuer Attribute und Einschränkungen zu bestehenden Entitäten. In FHIR gibt es dafür Extensions für FHIR-Ressourcen. Reale Systeme entwickeln sich in der Regel zu offenen Systemen. Ein offenes System mit einem strikten Schema aufzubauen, ist eine erhebliche Herausforderung. Der Dokumentansatz ermöglicht Flexibilität und Erweiterbarkeit wesentlich einfacher.
Dokument-/Relationale Datenbanken
Die meisten etablierten relationalen Datenbanken (PostgreSQL, Oracle, MySQL und MS SQL) sowie moderne Datenbanken wie Spark, BigQuery und Spanner erlauben die gleichzeitige Nutzung von SQL, Relationen und Dokumenten. Sie können also einen hybriden Ansatz verfolgen — Ihre Ressourcen effizient unverändert speichern (ohne Transformationsschichten) und gleichzeitig die Stärken von SQL sowie weitere Datenbankfunktionen (Transaktionen, Indizierung usw.) nutzen.
Fazit
Ich denke, dass die Speicherung von FHIR-Ressourcen „so wie sie sind" mit modernen Technologien wie PostgreSQL/jsonb oder BigQuery/ProtoBuf ein sehr vielversprechender Ansatz ist, der in Betracht gezogen werden sollte, wenn Sie ein neues Health-IT-System oder eine neue Analyseplattform aufbauen.
Beteiligen Sie sich an der Diskussion!
Um solche Themen zu besprechen, werden Sie Teil unserer Gruppen Analytics on FHIR und Storage on FHIR. Treffen Sie uns persönlich beim Storage & Analytics Connectathon-Track. Wir freuen uns über Ihre Teilnahme und Ihre Gedanken.
Siehe auch: SQL on FHIR: Ein Blick ins Innere und FHIR produktionsreif machen.
