=====Client=====


====Opskrift til tilretning af makroer====
  *Indsæt <script></script> tag omkring resume teksten
  *Er resume teksten lavet med pracro syntaks skal det omskrives til lua
  *Under scripts tilføjes linien "<script src="value.lua"/>"
  *Hver enkelt <script></script> under <scripts> skal laves til en funktion i stedet for. Eks. "<script name="evolution_enable">" skal således skrives om til funktionen "function evolution_enable()". Alle funktioner kan indkapsuleres i en enkelt <script></script>, der behøver ikke være en omkring hver enkelt funktion.
  *Hver enkelt funktion skal ikke længere returnere true da der ikke længere er noget at returnere til. Fjern derfor den linie fra alle <scripts> under omskrivningen. Før blev det brugt til verificering, men det er ikke længere relevant.
  *Der er ikke længere noget der hedder enable('widget') og disable('widget'). I stedet skal man skrive "w = widget('evolution'); w:setEnabled(boolean);"
  *Lav search/replace på "getValue('" og ændr det til "value('"
  *Under "<widgets>" skal alle steder med "script="[script]"" laves om til "onChange="[funktion]()""
  *Hvis der er regexp entries i én eller flere widgets, skal disse laves om til lua regexps. Dokumentation er her http://www.lua.org/manual/5.1/manual.html#5.4.1
    *Under "<scripts>" indsættes "<script language="lua" src="regexp.lua"/>"
    *På de relevante widgets laves checket med "onChange="this:setValid(regexp('[lua regexp]'))"". Er onChange i brug i forvejen indsættes koden blot efter den kode der allerede er der. Eksempel: "onChange="enFunktion(); this:setValid(regexp('[lua regexp]'))""


====Tilrettede makroer====
  *tidligere_alment-1.0
  *tobaksrygning-1.0
  *tidligere_oejensygdomme-1.0
  *aktuelle-1.0
  *medicin-1.0
  *allergier-1.0

====Metawidgets med lua kode i format string====
  *aktuelle-1.0

====Specifikke macro spørgsmål====

====Macro rettelser====
  * Skal der generelt være en "ikke udfyldt" entry i alle combo bokse? Pånær dem der har en default værdi sat naturligvis. NEJ! Det skal der ikke sagde manden, for en combobox widget virker fint med false validering når der /ikke/ er sat en kendt default værdi. Det virker til gengæld ikke i altcombox'ene, da de pt. altid sætter altitem (eller den sidst tilføjede item?) som default og derfor true validering. Det løses for nuværende med at lave valideringen med et script.

===My own notes from complete review of ref macros 27th of January 2010===
==Visus - egen korrektion==
Sf osv. skal overføres automatisk fra egen brille makroen hvis den er udfyldt tidligere.

==Cycloplegisk refraktion==
Så vidt jeg forstod på Kristina og Henrik er det slet ikke fra Phoroptoren værdierne til denne skal hentes. Det skal jeg lige snakke med Toke om.

==Forunder - Konklusion==
Der skal muligvis tilføjes en mulighed i øverste combobox. Det er ikke altid at patienten beslutter sig på dagen og der skal derfor stå noget i retning af "Patienten er kandidat til refraktiv kirurgi, men ønsker at overveje om behandling ønskes.". Hvis denne mulighed vælges, så skal boksen med "der aftales" ikke være aktiv, da man jo ikke har aftalt noget. I stedet kan lægen/optikeren skrive noget om årsagen i supplerende.

===My own notes from complete review of ref macros 6th of October 2009===
Generel navngivning af macroer i xml headers og i templates skal diskuteres. Jeg mener der skal være mulighed for punktum og bindestreg.

==ref_forunders==
  * Øjendrypning: Skal diskuteres til bunds. Lige pt. har jeg 2-3 forskellige. De bør samles i et med et fælles præparat sæt.
  * Spaltelampe: Alle "ikke udfyldt" valgene skal IKKE være der. Feltet skal i stedet være rødt, men grundet en bug i altcombobox fungerer det ikke pt. Se mere under bugs.
  * Spaltelampe: Skal flap, folder og interface fjernes? Hvis de ikke udfyldes kommer de ikke med i resumeet, så hvis de kunne være brugbare kan de bare blive stående.
  * Konklusion: Noget med en epikrisetekst der skal poppe op - hvad menes der?
  * Konklusion: Skal informeret samtykke være integreret i konklusionen? I tremaanederskontrollen viser resume teksten i Tokes dokument at der gives samtykke.

