FHIR-standarden (Fast Healthcare Interoperability Resources) har fått stor betydelse för interoperabilitet mellan vårddata.
FHIR ger ett flexibelt och robust format för utbyte av hälsoinformation, men att integrera icke-standardiserade datakällor i detta strukturerade format kan vara en formidabel uppgift.
Den här artikeln ger ett inifrånperspektiv på ett projekt där vi utvecklade en lösning för att överbrygga klyftan mellan vår kunds olika datakällor – inklusive CSV-filer och databaser – och den strikta FHIR-standarden.
Vårt slutmål var att förbereda kundens data för sömlös integrering i AWS HealthLake, vilket öppnade upp en värld av möjligheter för forskning och andra tillämpningar inom hälso- och sjukvården.
FHIR-RESURSHIERARKIN
En av de grundläggande utmaningarna med att konvertera data till FHIR är den väsentliga skillnaden i struktur mellan FHIR-resurser och traditionella datakällor, t.ex. CSV-filer och relationsdatabaser. Medan konventionella datakällor vanligtvis är organiserade i tabeller med rader och kolumner och relationer mellan dem, representeras FHIR-resurser av en trädliknande struktur. Denna trädstruktur kan vara flera nivåer djup, med vissa resurser som refererar till andra resurser, och i vissa fall kan cirkulära beroenden uppstå.
Att navigera i detta invecklade träd av resurser och datatyper kan vara en utmaning, särskilt när man hanterar omfattande dataset.
En struktur för dataimport är nödvändig för att hantera komplexiteten i FHIR:s resurshierarki och minska de utmaningar som är förknippade med cirkulära beroenden. Denna strategi bör göra det möjligt att importera data utan att i onödan gräva djupt i det komplexa FHIR-trädet. Den här strukturerade importstrategin förenklar dataanalysen och säkerställer att processen förblir hanterbar.
DYNAMISK MAPPNINGSALGORITM
Vårt team introducerade en användarvänlig mappningsalgoritm för att hantera dessa utmaningar. Det primära målet var att tillhandahålla en dynamisk och återanvändbar lösning och samtidigt undvika begränsningarna med hårdkodning. Denna algoritm innehåller ett användargränssnitt för mappning av källdata till FHIR-resurser, med FHIR-resursträdet som referens.
HANTERING AV PRIMITIVA TYPER OCH DATATYPER
Det är relativt enkelt att arbeta med primitiva typer i FHIR, men datatyper innebär ett nytt lager av komplexitet. Datatyper, t.ex. adresser, är objekt och kan innehålla andra datatyper. Dessutom kan vissa datatyper representeras som matriser, vilket ytterligare komplicerar mappningsprocessen. Datatypen ”HumanName” innehåller till exempel en mängd olika ”Given”-värden men bara ett ”Family”-attribut.
Att utforma ett användargränssnitt som hanterar denna komplexitet kräver noggrant övervägande, eftersom varje underordnad nod i FHIR-trädet kan vara antingen en datatyp eller en matris, vilket leder till en mer komplicerad struktur.
Med en kodbas med alla FHIR-resurser i ett praktiskt format i ett av de populära programmeringsspråken kunde vi skriva ett skript som rekursivt itererade över detta träd, analyserade varje attribut, dess typ (primitiv typ, datatyp) och dess numeriska värde, och genererade JSON-konfigurationer för det framtida FHIR-trädet. Särskild uppmärksamhet ägnas åt att hantera cirkulära beroenden, vilket säkerställer att den rekursiva algoritmen inte går in i oändliga loopar.
HANTERING AV CIRKULÄRA BEROENDEN
En kritisk utmaning vid mappning till FHIR-resurser är hanteringen av cirkulära beroenden. Till exempel kan typen ”Extension” i FHIR länkas till nästan vilken resurs som helst och kan också ha andra tillägg inom sig, vilket potentiellt kan leda till cirkulära referenser. För att hantera detta problem inkluderar mappningsalgoritmen ytterligare villkor under analysen. Den identifierar scenarier där barn- och föräldranoder delar samma resurstyp och utesluter dem från analysen. Även om detta antagande kanske inte är korrekt i alla fall, är det effektivt i många verkliga scenarier.
DYNAMISKT TRÄDDJUP
En storlek passar inte alla när man mappar till FHIR-resurser. Hur djupt FHIR-resursträdet måste vara för mappning beror på den specifika datakällan och kundens krav. Att analysera kundens datakälla och anpassa den till FHIR-strukturen är avgörande för att fastställa det nödvändiga träddjupet. I vissa fall kan ett fast djup vara tillräckligt, medan det i andra fall kan krävas ett mer dynamiskt tillvägagångssätt för att hantera olika nivåer av komplexitet.
Om du vill veta mer om FHIR-standarden kan du läsa vår tidigare artikel, som innehåller den ultimata guiden för att förstå den.
ANVÄNDARVÄNLIGT UI
För att hantera utmaningarna med att mappa data till FHIR-standarden har vi utvecklat ett användarvänligt gränssnitt som gör det möjligt för kunderna att välja kapslade typer och motsvarande kolumner från sin datakälla. Det är viktigt att notera att vissa FHIR-element har numeriska värden, vilket kräver elementmappning och specifikation av elementindex. Numerical kan tillämpas på olika datatyper inom FHIR, och om man identifierar vilka typer som är numeriskt större än ett innebär det att de representerar matriser. Detta användarvänliga gränssnitt effektiviserar mappningsprocessen för klienten, vilket gör den ännu mer tillgänglig för användare med begränsad teknisk expertis.
DYNAMISK MAPPNING AV VÄRDEN OCH STANDARDISERADE KODER
När FHIR-attributmappningen är klar är nästa utmaning värdemappning. FHIR tillämpar strikt datatypning, vilket innebär att data måste följa specifika koder och fält. I många fall matchar dock inte kunddata de fördefinierade värdena i FHIR-standarden. För att åtgärda detta har vi implementerat en dynamisk mappningsmekanism.
Den här mekanismen analyserar alla kolumner som kunden har angett i sin datakälla. Den identifierar unika värden i dessa kolumner och försöker mappa dem till de värden som anges i FHIR-standarden. I de fall där inga direkta matchningar hittas identifierar systemet uppsättningar av unika värden och presenterar dem för kunden för mappning. Variationer som ”M”, ”m”, ”man” och ”Man” kan till exempel alla mappas till FHIR-standardvärdet ”Male”. Denna dynamiska mappning och grundliga dataanalys gör att kunden kan mappa alla värden på ett effektivt sätt.
Standardiserad kod innebär en större utmaning. FHIR föreskriver strikta koder, särskilt i sammanhang som immuniseringar och allergier. Snomed och Loinc är två standardiserade kodsystem som används i stor utsträckning av användare av FHIR-standarden. Standardiserade koder är avgörande för att säkerställa att data som utbyts mellan FHIR-användare förstås på ett konsekvent sätt.
Vi har lagt till moduler i vårt system som gör det möjligt att enkelt söka efter koder för att lösa detta problem. Eftersom antalet koder kan vara mycket stort är denna funktion ovärderlig. Denna funktion gör det möjligt för kunden att kartlägga sjukdomskoder, vilket säkerställer standardisering och korrekta sjukdomsrelaterade data i FHIR-dokument, vilket är avgörande för efterföljande analys.
OPTIMAL DATALAGRING
Under utvecklingen av vår lösning uppstod frågan om datalagring för mellanliggande resultat. En relationsdatabas kan tyckas vara ett självklart val, men en närmare titt på FHIR-typerna avslöjade ett överväldigande antal typer och beroenden. Det skulle vara nästan omöjligt att hantera en sådan databas. Å andra sidan kunde en dokumentbaserad NoSQL-databas övervägas, men det blev tydligt att lagring av mellanliggande data var valfritt.
De viktigaste frågorna som vägledde vårt beslut var följande:
- Varför behöver vi lagra de här uppgifterna?
- Skulle det finnas behov av att söka i den?
- Kommer dessa data att visas?
Som ett resultat av detta beslutade vi att inte lagra mellanliggande data. Istället fokuserade vi på att lagra metadata, en matris för mappning av datakällans attribut till FHIR och kundens mappningsinställningar. Detta tillvägagångssätt gjorde det möjligt för oss att köra ett skript vid körning för att generera ett FHIR-dokument. Genom att eliminera behovet av att lagra mellanliggande data fick vi flexibilitet i vår kodorganisation. Som ett resultat byggdes alla objekt vid körning, vilket eliminerade behovet av databasoperationer eller fillagring, vilket avsevärt ökade bearbetningshastigheten.
SLUTSATS
Mappning av datakällor till FHIR-standarden innebär mångfacetterade utmaningar, från att navigera i komplexa resurshierarkier till dynamisk mappning av värden och hantering av standardiserad kod. Innovativa lösningar, som våra användarvänliga mappningsalgoritmer och dynamiska mappningsmekanismer, spelar en avgörande roll när det gäller att övervinna dessa hinder. Dessutom kan optimering av datalagringsstrategier genom att eliminera behovet av mellanliggande datalagring öka bearbetningshastigheten och kodflexibiliteten.
I takt med att kraven på interoperabilitet mellan vårddata ökar kommer det att bli allt viktigare att effektivt mappa olika datakällor enligt FHIR-standarden. Genom att förstå och övervinna svårigheterna i den här processen kan organisationer utnyttja FHIR:s fulla potential för förbättrat utbyte och analys av vårddata, vilket i slutändan förbättrar kvaliteten på vård och forskning inom vårdbranschen. Sådan dataanalys kommer att spela en viktig roll inom den närmaste framtiden och är en lovande inriktning eftersom standardiserade data i FHIR-format kan undersökas av olika maskininlärningsverktyg, vilket underlättar skapandet av förutsägelser och ömsesidiga beroenden mellan olika faktorer och sjukdomar. Detta har potential att identifiera tidigare okända hälsoproblem och hantera dem genom proaktiva åtgärder eller effektiva förebyggande strategier.
–
Sigma Software Group har lång erfarenhet inom hälso- och sjukvårdsbranschen och hjälper till att driva FHIR-standarden framåt och strävar efter att göra FHIR-implementeringen enklare. Som en del av vårt engagemang för att utveckla sjukvårdstekniken är vi glada över att kunna meddela att vi deltar i den tredje internationella utställningen och konferensen, Rebuild Ukraine Healthcare, som hålls i Warszawa den 24-25 juni. Tillsammans med vår partnerprodukt Cambio kommer vi att visa upp vår expertis inom digitalisering, molnlagring av e-hälsodata och processmodernisering inom hälso- och sjukvårdssektorn som en del av den svenska paviljongen.
–
Om författaren
YURIY SHTYBEL
Mjukvaruarkitekt på Sigma Software Group
Yuriy Shtybel har 15 års erfarenhet inom IT-branschen och är en erfaren expert på webbutveckling. Hans expertis täcker hela projektets livscykel, från analys av affärskrav och arkitektur till design, användargränssnitt, konstruktion av moduler och komponenter samt implementering. Han har framgångsrikt levererat projekt inom e-handel, EdTech och fordonssektorn och har haft kunder i USA, Kanada, Europa och Israel. Hans engagemang för excellens är tydligt i att han konsekvent möter och överträffar kundernas förväntningar.
