Dane z karty zdrowia są przechowywane w formacie HL7 FHIR.
Dokumentacja medyczna obsługuje te wersje standardu Fast Healthcare Interoperability Resources (FHIR):
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ą określane jako typy zasobów medycznych. Zasoby obserwacji są mapowane na podstawie treści takich jak kody z Logical Observation Identifiers Names and Codes (LOINC) i kategorie FHIR.
Obserwacje, które nie pasują do żadnej z tych kategorii, nie są zapisywane w Health Connect.
| Typ zasobu medycznego Health Connect | Zasoby FHIR |
|---|---|
| Alergie | AllergyIntolerance |
| Schorzenia | Warunek |
| Laboratoryjny | Obserwacja
|
| Leki | Medication, MedicationRequest, MedicationStatement |
| Dane osobowe | Pacjent |
| Dane specjalisty | Practitioner, PractitionerRole |
| Ciąża | Obserwacja
|
| Zabiegi | Procedura |
| Historia danych związanych ze stylem życia | Obserwacja
|
| Szczepienia | Szczepienia |
| Wizyty | Spotkanie, Lokalizacja, Organizacja |
| Parametry życiowe | Obserwacja
|
Materiały dla pacjentów
Obecnie Health Connect służy do przechowywania danych z dokumentacji medycznej tylko jednej osoby. Dlatego wszystkie zasoby FHIR powinny należeć do tej samej osoby.
W systemie dotyczących jednego pacjenta często występuje wiele zasobów FHIR. Zalecamy, aby aplikacje uzgadniały dane i zapisywały w Health Connect pojedynczy zasób danych Pacjent. Nie jest to jednak wymóg, aby uwzględnić różne struktury organizacyjne, które mogą występować.
weryfikacja danych,
Interfejsy API dotyczące dokumentacji medycznej akceptują prawidłowe 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.
| 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:
|
||||||||
| 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:
|
||||||||
| 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.
|
||||||||
| 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 tym samym zasobie 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ć własne 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.
- Rozwiązywanie problemów z formatowaniem i innymi problemami 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 zakresie zastosowania 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
MedicalDataSourcew 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 kilku źródeł w jednym
MedicalDataSourcemoże utrudnić ustalenie ich pochodzenia. Często przydatne jest, aby użytkownicy danych wiedzieli, skąd pochodzą dane. Dlatego zalecamy wypełnienie polameta.sourcedla każdego zasobu oryginalnym źródłem rekordu (zazwyczaj adresem URL bazy FHIR).