==ref_foerstedagskontrol==
  * Visus - uden korrektion: I Tokes dokument nævnes et felt til indtastning af tal mellem 0 og 2. Jeg kan godt se idéen, men er det ikke bedre blot at anføre mulighederne på listen i stedet for at smide ekstra felter på?
  * Spaltelampe: For stroma, flap, folder og interface, skal der da tilføjes en "ej relevant" option? Ifølge Tokes dokument er de kun relevante efter bestemte kirurgiske indgreb, men jeg har ikke umiddelbart mulighed for at tjekke på disse. Eller kan jeg? Personligt synes jeg det vil være overkill at lave checks på det. "ej relevant" muligheder burde være fint.

==ref_tremaanederskontrol==
  * Medicin: Skal diskuteres generelt for alle forløb. Lægerne bruger al for lang tid på at udfylde dem og den er for præcis i sine angivelser.
  * Tidligere alment: Skal hentes ind fra tidligere "tidligere alment" felter fra tidligere. Kan de lade sig gøre?
  * Visus - uden korrektion: Skal diskuteres. Der står anført op til flere macroer i én. Skal der laves en mere der hedder "visus binokulær"? og skal de indsættes efter hinanden ligesom i ref_forunders?
  * Tonometri / lufttonometri: Der står specifikt anført lufttonometri, men jeg har valgt at indsætte den generelle tonometri macro. Jeg går ud fra det er fint.
  * Øjendrypning: Igen igen. Den skal diskuteres.
  * 90-d linse: Anførslen af "hul eller rift kl" skal udspecificeres. Hvad skal regexp på den være? Er det et klokkeslet eller er det en klasse?

==ref_behandling==
  * Kirurgisk procedure: Part2 delene skal have tilføjet scripts, så de invalid hvis checkbox ikke er checket.
  * Kirurgisk procedure: Skal macroen splittes op i flere undermacroer i stedet for at være i en stor? I så fald vil part2 macroerne blot bestå af en enkelt checkbox, men det kan måske være fint nok.
  * Øjendrypning: Igen igen. Den skal diskuteres.
  * Generelt: requires i ref_behandling template filen fungerer ikke da der er brugt '.' og '-' i macro navnene. Det bør fikses, så det er muligt at bruge disse tegn.
  * Generelt: Der skal være en header på hele forløbet, så der bliver indsat overskrift i pcp.







