Format danych PHR

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Dane z osobistym rekordem zdrowotnym są przechowywane w formacie HL7 FHIR.

PHR obsługuje te wersje standardu Fast Healthcare Interoperable Resources (FHIR):

• R4 (v4.0.1)
• R4B (wersja 4.3.0)

Typy zasobów medycznych

FHIR składa się z zestawu modułowych komponentów zwanych zasobami. Obsługiwany zbiór zasobów FHIR i odpowiadających im kategorii jest w przybliżeniu oparty na sekcjach Międzynarodowego podsumowania dla pacjenta.

Te zasoby są mapowane na kategorie danych w Health Connect, które w interfejsie API są nazywane typami zasobów medycznych. Zasoby obserwacji są mapowane na podstawie treści takich jak kody LOINC i kategorie FHIR.

Obserwacje, które nie pasują do żadnej z tych kategorii, nie są zapisywane w Health Connect.

Tabela 1. Typy zasobów medycznych w Health Connect

Typ zasobu medycznego Health Connect	Zasoby FHIR
Alergie	AllergyIntolerance
Schorzenia	Warunek
Laboratoryjny	Obserwacja laboratory Kategoria FHIR
Leki	Medication, MedicationRequest, MedicationStatement
Dane osobowe	Pacjent
Dane specjalisty	Practitioner, PractitionerRole
Ciąża	Obserwacja Kody LOINC dotyczące ciąży
Zabiegi	Procedura
Historia danych związanych ze stylem życia	Obserwacja Kody LOINC dotyczące historii danych związanych ze stylem życia social-history Kategoria FHIR
Szczepienia	Szczepienia
Wizyty	Spotkanie, Lokalizacja, Organizacja
Parametry życiowe	Obserwacja Kody LOINC dotyczące parametrów życiowych vital-signs Kategoria FHIR

Materiały dla pacjentów

Obecnie Health Connect służy do przechowywania danych o zdrowiu i formie fizycznej tylko jednej osoby. Dlatego wszystkie zasoby FHIR powinny należeć do tej samej osoby.

W systemie dotyczących pojedynczej osoby często występuje wiele zasobów FHIR dotyczących pacjenta. Zalecamy, aby aplikacje uzgadniały dane i zapisywały w Health Connect pojedynczy zasób danych Pacjent. Nie jest to jednak wymagane, aby uwzględnić różne struktury organizacyjne, które mogą występować.

weryfikacja danych,

Interfejsy PHR API akceptują poprawne zasoby FHIR z obsługiwanych wersji, a Health Connect przeprowadza weryfikację, aby potwierdzić, że przestrzegana jest specyfikacja FHIR dla każdej obsługiwanej wersji.

Weryfikacje oznaczone jako Wkrótce nie są jeszcze wymagane, ale zostaną uwzględnione w jednej z przyszłych wersji. Zalecamy tworzenie aplikacji z uwzględnieniem wszystkich wymienionych weryfikacji, aby zachować zgodność z przyszłymi wersjami.

Tabela 2. Weryfikacja danych FHIR przez Health Connect

