Den här webbplatsen använder kakor (cookies) för att spåra trafik som delas med Google Analytics och andra parter. Dessa parter kan kombinera denna information med den som de samlat in genom din användning av deras tjänster. Du samtycker till våra kakor genom att fortsätta använda denna webbplats.

Archives

v2.68

Vi har inte haft någon release sedan slutet av april så det blev ganska många förändringar denna gång, bland annat har rollhanteringen gjorts om från grunden. Dock är det fler ändringar på “insidan” än “utsidan”.

Roller och yrkeskategorier

De tidigare rollerna placerade inte tydligt nog användare i sin yrkeskategori, framför allt om det rör sig om vårdpersonal eller registerpersonal, vilket är viktigt då det är förknippat med olika juridiska krav. Detta blev särskilt tydligt i och med den nya koordinatorrollen.

Vissa roller har direkt översatts till de nya:

Tidigare Ersätts med
Registrerare (oförändad)
Enhetsadminstratör Plusregistrerare
Registeradministratör   Koordinator

Den enda skillnaden mellan Plusregistrerare och Registrerare är för närvarande att Plusregistrerare kan ladda ned data med personnummer. Dessa tre roller är de enda som för närvarande går att logga in på. Rollen Patient kan också bli aktuell för inlogging, då vi skulle kunna leverera ut “e-utdrag” från register och erbjuda inloggning via Mobilt BankID.

Koordinatorrollen är en registrerarroll men utökad så att vårdenhetsgränser kan överskridas, det vill säga att om man som koordinator söker upp en patient så hämtas samtliga registreringar upp, oavsett vårdenhet. Koordinatorn är också den som (tekniskt) har möjlighet att förändra register och att begära registerutdrag för samtliga patienter med personnummer.

När en koordinator uppdaterar en registrering kommer den ursprungliga kontexten inte att skrivas över, det vill säga registreringens ursprungliga uppgifter om vårdenhet, användare och roll bibehålls. För en ny registrering gäller som vanligt att man måste vara inloggad på den vårdenhet som registreringen skall tillskrivas (likt övriga registrerarroller).

Gränsöverskridande formulär

En närliggande nyhet är stöd för “gränsöverskridande”, subjektbundna formulär. Dessa ger liknande möjligheter som koordinatorrollen, fast för användare som är vårdpersonal. Om en registrering tillhör en annan vårdenhet hämtas en begränsad del av registreringen upp (i dagsläget de variabler som är identifierare).

I registrerings­applikationen går det då inte att öppna aktuell formulärpanel, endast titelraden visas samt knappraden för att lägga till underformulär. Titeln sätts förvalt till “(dold)” men kan på vanligt vis förändras via TitleOfPanel i registrets metodskript.

Ett alternativt tillvägagångssätt skulle kunna vara att panelen kan öppnas men alla uppgifter är skrivskyddade plus att Spara-knappen är inaktiverad. Vi får se vilket som behövs framöver.

Eftersom detta kan utgöra en överträdelse av patientdatalagen bör man vara försiktig att använda den utan prövning av jurist. Denna typ av formulär är viktiga då de ger en möjliget att ha kompletta kedjor av registreringar som huvud-/underformulär som kan ses av av alla vårdenheter inom ett register. Viktigt inte minst för SFR och SHPR där man behöver kunna följa patienter över vårdenhetsgränser på ett effektivt sätt. Eventuellt behöver vi bättre kunna skräddarsy vilka uppgifter som hämtas upp och visas för dessa registreringar. Framtiden får utvisa.

Stödet för anonyma registreringar har tagits bort. Anonyma registreringar var planerat att användas för bland annat anmälan till register men är förknippat med för mycket säkerhetsproblem.

Byte av kontext

Kortkommandot Ctrl-Shift-K kan nu användas för att komma åt dialogen för att byta kontext. Listan med vårdenheter kan nu sökas på samma sätt som i registreringsapplikationen, det vill säga både på vårdenhetskod och delar av namn. Dialogen väljer och stänger nu vald kontext med Enter-tangent. Om man byter till en kontext inom samma register blir man nu kvar i samma läge (även inne i registrerings­applikationen), under förutsättning att man fortfarande är behörig. Vald kontext blir nu automatiskt den förvalda. Kort sagt diverse förbättringar för att snabbare kunna växla mellan kontexter, särskilt för våra kommande koordinatorer.

