Skip to content

Commit 86ddabb

Browse files
dkapitandkapitan
committed
Update informatie/syntactisch.md
1 parent c7d469e commit 86ddabb

File tree

4 files changed

+58
-4
lines changed

4 files changed

+58
-4
lines changed

‎docs/informatie/index.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -19,7 +19,7 @@ Om gezondheidsgegevens zinnig te kunnen hergebruiken moet de vorm (syntax) en be
1919

2020

2121
## Informatiemodellen voor syntactische interoperabiliteit
22-
Om gegevens technisch uit te wisselen, hebben we standaarden nodig die de **structuur** bepalen.In de zorg kent vele informatie modellen, maar in de afgelopen jaar is de sector aan het convergeren naar openEHR, OMOP en FHIR als de belangrijkste informatiemodellen.[@tsafnat2024converge] Hoewel ze ook betekenis (semantiek) bevatten, is hun belangrijkste functie dat ze de "container" voor de data.
22+
Om gegevens technisch uit te wisselen, hebben we standaarden nodig die de **structuur** bepalen. De zorg kent veel verschillende informatie modellen, maar in de afgelopen jaar is de sector aan het convergeren naar openEHR, OMOP en FHIR als de belangrijkste informatiemodellen.[@tsafnat2024converge] Hoewel ze ook betekenis (semantiek) bevatten, is hun belangrijkste functie dat ze de "container" voor de data.
2323

2424

2525

@@ -62,4 +62,4 @@ Semantische interoperabiliteit is erop gericht om verschillende computersystemen
6262

6363
Het is goed om op te merken dat alle syntatische standaarden (FHIR, OMOP, openEHR) altijd gebruik maken van meerdere KOS componenten. Op zijn moeten codelijsten (taxonomieen) gebruikt worden, in het meest uitgebreide geval wordt een ontologie gebruikt. Zo wordt SNOMED vrijwel altijd gebruikt bij implementaties van OMOP, openEHR en FHIR.
6464

65-
In het volgende wordt beschreven hoe syntactische en semantische gerealiseerd kan worden binnen de architectuur voor secundair gebruik van data.
65+
De TEHDAS2 stelt dat BVOs functionaliteit moet aanbieden om semantische en syntactische interoperabiliteit te realiseren (zie FCR-1 en FCR-2 in de [TEHDAS2 requirements](../appendix/tehdas2-requirements.md)). In het volgende wordt beschreven hoe dit gerealiseerd kan worden binnen de datastations.

‎docs/informatie/semantisch.md‎

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,17 @@
22

33
## 3.2.1. Niveaus van semantische interoperabiliteit
44

5+
6+
7+
Er zijn reeds verschillende thesauri beschikbaar, maar die worden nog te weinig gebruikt. Er zijn ook al vertalingen tussen verschillende thesauri
8+
9+
- DHD diagnose thesaurus: koppelt ICD10, Snomed en het Nederlandse DBC systeem
10+
- DHD verrichting thesaurus: ...
11+
- Z-Index mapping naar RxNorm van ErasmusMC
12+
- Artikel Cornet et al. van Z-index naar ATC naar RxNorm
13+
14+
De rol van generatieve AI c.q. LLMs: hulpmiddel om ongestructureerde data (vrij tekst) om te zetten naar gestructureerde data (in een gekozen informatiemodel, gecodeerd met een gekozen terminologieyysteem)
15+
516
Ontology pipeline paper en ANSI standaard uitleggen
617

718
## 3.2.2. Bestaande thesauri en terminologie stelsel

‎docs/informatie/syntactic-convergence.png‎

32.2 KB
Loading

‎docs/informatie/syntactisch.md‎

Lines changed: 45 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,47 @@
11
# 3.1. Syntactische interoperabiliteit
2-
## 3.1.1. Convergentie van de drie grootste informatiemodellen
32

