De vigtigste afhængigheder er:
- Pakken i dette repository
- Pathling
- Spark
Pakken i dette repository gør forbindelse til Spark-clusteren (der, hvor beregningerne udføres) og S3-bucket'en (der, hvor data ligger) så nem som mulig for brugeren.
Pathling tillader at skrive FHIRPath queries på data, så vi kan lave traditionelle SQL-agtige views, som derefter kan joines sammen med normal Spark-syntaks til det endelige resultat.
Alle eksemplerne følger denne fremgangsmåde.
Bemærk at Jupyter Notebooks cacher deres resultater i filen. Når du kører på testdata kan du se bort fra dette, men hvis resultaterne indeholder personfølsom information vil disse være indeholdt i notebook'en. Du bør derfor ikke pushe dem til fut-infrastructure/spark-bi.
- Åben en ny terminal på JupyterHub
- Hvis du ikke allerede har gjort det, så klon det nuværende repository (
git clone https://github.com/fut-infrastructure/spark-bi/) cd spark-bipip install -e .- Åbn en notebook og genstart kernel for at sikre at den nye pakke er tilgængelig
5.1 Klik på
Kernel->Restart Kerneli menuen i toppen - Du er nu klar til at køre notebooks. Først block i hver notebook skal køres for at initialisere forbindelse til Spark og S3, og derefter kan du køre "run all" for at køre hele notebook'en.
Kørsel lokalt kræver at der findes et delta-lake udtræk lokalt. Et test-udtræk med det rette skema kan rekvireres fra FUT-S/TRIFORK. Dataene skal placeres samme sted som i data_location.py, eller der skal rettes i denne fil.
Den nemmeste opsætning er med uv, den bedste package-manager til Python. Guide til opsætning her.
- Kør
uv synci roden af projektet - Åben en notebook i VSCode
- Tryk "run all"
- Vælge "Python environments" -> Miljøet i den aktuelle mappe
Resultaterne dukker op.
Spark 4 understøtter officielt Java 17 og Java 21. Java 18+ kræver -Djava.security.manager=allow, hvilket pakken automatisk sætter via SPARK_SUBMIT_OPTS samt spark.{driver,executor}.extraJavaOptions. Hvis du oplever problemer, så installer en LTS JDK (brew install openjdk@21) og peg JAVA_HOME derpå.
FHIRPath queries kan med fordel testes på en testresource på denne hjemmeside. Hvis FHIRPath-udtrykket bruger relevante funktioner, men f.eks. efterspørger en extension der ikke findes på ressorucen, vil Pathling blot returnere "None" som værdi.
Pathling har desuden en række eksempler i deres dokumentation.
Som udgangspunkt skalerer Spark selv antallet af cores og hukommelse of executors, hvis en query tager lang tid. Hvis der er brug for manuel kontrol, kan FutPathlingContext.create tage spark parametre:
spark.cores.max: hvor mange cores der kan allokeres til jobbet på tværs af executors (total cores)spark.executor.cores: hvor mange cores der allokeres til hver executor (worker JVM)spark.executor.memory: hvor meget hukommelse der allokeres til hver executor (worker JVM)
Sparks dokumentation giver et fint overblik over disse:
Rapporterne her er kørt på data fra TRIFORKs testmiljø. Derfor afspejler resultaterne ikke produktion, og ser meget underlige ud.
Det viser sig, at meget få episodes-of-care har en kommune tilknyttet på TRIFORKs testmiljø. Derfor bruges typisk patientens bopælskommune som proxy for e.g. en spørgeskemabesvarelses "kommune".
I produktion bør man overveje, om man vil bruge QuestionnaireResponse.episodeOfCare.managingOrganization.municipalityCode.
Jeg er usikker på, om vi kan entydigt identificere organisatoriske enheder.
De organisatoriske enheder vil være repræsenterede som ehealth-organization, men en ehealth-organization er ikke opmærket med, hvilket niveau i SOR den afspejler.
En mulighed ville være at downloade hele SOR, finde kun de organisationer der har SOR-type == "Organisatorisk enhed", og så bruge dette til at filtrere. Det udskydes for nuværende.