1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
|
###################################
# 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?
|