====Bugs====

  * 1. I have marked all the following lines with a 1. to signify that they are part of the same bug. I don't know how this wiki syntax stuff works when i need to make line breaks.
  * 1. It seems that the requires option used in the template files doesn't work as expected. In a template file i have the following:
  * 1. <macro name="ref_behandling.klargoering" requires=""/>
  * 1. <macro name="de_5_trin" requires="ref_behandling.klargoering"/>
  * 1. <macro name="ref_behandling.kirurgisk_procedure" requires="ref_behandling.klargoering,de_5_trin"/>
  * 1. The header names of the referred macro files are similar til these (i copied them directly to avoid spelling errors). The behavior is as follows: The kirurgisk_procedure is locked until de_5_trin has been filled in. The de_5_trin macro is never locked, not even if the ref_behandling.klargoering has not been filled in. IMPORTANT!!!!!!!! This bug is tied to the fact that "requires" parses for non-characters when deciding when one entry ends and another begins. So if the macro name has, for instance, '.' or '-' in them, they won't work.
  * If an altitem in an altcombobox can't be found (for instance when innerwidget attribute is misspelled), the client seems to crash right after aknowledging that it can't find it.
  * Not a bug as such, but when a macro is opened up in the client and you want to scroll down to it using the mouse wheel, you more often than not end up changing several of the combo boxes on the way down. Changing combo boxes using the mouse wheel should be disabled overall.
  * Hvis man lige har valgt noget i en combobox, har jeg for vane lige at klikke et "tomt" sted bagefter, så combobox'en bliver unselected for at undgå at man kommer til at trykke pil og skifter den uden man ligger mærke til det. Når man gør det i pracro klienten ender jeg altid med at ramme en af macro linierne hvorefter save, close, cancel dialogen dukker op. Det er meget generende. Åbn/luk macroer bør begrænses til kun at foregå med åbn/luk knappen til venstre for titlerne.
  * Vælges "cancel" i dialog boksen der dukker op når man lukker en ændret macro, så har man pludselig to macroer åbne på samme tid.
  * Når en resumé tekst er for stor i en eller anden grad, så skriver clienten kun 2-3 af linierne når en macro lukkes. Resten forsvinder nedadtil eller ud i højre side udenfor vinduets område.
  * Det bør være muligt, via lua, at lave et script der spørger om en checkbox er true eller false i stedet for at man, som nu, skal bruge getValue. Det medfører at man skal skrive checkboxens truevalue mindst to steder i dokumentet og de _skal_ stemme overens. Ændrer man derfor det ene sted kan det skabe stor forvirring. Ofte vil man endda bruge det mere end 2 steder når man også bruger det i if sætninger i resumeet.
  * Det er ikke muligt at bruge < og > på fornuftig vis i macroerne lige pt. De skal escapes dobbelt, men selv da giver de problemer når så resuméet bliver vist for her er de ikke længere escapet nok. Et work-around er pt. at escape dem 3 gange, men det virker lidt tåbeligt.
  * Vinduernes placering huskes ikke altid til næste gang Pracro åbnes.
  * "Supplerende" lineedit i konklusionen i ref_forunders kommer ikke altid med i resumeet. Det lader til at være lidt tilfældigt om den bliver gemt eller ej så det må antages at være et problem i kommunikationskoden mellem server og klient. Det kan dog ikke udelukkes at det skyldes en fejl i makrokoden.

  * Når lægen/optikeren bruger ref_kir makroerne, så lukker de ofte Pracro midt i en undersøgelse fordi de skal vente på at patientens bliver dilleteret (det tager ca. 30 min.). I den sammenhæng tager de en ny patient ind midtvejs og vender senere tilbage til den dilleterede patient. Det bevirker at sammenhængen i teksten der indsættes af Pracro makroerne bliver delt i 2 og at rækkefølgen af dataene der er indsat i Pc-Praxis journalen ikke længere stemmer overens med Pracro templatens rækkefølge. Dette er et problem når patienten sendes til OP, hvor lægerne skal kende visse værdier for at kunne udføre en operation. For at finde disse værdier skal de nu rode rundt i journalen, med risiko for at de værdier de finder enten er blevet overskrevet med nye værdier længere nede, eller også er uddaterede. Det er IKKE optimalt på nogen måde. Det skal diskuteres igennem med Toke og Co. (Kristina, Henrik, Nicolai og Bent).
  * I ref_kir forunders template under konklusion, klager Kristina over at hun altid skal vælge øje, også selvom hun vælger "andet" under operationstype. Det bevirker, siger hun, at der opstår mulighed for fejl, da de nogen gange skriver "skal konsultere med jesper før der vælges øje". Når de skriver dette er de stadig tvunget til at vælge øje, så der fremgår altså en øje i journalen, selvom de endnu ikke har lagt sig fast på det. Når de så senere har konsulteret Jesper, så udfylder de øjet korrekt. Når operation skal foretages, vil der derfor være angivelse af øje to steder. Kigges der ikke det korrekte sted, kan det i yderste instans bevirke at patienten bliver opereret forkert. DET MÅ IKKE SKE!!!!!!!!!! Foreslag til ændring er at øje-comboen simpelthen bliver deaktiveret hvis der vælges andet.

====Tanker====
  * At man kan skille journalfilen ad på en sådan måde at man kan skille den fra hinanden og erstatte en klump med noget andet.
  * At man visuelt i pracro kan indikere hvilke journaltekster som er gamle og hvad for nogen der er nye og som vil blive committed når Pracro lukkes.
  * Kan man stalle data i uploadserveren til om natten, så dataene ikke bliver skrevet i PCP direkte, men i stedet har en sideløbende journalviewer hvor nye entries konkatineres. Heri kan de så editeres inden de bliver gemt i PCP som final dagen efter. Det medfører naturligvis at dataene ikke er tilgængelige i PCP journalen med det samme.
  * Efter man har udfyldt et felt vil det være en fordel hvis "enter" springer videre til næste felt, ligesom "tab" gør det. Det er efterspurgt af både Kristina og Henrik fra ref-kirurgi.
  * Ref_forunder:Konklusion: Der bør tilføjes "Patienten er kandidat til refraktiv kirurgi, men ønsker at overveje om behandling ønskes". Herefter skal aftale felterne være greyed.