Poziom	Sprawdzanie poprawności
Prawidłowy kod JSON	Dane są zgodne z formatem JSON.
Obsługiwane formaty FHIR	Obsługiwana jest wersja FHIR zadeklarowana przez aplikację do zapisywania. Health Connect obsługuje te wersje FHIR: 4.0.1 4.3.0
Obsługiwane formaty FHIR	Typ zasobu FHIR zapisany w przypadku zasobu jest obsługiwany. Zarządzanie danymi o zdrowiu obsługuje te typy zasobów FHIR: AllergyIntolerance Warunek Spotkanie Szczepienia Lokalizacja Leki MedicationRequest MedicationStatement Obserwacja Należąca do organizacji Pacjent Lekarz PractitionerRole Procedura
Unikalny identyfikator zasobu	Zasób ma pole identyfikatora z wartością, która spełnia wymagania dotyczące wyrażeń regularnych.
Unikalny identyfikator zasobu	Zasób nie ma identyfikatora wspólnego z żadnym innym zasobem FHIR tego samego typu z tego samego MedicalDataSource.
Zasady biznesowe	Nie zawiera zawartego zasobu FHIR. Zawarte zasoby to zasoby FHIR zagnieżdżone w „zasobie nadrzędnym”. Są one używane, gdy zasób nadrzędny musi odwoływać się do innego zasobu, ale system nie ma wystarczającej ilości informacji, aby utworzyć go jako samodzielny zasób o niezależnym istnieniu.
Prawidłowy podstawowy FHIR	Pola najwyższego poziomu w pliku JSON FHIR znajdują się w specyfikacji FHIR dla danego typu zasobu.
Prawidłowy podstawowy FHIR	Pola najwyższego poziomu nie mają wartości null w formacie JSON.
Prawidłowy podstawowy FHIR	Wszystkie wymagane pola najwyższego poziomu są obecne.
Prawidłowy podstawowy FHIR	Pola najwyższego poziomu zdefiniowane jako powtarzające się elementy w FHIR mają typ danych JSON array.
Prawidłowy podstawowy FHIR	Pola najwyższego poziomu (w tym elementy w obiektach JSON array) zdefiniowane jako typy złożone w FHIR mają typ danych JSON object.
Prawidłowy podstawowy FHIR	Pola najwyższego poziomu (w tym elementy w elementach JSON array), zdefiniowane jako typy proste w FHIR, mają prawidłowy typ danych JSON. Typ danych FHIR Typ danych JSON integer, unsignedInt, positiveInt, decimal liczba wartość logiczna wartość logiczna instant, time, date, dateTime, string, code, markdown, id uri, url, oid, uuid, canonical, integer64, base64Binary liczba Wkrótce
Prawidłowy podstawowy FHIR	Pola najwyższego poziomu zdefiniowane jako typy proste w FHIR spełniają wymagania dotyczące wyrażeń regularnych. Wkrótce
Prawidłowy podstawowy FHIR	Rozszerzenia typów prymitywnych występują w specyfikacji FHIR i mają typ danych JSON object.
Prawidłowy podstawowy FHIR	W przypadku polów wyboru (fieldname[x]) nie jest rejestrowane więcej niż 1 pole. Na przykład w tej samej instancji zasobu nie mogą występować pola effectiveDateTime i effectivePeriod.
Prawidłowy podstawowy FHIR	Złożone typy danych zawierają pola i typy danych zgodne ze specyfikacją FHIR. Wkrótce
Prawidłowy podstawowy FHIR	Elementy szkieletu (oraz elementy w złożonych typach) zawierają pola i typy danych zgodne ze specyfikacją FHIR. Wkrótce
Prawidłowy podstawowy FHIR	Element Extensions value[x] pola mają prawidłowy typ i zawierają zawartość zgodną z tym typem danych. Elementy rozszerzeń mogą być zawarte w dowolnym zasobie, aby reprezentować dodatkowe informacje, które nie są częścią specyfikacji podstawowej. Zawierają pole url, które łączy się z definicją rozszerzenia, oraz pole value[x], które zawiera wartość rozszerzenia. value[x] musi pochodzić z listy dozwolonych typów danych. Wkrótce

Przekształcone dane FHIR

Niektóre aplikacje przekształcają dane FHIR, aby spełniały ich wymagania. Przykład:

• scalanie danych z różnych źródeł (zazwyczaj interfejsów FHIR API);
• mapowanie kodów na terminologie globalne (np. SNOMED, LOINC, ICD) oraz standaryzacja jednostek.
• konsolidowanie i usuwanie duplikatów danych.
• naprawić formatowanie lub inne problemy z jakością danych.
• Filtrowanie rekordów na podstawie reguł biznesowych określonych w aplikacji.

Do Health Connect można zapisać nieprzekształcone i przekształcone dane FHIR, o ile są one zgodne ze specyfikacją FHIR R4. W miarę możliwości zalecamy zapisywanie przekształconych danych. Pamiętaj jednak o tych kwestiach:

• Aplikacje o wąskim zastosowaniu mogą odfiltrowywać znaczną liczbę rekordów, które mogłyby być wykorzystane przez inne aplikacje w ekosystemie do tworzenia wartości dla użytkowników. W takich przypadkach warto napisać nieprzekształcony FHIR, który jest bardziej kompletny. Pamiętaj jednak, aby poinformować użytkowników, że udostępniasz im szerszy zbiór danych.
• Jeśli zgrywasz dane pochodzące z różnych źródeł, możesz zapisać je w jednym MedicalDataSource w Health Connect. Musisz też przypisać nowy identyfikator do każdego zasobu, aby uniknąć konfliktów, oraz zaktualizować odwołania do zasobów, aby wskazywały one na nowe identyfikatory.
• Scalanie danych z wielu źródeł w jednym MedicalDataSource może utrudnić ustalenie ich pochodzenia. Często przydatne jest, aby użytkownicy danych wiedzieli, skąd pochodzą dane. Dlatego zalecamy wypełnienie pola meta.source dla każdego zasobu oryginalnym źródłem rekordu (zazwyczaj adresem URL bazy FHIR).