Dane dotyczące dokumentacji medycznej są przechowywane w formacie HL7 FHIR.
Dokumentacja medyczna obsługuje te wersje Fast Health Interoperable Resources (FHIR):
Typy zasobów medycznych
FHIR składa się z zestawu modułowych komponentów zwanych zasobami. Obsługiwany zestaw zasobów FHIR i odpowiadających im kategorii jest oparty w przybliżeniu na sekcjach międzynarodowego podsumowania informacji o pacjencie.
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 (Logical Observation Identifiers Names and Codes) i kategorie FHIR.
Obserwacje, które nie należą do żadnej z tych kategorii, nie są zapisywane w Health Connect.
| Typ zasobu medycznego Health Connect | Zasoby FHIR | Deklaracja uprawnień Health Connect |
|---|---|---|
| Alergie | Alergia lub nietolerancja |
android.permission.health.READ_MEDICAL_DATA_ALLERGIES_INTOLERANCES
|
| Schorzenia | Warunek |
android.permission.health.READ_MEDICAL_DATA_CONDITIONS
|
| Laboratorium |
Obserwacja
|
android.permission.health.READ_MEDICAL_DATA_LABORATORY_RESULTS
|
| Leki | Leki, MedicationRequest, MedicationStatement |
android.permission.health.READ_MEDICAL_DATA_MEDICATIONS
|
| Dane osobowe | Pacjent |
android.permission.health.READ_MEDICAL_DATA_PERSONAL_DETAILS
|
| Dane specjalisty | Lekarz, PractitionerRole |
android.permission.health.READ_MEDICAL_DATA_PRACTITIONER_DETAILS
|
| Ciąża |
Obserwacja
|
android.permission.health.READ_MEDICAL_DATA_PREGNANCY
|
| Zabiegi | Procedura |
android.permission.health.READ_MEDICAL_DATA_PROCEDURES
|
| Historia danych związanych ze stylem życia |
Obserwacja
|
android.permission.health.READ_MEDICAL_DATA_SOCIAL_HISTORY
|
| Szczepienia | Szczepienia |
android.permission.health.READ_MEDICAL_DATA_VACCINES
|
| Wizyty | Spotkanie, Lokalizacja, Organizacja |
android.permission.health.READ_MEDICAL_DATA_VISITS
|
| Parametry życiowe |
Obserwacja
|
android.permission.health.READ_MEDICAL_DATA_VITAL_SIGNS
|
Materiały dla pacjentów
Health Connect jest obecnie przeznaczona do przechowywania danych dokumentacji medycznej tylko jednej osoby. Dlatego wszystkie zapisane zasoby FHIR powinny należeć do tej samej osoby.
W systemie może istnieć wiele zasobów FHIR Patient dotyczących jednej osoby. Zalecamy, aby aplikacje uzgadniały dane i zapisywały w Health Connect pojedynczy zasób Pacjent. Nie jest to jednak wymóg, aby uwzględnić różne struktury organizacyjne, które mogą istnieć.
weryfikacja danych,
Interfejsy API rekordów medycznych akceptują prawidłowe zasoby FHIR z obsługiwanych wersji, a Health Connect przeprowadza weryfikację, aby potwierdzić, że specyfikacja FHIR dla każdej obsługiwanej wersji jest przestrzegana.
Sprawdzanie poprawności oznaczone jako Wkrótce nie jest jeszcze wymuszane, ale będzie w przyszłej wersji. Aby zachować zgodność z przyszłymi wersjami, zalecamy opracowywanie aplikacji pod kątem wszystkich wymienionych kontroli weryfikacji.
| Poziom | Sprawdzenie poprawności | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Prawidłowy plik JSON | Dane są zgodne z formatem JSON. | ||||||||
| Obsługiwane FHIR | Obsługiwana jest wersja FHIR zadeklarowana przez aplikację do pisania. Zarządzanie danymi o zdrowiu obsługuje te wersje FHIR:
|
||||||||
| Obsługiwane FHIR | Typ zasobu FHIR zarejestrowany w instancji zasobu jest obsługiwany. Zarządzanie danymi o zdrowiu obsługuje te typy zasobów FHIR:
|
||||||||
| Unikalny identyfikator zasobu | Zasób ma pole identyfikatora o wartości, która spełnia wymagania wyrażenia regularnego. | ||||||||
| Unikalny identyfikator zasobu | Zasób nie ma tego samego identyfikatora co inny zasób FHIR tego samego typu pochodzący z tego samego MedicalDataSource. |
||||||||
| Reguły biznesowe | Nie zawiera zasobu FHIR. Zasoby zawarte 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ących informacji, aby utworzyć go jako samodzielny zasób o niezależnym istnieniu. | ||||||||
| Prawidłowy podstawowy format FHIR | Pola najwyższego poziomu w pliku JSON FHIR istnieją w specyfikacji FHIR dla danego typu zasobu. | ||||||||
| Prawidłowy podstawowy format FHIR | Pola najwyższego poziomu nie mają wartości null w formacie JSON. | ||||||||
| Prawidłowy podstawowy format FHIR | Wszystkie wymagane pola najwyższego poziomu są obecne. | ||||||||
| Prawidłowy podstawowy format FHIR | Pola najwyższego poziomu zdefiniowane jako powtarzające się elementy w FHIR mają typ danych JSON array. |
||||||||
| Prawidłowy podstawowy format FHIR | Pola najwyższego poziomu (w tym elementy w arrays JSON) zdefiniowane jako typy złożone w FHIR mają typ danych object JSON. |
||||||||
| Prawidłowy podstawowy format FHIR | Pola najwyższego poziomu (w tym elementy w obiektach JSON array) zdefiniowane jako typy pierwotne w FHIR mają prawidłowy typ danych JSON.
|
||||||||
| Prawidłowy podstawowy format FHIR | Pola najwyższego poziomu zdefiniowane jako typy proste w FHIR spełniają wymagania dotyczące wyrażeń regularnych. Już wkrótce | ||||||||
| Prawidłowy podstawowy format FHIR | Rozszerzenia typów pierwotnych
występują w specyfikacji FHIR i mają typ danych JSON object. |
||||||||
| Prawidłowy podstawowy format FHIR | W przypadku pól wyboru (fieldname[x]) rejestrowane jest maksymalnie 1 pole. Na przykład effectiveDateTime i effectivePeriod nie mogą występować w tej samej instancji zasobu. |
||||||||
| Prawidłowy podstawowy format FHIR | Złożone typy danych zawierają pola i typy danych zgodne ze specyfikacją FHIR. Już wkrótce | ||||||||
| Prawidłowy podstawowy format FHIR | Elementy podstawowe (i elementy w obrębie typów złożonych) zawierają pola i typy danych zgodne ze specyfikacją FHIR. Już wkrótce | ||||||||
| Prawidłowy podstawowy format FHIR | Element rozszerzeń
value[x] pola są prawidłowego typu i zawierają treści
zgodne z tym typem danych.
Elementy rozszerzające można uwzględnić w dowolnym zasobie, aby przedstawić dodatkowe informacje, które nie są częścią specyfikacji podstawowej. Zawierają one pole url, które prowadzi do definicji rozszerzenia, oraz pole value[x], które zawiera wartość rozszerzenia.
value[x] musi pochodzić z ustalonej listy akceptowanych typów danych.
Już wkrótce |
Przekształcone dane FHIR
Niektóre aplikacje przekształcają dane FHIR, aby spełniały ich własne wymagania. Na przykład:
- Scalanie danych z różnych źródeł (zwykle interfejsów API FHIR).
- Mapowanie kodów na globalne terminologie (np. SNOMED, LOINC, ICD) i standaryzacja jednostek.
- konsolidowanie i usuwanie duplikatów danych;
- rozwiązywanie problemów z formatowaniem lub innych problemów z jakością danych;
- filtrowanie rekordów na podstawie reguł biznesowych dotyczących aplikacji;
Do Health Connect można zapisywać dane FHIR w formie nieprzekształconej i przekształconej, o ile są 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 zastosowań mogą odfiltrowywać znaczną liczbę rekordów, które inne aplikacje w ekosystemie mogłyby wykorzystać do zwiększenia wartości dla użytkowników. W takich sytuacjach warto napisać nieprzekształcony kod FHIR, który jest bardziej kompletny. Pamiętaj jednak, aby poinformować użytkowników, że udostępniany jest szerszy zbiór danych.
- Jeśli łączysz dane pochodzące z różnych źródeł, możesz zapisywać dane w jednym
MedicalDataSourcew Health Connect. Musisz też przypisać każdemu zasobowi nowy identyfikator, aby uniknąć konfliktów, i zaktualizować odwołania do zasobów, aby wskazywały nowe identyfikatory. - Scalanie danych z wielu źródeł w jednym
MedicalDataSourcemoże zaciemnić pochodzenie danych. Ponieważ odbiorcy danych często potrzebują informacji o ich pochodzeniu, zalecamy wypełnianie polameta.sourcedla każdego zasobu oryginalnym źródłem rekordu (zwykle podstawowym adresem URL FHIR).