4-
## 3.1.2. Resultaten van hackathon beschrijven
3+
## 3.1.1. Convergentie van openEHR, FHIR en OMOP
4+
5+
![](syntactic-convergence.png)
6+
7+
In de zorg worden veel verschillende informatie modellen gebruikt, maar in de afgelopen jaar is de sector aan het convergeren naar openEHR, OMOP en FHIR als de belangrijkste informatiemodellen.[@tsafnat2024converge] Om syntactische interoperabiliteit tussen deze drie standaarden te realiseren, is het noodzakelijk om specificaties c.q. mappings op te stellen hoe elementen uit het ene informatiemodel vertaald moeten worden naar het andere. Idealiter staan deze formele mappingsspecificaties los van de specifieke implementatie van software om de mappings daadwerkelijk te realiseren, zoals in bovenstaand diagram is weergegeven.
8+
9+
10+
## 3.1.2. Formele specificaties voor syntactische mappings
11+
12+
Ten tijde van het schrijven van dit document zijn de volgende (eerste versies van) formele mappingsspecificaties beschikbaar.
13+
14+
15+
=== "**FHIRconnect**"
16+
17+
De [FHIRconnect Specificatie](https://sevkohler.github.io/FHIRconnect-spec/build/site/FHIRconnect/v1.0.0/index.html). Deze aanpak gebruikt een Domain Specific Language (DSL) om mappings te definiëren. Het abstraheert de transformatielogica naar "Mapping Templates" die onafhankelijk zijn van de onderliggende programmeertaal.
18+
19+
=== "**HL7 FHIR-OMOP IG**"
20+
21+
De [HL7 FHIR-OMOP Implementation Guide](https://build.fhir.org/ig/HL7/fhir-omop-ig/) biedt de formele regels voor cross-paradigma mapping, waarbij het transactionele karakter van FHIR en het longitudinale karakter van OMOP worden verzoend.
22+
23+
=== "OMOCL"
24+
25+
De [OMOP Conversione Language](https://www.sciencedirect.com/science/article/pii/S1532046423001582) is een domein-specifieke taal waarin mapping van openEHR archetypes zijn gemaakt naar het OMOP CDM. Het is het resultaat van ee onderzoeksproject en is in juli 2025 ter consultatie voorgelegd aan de openEHR community met als doel om het als formele specificatie te adopteren. EOS is de referentie implementatie van OMOCL.
26+
27+
28+
## 3.1.3. Implementaties van syntactische mappings
29+
30+
Implementaties zijn de uitvoeringsmotoren (engines) die de formele specificaties interpreteren om gegevens te transformeren of te verplaatsen. Daarbij wordt onderscheidt gemaakt tussen twee verschillende implementatie patronen.
31+
32+
1. Een facade-patroon implementeert een real-time mapping laag bovenop een bestaande database.
33+
2. Een ETL-patroon implementeert data transformatie 'straten' die periodiek (typisch dagelijks) de data van het ene formaat naar het andere vertalen. Dit patroon komt uit datawarehousing.
34+
35+
=== "**openFHIR**"
36+
37+
[openFHIR](https://open-fhir.com/#access) is een commerciele implementatie van de FHIRconnect specificatie. Het gebruikt een facade-patroon om bi-directioneel FHIR data in openEHR op te slaan, en FHIR data uit openEHR te lezen.
38+
39+
=== "**EOS**"
40+
41+
Het [Eos Framework](https://github.com/SevKohler/Eos) is de referentieimplementatie van de OMOCL mappingspecificatie. Het volgt een ETL patroon en is geimplementeerd in Java.
42+
43+
=== "**OMOPonFHIR**"
44+
45+
Het [OMOPonFHIR](https://github.com/omoponfhir) project levert de softwarecomponenten (servers, adapters) die de bidirectionele FHIR interface realiseren bovenop het OMP CDM. Deze oplossing volgt een facade-patroon: wanneer een client een FHIR `Observation` opvraagt via een REST API, onderschept de facade-laag het verzoek, voert een query uit op de onderliggende OMOP `MEASUREMENT`-tabel in real-time, en transformeert het resultaat naar een FHIR JSON-resource middels de formele specificatie. Middels dit facase patroon kunnen FHIR berichten ook worden opgeslagen in de OMOP database. OMOPonFHIR gaat uit van OMOP CDM 5.4 en FHIR v4 en is geimplementeerd in Java. Het is ontwikkeld voordat de HL7 FHIR-OMOP IG beschikbaar was en heeft daarom de mappings zelf gedefinieerd.
46+
47+

0 commit comments

Comments
 (0)