###################
# Makro templates #
###################
En makro template best�r af tre dele:
1: Header
2: Queries
3: Widgets
Headeren indeholder alle overordnede info, s�som cpr nummer og makro
version.
Queries udf�res af serveren een gang og resultaterne mappes til nogle
symboler som kan bruges i value felterne i widgets sektionen.
Der skal v�re mulighed for simpel aritmetik i mapningsfunktionerne.
Widgets sektionen er som beskrevet andetsteds.
###########
# Queries #
###########
For at en query skal give mening, skal der v�re en stor m�ngde klasser
man kan lave requests p�.
Disse klasser skal tilsammen beskive al apparatur p� afdelingen,
hiraktisk, s� man f.eks kan bede om "lensmeter" eller en konkret
model.
En nedarvningsmodel kan bruges som inspirationskilde.
Der skal v�re mulighed for at h�fte flere klasser p� det samme
apparat, idet nogle apparater m�ler mere end een ting. (ala multipel
nedarvning.)
Sproget i en query som laver mapningen.
-> class, cpr, timestamp (oldest)
<- xml formateret
<svar>
<gruppe navn="fisk">
<v�rdi navn="dims" value="42"/>
<v�rdi navn="fnuller" value="blah"/>
</gruppe>
<gruppe navn="ostemad">
<v�rdi navn="dims" value="42"/>
<gruppe navn="olm">
<v�rdi navn="fnuller" value="blah"/>
</gruppe>
</gruppe>
</svar>
Mapningerne kan s�ledes laves 1:1 fisk.dims, fisk.fnuller,
ostemad.dims og ostemad.olm.fnuller.
Eksempler p� mapninger:
<map name="myvalue">
2*fisk.dims
</map>
<map name="anothervalue">
pi = 3.14
sin(fisk.dims / pi) + 42
</map>
Mapningssproget
LUA?
Simplere (ala bc)?
######################################
# Preudfyldning af felter i en makro #
######################################
Preudfyldningen skal ske serverside.
Det skal indikeres i feltet at det er preudfyldt og den information
skal lagres sammen med dataene naar de senere bliver gemt paa serveren
efter en commit.
Hvis preudfyldte felter aendres paa klienten, skal dette indikeres i
de lagrede data.
Skal den preudfyldte vaerdi lagres, saa man altid kan se hvad det
foreslaaede var?
Data som allerede eksisterer paa serveren:
Hvis et felt allerede findes paa serveren fra en tidligere
indtastning og dens ttl ikke er overskredet, skal feltet preudfyldes
med denne vaerdi.
TTLerne?
Hvem skal saette dem?
Hvor skal de saettes?
Hvis de saettes paa feltet paa kontruktionstidspunktet, uafhangig af
kilden, betyder det at feltet har samme udloebstid uanset om det er
manuelt indtastet, eller indlaest fra en ekstern kilde.
Et felts ttl vil nok vaere defineret uafhaengigt af kilden, saa
ovenstaeende loesning kan sikkert vaere fin nok.
Data som kommer fra eksterne kilder:
Et flest skal have en eller flere properties som indikerer at feltet
skal udfyldes fra en ekstern datakilde.
Disse properties skal beskrive hvilken kilde dataene skal hentes fra,
samt hvor gamle dataene maksimalt maa vaere.
En maade at goere det paa kunne vaere at kalde en ekstern applikation
(via. popen eller lign.) som spytter data ud paa stdout i et af
pracro velkendt format.
Parametrene til dette eksterne program kan saa styres vha. af en
lignende mekanisme som i formatet til journal resumeet ($$, ${cpr},
${firstname}, etc).
En anden maade at goere det paa kunne vaere at lave et indbygget
kommandosaet som kan tage en raa streng som parameter, som derved
fungerer som kald til et eksternt program, bortset fra at der kaldes
en intern rutine istedet.
En tredie maade, som er en afart af den anden maade, vil vaere at
lave kommandsaet baseret udelukkende paa kilde. [kilde]/[apparat]/[parameter]
ex. pentominos/lensmeter/axis
Problem: Hvordan skelnes mellem flere ensnavngivne parametre?
I lensmeter findes axis parameteren principielt to gange, een gang
for hoejre og een gang for venstre linse.
Hvis der baade eksisterer data paa serveren og findes ekstern data.
Dataene paa serveren har precedens over data fra eksterne kilder,
hvis:
a) Dataene paa serveren er nyere end dem fra den eksterne kilde.
b) Dataene paa serveren er indtastet af en bruger og stadig gyldige.
Hvis der hverken findes gyldig data (ikke eksisterende eller
udloebet) paa serveren eller fra den eksterne kilde (igen ikke
eksisterende eller udloebet) benyttes value feltets indhold.
Pentominos data eksempel:
Serveren laeser:
<lineedit name="dioptri_odex"
source="pentominos/lensmeter"
command="cliclient --cpr=${cpr} query --filter=latest --deviceid=lensmeter --devicetype=lensmeter --format=xml"
ttl="86400"
value=""/>
Serveren oversaetter dette til:
<lineedit name="dioptri_odex"
value="4"
source="pentominos/lensmeter"/>
Taenkt eksempel med et fundus billede:
Serveren laeser:
<image name="dioptri_odex"
source="pentominos/fundus"
command="cliclient --cpr=${cpr} query --filter=latest --devicetype=fundus --format=raw"
ttl="86400"
value="SOMERAWJPEGCODEINBASE64-9823fasd73487234fas7asd8732487asd8fc7sd8f76328732"/>
Serveren oversaetter dette til:
<image name="dioptri_odex"
value="SOMERAWJPEGCODEINBASE64-9823fasd73487234fas7asd8732487asd8fc7sd8f76328732"
source="pentominos/lensmeter"/>
###################################
# Avanceret validering af widgets #
###################################
LUA Ide:
LUA som validering, sat i serie med en regexp validering. Begge kan
vaere tomme, eller udeladt (svarende til tomme).
Hver widget optraeder automatisk som preloaded variabel i lua
programmet.
Programmet indeholder en funktion validate som returnerer true eller
false afhaengigt af om den er valid eller ej.
Hvad med reserverede karaterer i hhv. LUA og XML? skal lua koden base64 enkodes?
Eller maaske bare XML kodes (i.e. " osv.)
Hvornaar skal koden udfoeres? Naar feltet aendres? Naar feltet forlades (lost
focus) eller inden makroen comittes?
Flere funktioner kan introduceres for at kunne udfoere lua kode paa forskellige
tidspunkter (onfocus(), onfocusleave(), onchange(), beforecommit(), etc...)
Istedet for at bruge direkte mapninger mellem variable og widgets kan man bruge
et array (eller hvad der nu svarer til map< std::string, std::string > i c++),
saa man slipper for at overskrive nogen af LUAs interne variable og funktioner.
Hvis der ikke findes en saadan type i LUA kan man lave et funktionkald ind i c
koden som goer det, altsaa field('varname')
Injicering af data i makroen paa runtime.
Et funktionskald fra lua programmet saetter vaerdien af et felt.
En serie af funktioner kan introduceres til at kontrollere GUI igennem LUA.
Funktioner som disable('button1'), uncheck('checkbox2'), osv.
Disse funktioner skal bruges til at lave selve makroindholdet dynamisk, saa man
f.eks vaelger en radiobutton som aktiverer en hel undersektion af lineedits.
Alt dette kan muligvis implementeres vha. checkbox/radiobutton grupper istedte,
saa man slipper for denne forholdsvis dybe kontrol paa LUA niveau (laes, der er
mange muligheder for fejl!)
Eksempel:
<lineedit name="dioptri_odex"
regexp="[1-9][0-9]{0,2}"
lua="function validate() return math.abs(fields['dioptri_odex'] - fields['dioptri_osin']) < 3 end"
value=""
help="Dioptrien p� venstre �je skal v�re max 2 dioptri fra h�jre."/>
<lineedit name="diotri_osin"
regexp="[1-9][0-9]{0,2}"
lua="function validate() return math.abs(fields['dioptri_odex'] - fields['dioptri_osin']) < 3 end"
value=""
help="Dioptrien p� h�jre �je skal v�re max 2 dioptri fra venstre."/>
##################################
# Forl�b og deres struktur i xml #
##################################
Makro er en del af et forl�b
Forl�b skal sammens�tte makroer i logiske sekvenser.
- Backward dependancy
- Forward dependancy
- Optional
- Required
Et forl�b beskrevet som et komplet xmldokument?
- Alle makroer er indeholdt i et st�rre dokument, forl�bet.
- N�r data postes, lagres forl�bs id sammen med makro id'et.
- Der er indbygget i xml strukturen en logisk sammenh�ng mellem makroerne
(dependencies o. lign.).
Eksempel:
<forl�b>
<makro navn="makro1" completed="true" optional>
...
</makro>
<makro navn="makro2" depencies="makro1" required>
...
</makro>
<makro navn="makro3" depencies="makro2" optional>
...
</makro>
<makro navn="makro4" optional>
...
</makro>
<makro navn="makro5" optional>
...
</makro>
<makro navn="makro6" depencies="makro1,makro5" required>
...
</makro>
</forl�b>
Eksempel med B2 forloebet i pseudokode:
B2 req
B21 dep=B2 opt
B22 - B26, B28 dep=B2,B21 opt
B27 dep=B2,B21 req
B29 dep=B27 req
#############################################
# CPR indtastning, hvordan? hvor? hvornaar? #
#############################################
1) - CPR nummeret hentes fra sygesikringsbevis eller RFID eller lign.
- Det sendes til cpr server (ligesom paa barcode)
- Naar et apparat skal sende data henter det foerst cpr nummeret vha.
sit lokationnummer.
2) - CPR nummeret hentes fra sygesikringsbevis eller RFID eller lign.
- Det sendes til pentominos med lokationsnummer som raa data som alle
andre apparater.
- Naar der sendes data fra et andet apparat vedhaeftes kun lokationkoden,
og det er pentominos serverens ansvar at vide hvilket cpr nummer der
skal bruges.
3) - CPR nummeret hentes fra sygesikringsbevis eller RFID eller lign.
- Nummeret lagres lokalt paa den Soekris kassen.
- Naar der sendes apparatdata vedhaeftes det lagrede cpr nummer.
4) - CPR nummeret hentes fra sygesikringsbevis eller RFID eller lign.
- Nummeret sendes til en server sammen med et lokationsnummer.
- Serveren har registreret hvilkemaskiner der findes paa den lokation
og broadcatser cpr nummeret til disse.
5) - CPR nummeret hentes fra sygesikringsbevis eller RFID eller lign.
- Det sendes til cpr server (ligesom paa barcode)
- Naar der sendes data fra et andet apparat vedhaeftes kun lokationkoden.
- Pentominos serveren henter cpr nummeret fra cpr serveren vha. den
vedhaeftede lokationskode.
Overvejelser:
a - Data og kilde (cpr nummer) boer holdes samlet.
b - Hvem har ansvaret for at cpr nummer og data haenger sammen.
c - Hvem har ansvaret for at cpr nummer og data er rigtige?
d - Fordele/ulemper ved at have een cpr indtastningsmekaniske pr. Soekris
boks.
e - Hvilken vej koerer forbindelserne? Kan de fungere igennem en firewall?
f - Hvor mange forbindelser er der?
g - Boer forbindelserne holdes i live fremfor at lave nye hver gang der
skal kommunikeres?
h - Hvilke muligheder vil vi have for central logning af hvor patienter
bliver 'logget ind'?
i - Hvor og hvordan skal cpr numrenes ttl implementeres?