Aggregatstatistik

I Aggregat-api:et kan man nu utöver “count”, som avser antal registreringar som grundläggande mätvärde, använda sig av “subjectcount” (antal patienter), “unitcount” (antal vårdenheter), “usercount” (antal användare) samt “transfercount” (antal direktöverförda registreringar).

Till exempel returnerar

1
http://stratum.registercentrum.se/api/aggregate/SFR/Frakt/total/count/month(InsertedAt)?apikey=bK3H9bwaG4o=

totalt antal registreringar per månad i Svenska Frakturregistret medans

1
http://stratum.registercentrum.se/api/aggregate/SFR/Frakt/total/subjectcount/month(InsertedAt)?apikey=bK3H9bwaG4o=

returnerar totalt antal unika patienter per månad.

Övrigt

ExtJS är uppdaterat från 5.1.0 till 5.1.1. Även vårt tema är uppdaterat till att bygga på 5.1.1.

Enhetsbundna registreringar valideras inte längre mot registreringshistoriken. Detta för att användningsområdet inte är särskilt stort och för att vissa enhetsbundna formulär numera innehåller stora mängder registreringar (läs QRegPV och Kvartalen). Gäller både i registreringsapplikationen, där skriptvariabeln History är tom, och på serversidan då formulär sparas.

Den i vissa webbläsare inbyggda stavningskontrollen är nu avstängd i alla textfält förutom kommentarsfält för att slippa irriterande, röda understrykningar i till exempel listrutor. Gäller registreringsapplikationen.

För de som skriver widgets finns nu också en “reader” som automatiskt transformerar data till dess kumulativa motsvarighet. Exempel:

Fixar

  • I registreringsapplikationen översattes felaktigt ett värde som inte kan matchas med någon kod eller del av namn i en urvalslista, till saknat värde. Nu behålls det felaktiga värdet.
  • Listan med delformulär är nu inaktiv för nya registreringar (likt knappen för att välja formulär).
  • I registerbeskrivningar var variablerna för landsting och vårdnivå felaktigt namnsatta då alla hette “UnitCode” med aktuellt förled.
  • Under vissa omständigheter kunde en registrering skrivas över av en annan vårdenhet än den som urprungligen sparat den. Detta gällde via SOAP-tjänster eller REST-api och när en registreringen hämtades upp via identifierarmetoden. Eftersom registreringsapplikationen alltid använder sig av EventID-metoden så fanns inte problemet där.
  • Det är nu möjligt att referera till samma variabel mer än en gång i aggregat-api:et, vilket är användbart ihop med klustermetoder, till exempel api/aggregate/lvr/visit/total/count/county(visitunit)/visitunit för att få en uppdelning på vårdenhet och gruppering på landsting.

Registercentrum Västra Götaland

v2.67

Denna version handlade mest om diverse buggfixar som levde kvar efter övergången till ExtJS 5.1, framför allt i de sökbara listorna i registreringsapplikationen. Det fungerade inte att klicka i listan, filtrering gjordes inte korrekt, med mera.

Registercentrum Västra Götaland

v2.66

Främsta förändringen till denna version är ett nytt tema, ext-theme-stratum, som bygger på Crisp-temat i ExtJS. Skillnaderna mot det gamla temat är framför allt att det använder Open Sans som typsnitt, vilket är lättare och mer läsbart, färre bakgrunder med färger och större grafiska element. Dessutom är det förvalda temat till Sencha Charts ändrat så vi nu använder de logofärger som Registercentrum Västra Götaland använder (bland annat de fyra färgerna i logotypen längst ned).

I samband med temaändringen har vi gått igenom alla formulär, dialogrutor och widgets. I vissa fall har uppgifter i formulär breddats (i och med att “Open Sans” tar upp mer plats) eller flyttats till ny rad, färger i vissa diagram har ändrats men i allt väsentligt är det samma utseende.

Sedan 2009 har vi haft stöd för Google Ajax Crawling Scheme för att få SEO-hantering (synlighet i sökmotorer) att fungera väl i Stratum. Då Google har som mål att tolka innehåll även för webbsidor som byggs upp med JavaScript (“However, we are continously working to make Googlebot behave more like a browser”), så har vi valt att ta bort detta stöd. Om detta inte skulle fungera så väl kan vi ta ett nytt grepp om SEO-hanteringen när vi bygger nya utsidan i Keystone JS.

