Zasób FHIR Pacjent: identyfikatory, imiona, dane demograficzne i powiązania – z ważnym przykładem

Krótka odpowiedź: Patient to zasób FHIR opisujący osobę otrzymującą opiekę: kim jest administracyjnie, a nie co jej dolega. Zawiera identyfikatory (numery kart medycznych, krajowe ID), nazwy, dane kontaktowe telecom, administracyjną płeć, datę urodzenia, adres, stan cywilny, komunikację (języki), lekarza rodzinnego, organizację zarządzającą oraz powiązania do innych rekordów Pacjenta dla tej samej osoby. Każde Observation, Condition, Encounter lub MedicationStatement odnosi się do niego poprzez subject lub patient. Fakty kliniczne nigdy nie znajdują się w Patient; znajdują się w zasobach, które do niego wskazują.

Poprawny przykład FHIR R4

Poprawny zasób FHIR R4 typu Patient wymaga jedynie pola resourceType, ale w praktyce zawiera co najmniej jeden identyfikator z polem system i value, imię i nazwisko z częściami family i given, płeć administracyjną oraz datę urodzenia. Poniższy przykład deklaruje również profil IPS Patient w polu meta.profile i dodaje dane kontaktowe (telecom), adres (address), preferowany język (preferred language) oraz lekarza prowadzącego (general practitioner) i organizację zarządzającą (managing organisation).

{
  "resourceType": "Patient",
  "id": "example",
  "meta": {"profile": ["http://hl7.org/fhir/uv/ips/StructureDefinition/Patient-uv-ips"]},
  "identifier": [{
    "use": "usual",
    "type": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v2-0203", "code": "MR"}]},
    "system": "https://hospital.example.org/mrn",
    "value": "MRN-00012345"
  }],
  "active": true,
  "name": [{"use": "official", "family": "Doe", "given": ["Jane", "Marie"], "prefix": ["Ms"]}],
  "telecom": [{"system": "email", "value": "[email protected]", "use": "home"}],
  "gender": "female",
  "birthDate": "1980-05-23",
  "address": [{"use": "home", "line": ["12 High Street"], "city": "Leeds", "postalCode": "LS1 4AB", "country": "GB"}],
  "communication": [{"language": {"coding": [{"system": "urn:ietf:bcp:47", "code": "en-GB"}]}, "preferred": true}],
  "generalPractitioner": [{"reference": "Practitioner/gp-42"}],
  "managingOrganization": {"reference": "Organization/hospital"}
}

Istotne elementy

Najważniejsze elementy zasobu Patient dla interoperacyjności to: identyfikator (identifier - z polem system, value i type), imię i nazwisko (name - z polem use, family i given), płeć administracyjna (administrative gender), data urodzenia (birthDate), informacja o zgonie (deceased), status aktywności (active), dane kontaktowe (contact) i powiązanie (link). Identyfikatory i imiona/nazwiska służą do dopasowywania rekordów między systemami, płeć i data urodzenia to fakty administracyjne, a link opisuje, jak główny indeks pacjentów połączył zduplikowane rekordy tej samej osoby.

• identifier to lista, z których każda zawiera system (kto ją wydał) i value. type określa rodzaj: MR numer karty medycznej, NI identyfikator krajowy, PPN paszport, SS numer ubezpieczenia społecznego, z tabeli HL7 0203. Pacjent zazwyczaj ma kilka; numer MRN szpitala i krajowy ID są poprawne, a systemy dopasowują je.
• name to również lista z use: official, usual, nickname, maiden, old. family to jeden ciąg znaków; given to lista. Skrypty, transliteracje i kolejność nazw pozostawia się przewodnikowi implementacji kraju.
• gender to administracyjna płeć z czterema wartościami: male, female, other, unknown. Jest to to, co mówi rekord, używane do dopasowywania i formularzy. Płeć kliniczna, tożsamość płciowa i zaimki znajdują się w rozszerzeniach lub Observation, które FHIR R5 i projekt Gender Harmony sformalizowały.
• birthDate to data, opcjonalnie tylko rok lub rok-miesiąc, gdy dokładna data jest nieznana. Rozszerzenie patient-birthTime dodaje godzinę urodzenia dla noworodków.
• deceased[x] to wartość logiczna lub data-czas. active false oznacza rekord, który nie powinien być już używany (duplikat, przeniesiony), bez jego usuwania.
• contact zawiera listę osób do kontaktu (najbliższa rodzina, opiekun), z kodem relacji; same w sobie nie są zasobami Patient. Rodzic, który jest również pacjentem, jest RelatedPerson wskazującym na obu.
• link łączy rekordy Pacjenta, które dotyczą tej samej osoby: replaced-by i replaces po scaleniu, refer do autorytatywnego rekordu, seealso dla rekordu w innym systemie. W ten sposób główny indeks pacjentów wyraża swoje decyzje w FHIR; zobacz Dopasowywanie pacjentów.

Co dodają profile krajowe

Krajowe i międzynarodowe profile FHIR przekształcają luźno zdefiniowany podstawowy zasób Patient w coś użytecznego, czyniąc pewne elementy obowiązkowymi i dodając rozszerzenia specyficzne dla danego kraju. US Core wymaga identyfikatora, imienia/nazwiska i płci, a także dodaje rozszerzenia dotyczące rasy, pochodzenia etnicznego i płci przy urodzeniu (race, ethnicity, birth sex); profil IPS Patient wymaga imienia/nazwiska, płci i daty urodzenia (name, gender, birthDate); profile krajowe definiują systemy identyfikatorów i formaty adresów.

