Opsætning

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.

Deling a Jupyter Notebooks

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.

Kørsel på JupyterHub

1. Åben en ny terminal på JupyterHub
2. Hvis du ikke allerede har gjort det, så klon det nuværende repository (git clone https://github.com/fut-infrastructure/spark-bi/)
3. cd spark-bi
4. pip install -e .
5. Kontakt FUT-S/TRIFORK for at få log-in information til S3 (dataopbevaring). Kopiér example-reports/credentials_example.py til example-reports/credentials.py
6. Udfyld værdierne
7. Du er nu klar til at køre notebooks. Åben `

Kørsel lokalt

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.

1. Kør uv sync i roden af projektet
2. Åben en notebook i VSCode
3. Tryk "run all"
4. Vælge "Python environments" -> Miljøet i den aktuelle mappe

Resultaterne dukker op.

FHIRPath

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.

Performance

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:

• Spark Cluster Mode Overview
• Spark Scheduling Configuration

Data

Rapporterne her er kørt på data fra TRIFORKs testmiljø. Derfor afspejler resultaterne ikke produktion, og ser meget underlige ud.

Kommune

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.

Organisatorisk enhed

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.