Nu kan domänavbildningar även efterfrågas per register och för alla gemensamma domäner. Dessa är väldigt användbara när man vill översätta kodade värden till text. Tidigare har det endast funnits stöd för att räkna upp ett antal domäner, till exempel:

1
http://stratum.registercentrum.se/api/metadata/domains/map/4000,4001,4004?apikey=bK3H9bwaG4o=

Nu går det även att efterfråga alla gemensamma uppräkningsdomäner:

1
http://stratum.registercentrum.se/api/metadata/domains/map/common?apikey=bK3H9bwaG4o=

eller alla uppräkningsdomäner för ett register:

1
http://stratum.registercentrum.se/api/metadata/domains/map/register/122?apikey=bK3H9bwaG4o=

Fixar

Efter uppgraderingen till ExtJS 5.1 började filtreringen i registreringsöversikten att fungera dåligt. Bland annat gick det inte att återställa filter och ibland gick det bara att filtrera en gång. Dessa problem är nu åtgärdade.

Registercentrum Västra Götaland

Stratum 3 - möte 3

Initialt fokus på Cloudinary som tjänst för bildhantering - vad behöver vi ha för konto? Börja med gratiskonto och se när vi slår i taket. Flera typer av uppgradering av konto finns. Hur skall vi hantera stora bilder? Kan vi “resampla” genom Cloudinarys api? Hur väl fungerar integrationen med Keystone? Får vår kommunikatör det som behövs? Här borde vi sitta med henne för att mer i detalj avgöra hur hon arbetar. Vi skulle kunna åta oss att importerar hennes nuvarande bilder med taggar och titlar. Är det görbart?

När vi ändå talar om import - är det möjligt att importera sidor i största allmänhet? Då kanske vi kan flytta hela gamla webbplatsen på ett automatiserat sätt. Under tiden som vi ändå implementerar de första sidorna kan vi undesöka hur svårt det skulle vara.

Vad gäller mallar så föreslås att vi utgår från de ursprungliga skisserna från Ibiz. Härifrån avvaktar vi resultatet från Tonsillregistrets genomgång av sin befintliga och nya webbplats med vår kommunikatör. En snarlik fråga är: skall vi ha med registerbegreppet i Keystone och arbeta med en databas eller skall vi satsa på flera Keystone-instanser?

Teknikval i allmänhet och stack på klientsidan i synnerhet. Keystones admingränssnitt är numera implementerat med Facebooks React. Föreslår att vi använder React då det finns med i Keystone. Keystone-projektet och dess community kommer troligen använda det än mer, då Jed Watson visat vägen. Läs också om hans argument för att använda React. Däremot kanske vi borde välja bort JSX på grund av förkompilering och jobbig syntax? Angular JS som alternativ skulle kunna vara intressant då de också har komponenttänkandet i fokus (via Directives) och att det används i nya NDR.

Handlebars använder vi som “template engine” då känns mest “klassisk”. Dessutom kan Keystones generator producera vyer på detta sätt “out-of-the-box”.

IISNode och övrig IIS-integration. Hur väl fungerar det? Tänker då på hantering av certifikat, tvingande HTTPS, loggning och annat. Kanske bäst att förpassa så mycket som möjligt till Node.js och Keystone.

Vår Github-organisation:

Registercentrum Västra Götaland

v2.64-v2.65

Störst fokus i denna version fanns på uppgradering till ExtJS 5.1. Ett försök gjordes sensommaren 2014 men då fanns för många buggar i den nyintroducerade Sencha Charts och dessutom buggar i den gamla ExtJS Legacy Charts (bland annat saknades musevent i diagramdelar). Nu fungerar Sencha Charts, som är samma diagramstöd som finns i Sencha Touch. Detta använder Canvas istället för SVG/VML så det är bättre förberett för framtiden.

En snabbfix tillkom för att förhindra (ett återintroducerat) problem med dubbelklick i händelsepanelen, därav v2.65.

Nästa steg är att ta fram och implentera nytt tema som bygger på Senchas Crisp-tema men med mer neutrala färger och CartoGotic som typsnitt. Eftersom en del dialoger och widgets är väl “hårdkodade” mot det gamla temat så kommer det krävs en viss insats för att få till ett bra utseende på allt. Detta är ju ett av ett antal steg på vägen till att bygga om Stratums “utsida”.

Registercentrum Västra Götaland