Krótka odpowiedź: dane dotyczące zdrowia poruszają się w czterech warstwach standardów. Standardy wymiany przenoszą dane między systemami: komunikaty HL7 v2, dokumenty CDA, zasoby FHIR i DICOM dla obrazów. Standardy modelowania i przechowywania określają, jak rekord jest strukturyzowany wewnątrz systemu: openEHR dla rekordów klinicznych, OMOP dla baz danych badawczych. Terminologie nadają każdemu pojęciu kod, który obie strony rozumieją: SNOMED CT, LOINC, ICD, ATC, UCUM, RxNorm. Standardy tożsamości i bezpieczeństwa decydują, kto może co czytać: OAuth 2.0 i SMART on FHIR, a także profile IHE, które łączą wszystko powyższe w przetestowane przepisy. Nikt nie używa tylko jednego; szpital zazwyczaj działa na wszystkich czterech warstwach jednocześnie.
Mapa
Standardy interoperacyjności w ochronie zdrowia tworzą cztery warstwy. Standardy wymiany (HL7 v2, CDA, FHIR, DICOM i DICOMweb) przesyłają dane między systemami, a profile IHE łączą je w przetestowane rozwiązania. openEHR strukturyzuje przechowywane rekordy, a OMOP strukturyzuje bazy danych do badań. Terminologie takie jak SNOMED CT i LOINC oraz standardy tożsamości, takie jak SMART on FHIR, są używane we wszystkich z nich.
| Warstwa | Standard | Co to jest | Gdzie można go spotkać w 2026 roku |
|---|---|---|---|
| Wymiana | HL7 v2 | Komunikaty rozdzielane pionową kreską (ADT, ORU, ORM, SIU) przez MLLP | Wewnątrz szpitali: przyjęcia, wyniki laboratoryjne, zlecenia, harmonogramy. Nadal najczęstszy interfejs |
| Wymiana | CDA / C-CDA | Dokumenty kliniczne XML z częścią czytelną dla człowieka i kodowanymi wpisami | Podsumowania wypisów, listy skierowań, amerykański C-CDA, transgraniczne podsumowania w MyHealth@EU |
| Wymiana | FHIR (R4, R4B, R5) | Zasoby internetowe (Patient, Observation, Condition…) przez REST i JSON | Aplikacje pacjenta, krajowe API, API EHR, US Core, format wymiany EHDS |
| Wymiana | DICOM i DICOMweb | Obiekty obrazów z osadzonymi metadanymi; DICOMweb to jego interfejs REST | Każdy skaner, PACS i przeglądarka radiologiczna; przeglądarki internetowe używają DICOMweb |
| Przepisy | Profile IHE | Przetestowane kombinacje powyższych dla jednego przypadku użycia (XDS, PIX/PDQ, XCA, SWF) | Udostępnianie dokumentów między szpitalami i regionami, tożsamość pacjenta, przepływ pracy w radiologii |
| Przechowywanie | openEHR | Model danych klinicznych oparty na archetypach dla samego rekordu | Szpitalne i krajowe platformy EHR w części Europy, Skandynawii, Brazylii |
| Badania | OMOP CDM | Wspólny model relacyjny dla badań obserwacyjnych | Sieci badawcze, dane z rzeczywistego świata, wtórne wykorzystanie EHDS |
| Terminologia | SNOMED CT, LOINC, ICD-10/11, ATC, RxNorm, UCUM | Kody dla wyników, badań, diagnoz, leków, jednostek | Wewnątrz każdego z powyższych standardów |
| Tożsamość | OAuth 2.0, OpenID Connect, SMART on FHIR, IHE XUA | Kim jest użytkownik i do czego aplikacja ma dostęp | Każda aplikacja skierowana do pacjenta i każda platforma aplikacji EHR |
Jak warstwy pasują do siebie
Warstwy standardów interoperacyjności w ochronie zdrowia pasują do siebie, ponieważ każda wykonuje jedno zadanie w tym samym przepływie pracy: wiadomość HL7 v2 przenosi zlecenie laboratoryjne, kody LOINC i UCUM kodują wynik, platforma openEHR go przechowuje, API FHIR udostępnia go aplikacji pacjenta po zalogowaniu SMART on FHIR, a dokument CDA udostępnia go innemu szpitalowi.
Wynik badania krwi pokazuje wszystkie cztery warstwy w jedno popołudnie. Zlecenie opuszcza oddział jako komunikat HL7 v2 ORM (wymiana). Wynik analizatora wraca jako HL7 v2 ORU, z badaniem zakodowanym w LOINC, a jednostką w UCUM (terminologia). Szpital przechowuje go we własnej bazie danych, być może na platformie openEHR (przechowywanie). Aplikacja pacjenta odczytuje go przez API FHIR jako Observation, po tym jak pacjent zalogował się za pomocą SMART on FHIR (tożsamość). Jeśli szpital udostępnia pełny raport innemu szpitalowi, może to zrobić jako dokument CDA za pośrednictwem rejestru IHE XDS. Jeśli wynik później dołączy do kohorty badawczej, zostanie przekonwertowany na OMOP.
Standardy nie są konkurentami. Każdy został stworzony do innego zadania, a zastąpienie jednego innym zazwyczaj oznacza przebudowę czegoś, co już działa.
Którego potrzebujesz?
Standard interoperacyjności w ochronie zdrowia, którego potrzebujesz, zależy od zadania: FHIR R4 z SMART on FHIR dla aplikacji pacjenta lub klinicysty, HL7 v2 do połączenia z istniejącymi systemami szpitalnymi, DICOM i DICOMweb dla obrazów, dokumenty CDA lub FHIR dla całych dokumentów, openEHR do długoterminowego przechowywania rekordów, OMOP do badań, a profile IHE, gdy dwa systemy muszą działać identycznie.
- Tworzysz aplikację dla pacjentów lub lekarzy: FHIR R4, z profilami swojego rynku (przewodniki implementacyjne), SMART on FHIR do logowania.
- Łączysz się z istniejącymi systemami szpitala: spodziewaj się najpierw HL7 v2; FHIR tam, gdzie oferuje go dostawca. Zobacz komunikaty HL7 v2 wyjaśnione.
- Przetwarzasz obrazy: DICOM do przechowywania i transferu, DICOMweb do wszystkiego w przeglądarce, FHIR ImagingStudy tylko do metadanych. Zobacz DICOMweb wyjaśnione i ImagingStudy vs DICOMweb.
- Wymieniasz całe dokumenty (podsumowania, listy): CDA tam, gdzie jest to wymagane, dokumenty FHIR (Bundle typu
document), gdzie możesz wybrać. Zobacz CDA i C-CDA wyjaśnione. - Projektujesz sposób przechowywania rekordu przez dziesięciolecia: openEHR, z FHIR jako warstwą wymiany. Zobacz openEHR vs FHIR.
- Prowadzisz badania na wielu rekordach: OMOP, z FHIR jako źródłem. Zobacz Wtórne wykorzystanie danych medycznych.
- Potrzebujesz, aby dwa systemy zachowywały się w ten sam sposób: wybierz profil IHE dla swojego przypadku użycia i przetestuj go.
Gdzie znajduje się Anpheros
Platforma Anpheros znajduje się w warstwie wymiany na mapie standardów jako serwer FHIR R4 z dostępem OAuth 2.0 i webhookami do powiadamiania o zmianach, odbierając wyniki laboratoryjne za pośrednictwem konektora z HL7 v2 ORU, CSV lub JSON. Nie przechowuje obrazów DICOM i nie oferuje usługi CDS Hooks; te pozostają w systemach szpitalnych.
Anpheros Platform to serwer FHIR R4 z zasobami potrzebnymi dla zorientowanego na pacjenta rekordu (Patient, Observation, Condition, MedicationStatement, DocumentReference, DiagnosticReport, Immunization, Consent, Provenance i inne), OAuth 2.0 do dostępu i webhookami do powiadamiania o zmianach. Wyniki laboratoryjne docierają przez łącznik laboratoryjny z HL7 v2 ORU, CSV lub JSON. Nie przechowuje obrazów DICOM i nie oferuje usługi CDS Hooks; te pozostają w systemach szpitala, a rekord do nich wskazuje.
Kolejność czytania
Dobra kolejność czytania standardów interoperacyjności w ochronie zdrowia zaczyna się od tego, czym jest FHIR i czym różni się od HL7 v2, następnie zasób FHIR Observation, następnie terminologie LOINC i SNOMED CT używane w jego ramach, następnie DICOMweb dla obrazów, CDA dla dokumentów, a na końcu porównanie openEHR z FHIR pod kątem sposobu przechowywania rekordów.
Jeśli jesteś nowy w tej dziedzinie: Czym jest FHIR → HL7 vs FHIR → FHIR Observation → LOINC i SNOMED CT → DICOMweb → CDA → openEHR vs FHIR.
Powiązane strony
- HL7 vs FHIR
- Komunikaty HL7 v2 wyjaśnione
- CDA i C-CDA wyjaśnione
- DICOMweb wyjaśnione
- openEHR vs FHIR
- Przewodniki implementacyjne FHIR
- FHIR R4 vs R5
- Co to jest kod LOINC?
- Co to jest SNOMED CT?
- DICOM vs FHIR dla programistów
- Profile i rozszerzenia FHIR wyjaśnione
- Serwery terminologii FHIR wyjaśnione
- Mapa regulacji danych medycznych
- Krajowe elektroniczne rekordy medyczne w Europie i USA
- Integracja systemów szpitalnych wyjaśniona
- AI na danych medycznych
- Wtórne wykorzystanie danych medycznych
- Bezpieczeństwo i tożsamość w aplikacjach medycznych
Źródła
- HL7 International: standardy
- Specyfikacja HL7 FHIR R4
- Standard DICOM, aktualne wydanie
- Frameworki techniczne IHE
- Specyfikacje openEHR
- OHDSI OMOP Common Data Model
- SMART App Launch
Najczęstsze pytania
Czy FHIR zastępuje wszystkie inne standardy?
Nie. FHIR zastępuje niestandardowe API i powoli niektóre wymiany dokumentów CDA. HL7 v2 pozostaje głównym narzędziem w szpitalach, DICOM pozostaje jedynym standardem dla obrazów, a openEHR i OMOP odpowiadają na pytania (przechowywanie, badania), na które FHIR nie został zaprojektowany.
Jaka jest różnica między standardem a profilem IHE?
Standard, taki jak FHIR lub DICOM, definiuje bloki konstrukcyjne. Profil IHE wybiera konkretne bloki, ustala ich opcje i dokładnie określa, w jaki sposób systemy muszą ich używać do jednego zadania, tak aby dwaj dostawcy, którzy przeszli testy IHE, mogli współpracować bez projektu.
Którego standardu używają krajowe systemy opieki zdrowotnej?
Większość europejskich systemów rozpoczęła od dokumentów CDA i HL7 v2, a obecnie dodaje API FHIR; format wymiany EHDS jest zbudowany na FHIR i IPS. USA nakazuje FHIR US Core do dostępu pacjenta i C-CDA do wymiany dokumentów.
Gdzie mieszczą się SNOMED CT i LOINC?
Nie są to standardy wymiany; są to słowniki używane we wszystkich z nich. Kod LOINC identyfikuje badanie w segmencie HL7 v2 OBX, wpisie CDA i podobnie w FHIR Observation.
Wypróbuj za darmo w sandboksie
Pierwsze wywołanie FHIR w 5 minut. API HL7 FHIR R4 z wbudowaną zgodą pacjenta: wypróbuj w piaskownicy, a następnie połącz własną aplikację lub system kliniczny.
Za darmo · 30 syntetycznych pacjentów · bez karty
Anpheros tworzy dokumentację medyczną, nad którą pacjent ma kontrolę i którą może udostępniać dowolnej klinice, na platformie HL7 FHIR R4, z siedzibą w UE. Te przewodniki pomogą Ci zrozumieć i uporządkować informacje o Twoim zdrowiu; nie zastępują one wizyty u lekarza.
O Anpheros →