Podstawowy zasób sprawia, że prawie wszystko jest opcjonalne. Profile sprawiają, że jest użyteczny:

Rekord, który ma przekroczyć granicę, musi spełniać profil po obu stronach, co w praktyce oznacza posiadanie zarówno krajowego identyfikatora, jak i MRN, pełnej oficjalnej nazwy i kompletnej daty urodzenia. Zobacz Przewodniki implementacji FHIR.

Operacje, których będziesz używać

Operacje FHIR najczęściej używane z zasobem Patient to: wyszukiwanie po identyfikatorze lub danych demograficznych (GET /Patient z parametrami identifier, family lub birthdate), operacja $everything, która zwraca pacjenta i wszystkie zasoby, które się do niego odnoszą, oraz $match, która pyta algorytm dopasowujący serwera o prawdopodobne duplikaty. Operacja $merge jest obecnie standaryzowana w FHIR R5.

• GET /Patient?identifier=https://hospital.example.org/mrn|MRN-00012345 wyszukuje pacjenta po identyfikatorze; ?family=doe&birthdate=1980-05-23 po danych demograficznych.
• GET /Patient/{id}/$everything zwraca pacjenta i każdy zasób, który się do niego odnosi, stronicowany, co jest sposobem eksportu całego rekordu.
• $match (tam, gdzie jest obsługiwane) prosi algorytm dopasowujący serwera o prawdopodobne duplikaty; $merge jest standaryzowane w R5.

Błędy, które psują rekordy pacjentów

Błędy, które najczęściej psują rekordy FHIR Patient, to: przechowywanie krajowego identyfikatora w polu resource id zamiast w identifier, pomijanie pola identifier.system, co prowadzi do kolizji wartości z różnych szpitali, wpisywanie całego imienia i nazwiska w jednym polu tekstowym bez podziału na family i given, używanie płci administracyjnej zamiast płci klinicznej, oraz edytowanie połączonego rekordu w miejscu zamiast jego dezaktywacji i powiązania.

• Umieszczanie krajowego ID w id. Zasób id należy do serwera i może się zmienić podczas importu; identyfikatory należą do identifier.
• Jedno name z wszystkim w text i bez family/given, co powoduje niepowodzenie wyszukiwania po nazwisku.
• gender używane dla płci klinicznej lub ustawione na unknown, ponieważ formularz nie miał pola.
• Brak identifier.system, co powoduje kolizję wartości MRN-1 z dwóch szpitali.
• Edycja Pacjenta w miejscu, gdy nastąpiło scalenie, zamiast linkowania i dezaktywacji.

W Anpheros

W Anpheros każdy użytkownik, posiadacz konta i każdy profil rodzinny jest reprezentowany jako zasób FHIR Patient na platformie Anpheros. Każdy rekord dodany przez klinikę za pośrednictwem API odnosi się do tego zasobu Patient. Identyfikatory kliniki są przechowywane jako dodatkowe identyfikatory z własnym systemem kliniki, a dane demograficzne wprowadzone przez użytkownika pozostają danymi administracyjnymi, z których nie wyciąga się żadnych wniosków klinicznych.

Gdy klinika przesyła swój własny identyfikator, jest on przechowywany jako dodatkowy identifier z systemem kliniki, dzięki czemu tę samą osobę można odnaleźć z obu stron. Dane demograficzne wprowadzone przez użytkownika w aplikacji to usual imię i nazwisko oraz dane administracyjne; rekord nigdy nie wyciąga z nich żadnych wniosków klinicznych.

Powiązane strony

• Dopasowywanie pacjentów i główny indeks pacjentów
• Przewodniki implementacji FHIR
• Wyjaśnienie FHIR Encounter
• Wyjaśnienie FHIR Condition
• Wyjaśnienie wyszukiwania FHIR
• Przykład Pacjenta na stronie dla deweloperów

Źródła

• HL7 FHIR R4: Patient
• HL7 FHIR R4: Patient $everything
• HL7 Terminology: identifier type codes (v2-0203)
• HL7 US Core: Patient profile
• HL7 IPS: Patient profile

Najczęstsze pytania

Czy Patient to to samo co Person w FHIR?

Nie. Person to zasób administracyjny, który łączy tę samą osobę w różnych rolach (tutaj Pacjent, tam Praktykujący, gdzie indziej Osoba Powiązana). Zasoby kliniczne odnoszą się do Patient, nigdy do Person.

Gdzie trafiają alergie i schorzenia?

Do zasobów AllergyIntolerance i Condition, które odnoszą się do Pacjenta. Sam Patient zawiera tylko dane administracyjne.

Jak zarejestrować noworodka bez imienia?

Z imieniem, którego użycie to temporary lub jest puste, birthDate z rozszerzeniem patient-birthTime, oraz link do rekordu matki poprzez RelatedPerson lub rozszerzenie patient-mothersMaidenName, zgodnie ze specyfikacją profili krajowych.

Czy jeden zasób Patient może być współdzielony przez dwa szpitale?

Każdy system przechowuje swój własny zasób Patient z własnym id; współdzielą identyfikatory (krajowy ID) i mogą linkować rekordy. Dopasowywanie między systemami jest zadaniem głównego indeksu pacjentów, a nie zasobu.

Anpheros Platform

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.

Utwórz darmowy sandboxPrzeczytaj przewodniki dla programistów →

Za darmo · 30 syntetycznych pacjentów · bez karty

Napisane przez

Zespół Anpheros

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 →