Fåresyge er ikke vigtigt

Der er en læge der har sagt noget fornuftigt om anvendelse af Open Source Software i EPJ sammenhæng.

Istedet for at lytte til manden, hænger nogle sig i den fuldstændigt tåbelige detaille at den softwarepakke han har set sig varm på er skrevet i et sprog der hedder "fåresyge", eller på USAnsk: "MUMPS" [1]

De MUMPS eksempler disse folk har hevet frem ser i mine øjne ikke væsentligt slemmere ud end den typiske perl eller PHP kode man støder på rundt omkring.

Fakta er, at MUMPS faktisk var et sprog der var en hel del forud for sin tid og at mange af de features man var nødt til at lave for at klemme det ned i datidens computere ikke mere bruges.

F.eks var tricket med at visse reserverede ord kunne reduceres til blot et tegn en nødvendighed for at reducere hvor meget kildeteksten fyldte når compileren også skulle være der.

Oftest blev den "komprimerede" kildetekst lavet af et program, udfra den fuldt kommenterede og læselige kildetekst.

Det næste man skal huske er at "datiden" er Korea- og Vietnamkrigene.

Det intelligente valg, af et til formålet bygget sprog, betyder at softwaren har overlevet i snart 40 års skiftende hardware og operativsystem modeskift.

Og behøver vi at nævne at brugerne er glade og tilfredse ?

EPJ er en af de mest seriøse applikationer af IT de fleste af os nogensinde vil blive berørt af.

For IT folkene er det vigtigt at huske at vi kommer ind til systemet med blodet flydende eller ikke ved bevidsthed, så vi kan ikke være til nogen hjælp med f.eks at rense musens linse.

Vær så helt ærlig, hvad vil du helst have ?

Et system der er klappet sammen på et par år af nogle store internationale software/konsulent huse, for hvem det bare var endnu et lukrativt offentligt IT-projekt, kodet i C++ af en stak IT folk uden nogen medicinsk erfaring, på computere der skal antivirusscannes 4 gange om dagen.

Eller, et system der har virket i 40 år, fordi det er skrevet af medicinsk personale for medicinsk personale, mener skrevet i et sprog der hedder "fåresyge" ?

Kald mig gammeldags, men jeg foretrækker at blive mødt af erfaring når det handler om min sundhed.

Lyt til lægen, giv ham en bevilling til at få lavet et realistisk feasibility studie.

phk

PS: Her kan I læse mere om WorldVistA.

[1] Selv læger har humor: fåresyge hedder "mumps" på engelsk fordi folk mumler når hele svælget og halsen er svulmet op. "MUMPS" hedder sådan, fordi lægerne syntes programmerne lignede forsøg på at skrive mumlen ned.

Kommentarer (33)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Jeppe Johansen

Jeg må tilstå jeg aldrig før har hørt et ord om noget programmerinssprog kaldet "MUMPS". Jeg troede først det var en spøg eller bare et tilfældigt navn valgt fra esolangs.org

Hvor lærer man at programmere sådan et sprog, og er der nogen i Danmark der kan det? Jeg mener, der skal vel aligevel års tilpasning til for at det passer til det danske sygehusvæsen?

  • 0
  • 0
#2 Flamber Hansen

Nu ved jeg ikke hvad andre fagpersoner (læger, sygeplejerske, etc) siger, men lyt til fagpersonerne.

Det er dem, som skal benytte systemet til dagligt, i svære situationer, hvor der er stress og alt for lange arbejdsdage, som burde vælge.

Det er jo fantastisk, at en rigtig god programmør (det er dig Poul-Henning!), vælger en lidt alternativ løsning i forhold til hvad verdenen ellers har valgt med andre typer af systemer (f.eks. banker).

Men PHK har helt ret i mindst én ting: giv IT-chefen for Bispebjerg Hospital en lille pose penge, så han kan teste systemet. Det vil jo være en dråbe i havet, når man taler om udvikling af den nuværende struktur til 10 milliarder danske kroner!

  • 0
  • 0
#3 Deleted User

Nogle vil måske mene at der skal nyere og mere moderne kode til for at sådan et projekt ville kunne "overleve" i den moderne verden.

... men ligesom Poul-Henning er jeg enig i at MUMPS er længe fint et sprog. Ja, det dukkede godt nok op for første gang i 1966, og jo, den seneste opdatering er fra slut 1995, men gør det programmet (og koden for den sags skyld) til noget ubrugeligt?

Jeg vil mene (med den begrænsede viden jeg har) at kode, som der er blevet udviklet på, og vedligeholdt i lige knap 30 år, er yderst kompetent, stabilt, og ja, nogle vil måske vove den påstand og mene at koden er overlegen i forhold til et lignende system skrevet i C++, C# eller lignende, og "bakset" sammen på x antal år.

Jeg er nok lidt konservativ hvad angår dette emne. Hvorfor ikke (ligesom med Bispebjerg Hospital's initiativ) bruge noget der er kendt, og som man ved fungerer, og så personliggøre det efter ens behov? Jeg syntes det er en fantastisk idé, og et lækkert initiativ, og jeg glæder mig til at følge projektet i udviklingen.

  • 0
  • 0
#4 Henning Makholm

Jeppe spørger: "Hvor lærer man at programmere sådan et sprog?" Samme sted som man lærer alle andre programmeringssprog, velsagtens: I sin sofa, i selskab med en sprogdefinition eller manual, og sidenhen ved sin computer ved at læse eksisterende kode og skrive ny kode i sproget.

"og er der nogen i Danmark der kan det?" Det bliver der helt af sig selv efterhånden som der er nogen i Danmark der får brug for at skrive om i den eksisterende kode (og som ikke lider af programmeringsskræk og tror man skal holdes i hånden af en eller anden hundedyr kursusarrangør med tvivlsom kompetence for at tilegne sig et programmeringssprog).

  • 0
  • 0
#5 Nicolai Petri

Jeg er jo sådan set helt enig med at det lyder spændende... og hvis det ikke var fordi jeg kender (alt for mange) IT projekter hvor kravspecifikationen indeholder 95% meninger og 5% behov så ville jeg jo bare ønske de fik trykket kanonen af. MEN ... så SKAL de forh*lvede huske at fjerne de 95% vås/ønsker/bras/ændriger som nogen helt sikkert mener er u-undværlige for at systemet kan bruges i Danmark (hvor syge folk helt sikkert skal behandles meget anderledes - måske vi stammer fra Mars ??).

Så jo - jeg stemmer for forslaget - hvis man fokuserer på at ændre arbejdsgangene så de passer til systemet og ikke omvendt - ellers har vi jo et nyt indsæt navn på tilfældigt offenligt katastrofeprojekt her.

  • 0
  • 0
#6 Jørgen Henningsen

Jeg stødte faktisk på en IT løsning hos min tandlæge. Det så ud til at fungere funktionmæssigt, men det var jammerligt klodset. En standard fladskærms PC stablet op på et bord ved siden af instrumenter og autoklave. PC'en faldt fuldstændigt igennem og det er dog en application, som er rimelig nem at gå til. Prøv at forestille sig hvordan det ville fungere for en læge, som arbejder på et sygehus. Sundheds IT kommer simpelthen ikke til at fungere ordentligt før der er een eller flere af det store leverandører af apparater (siemens f.eks.) som begynder at lave specialiseret hard og software løsninger, som passer ind i den verden.

  • 0
  • 0
#7 Jan Keller Catalan

Jeg er en af dem, der har manet til overvejelse, når det kommer til et system skrevet i MUMPS.

  • Sproget er 40 år gammelt (sproget... ikke VistA, medmindre jeg har overset noget) men C er jo heller ikke just en ny opfindelse

  • Der er ikke mange i Danmark, der har hørt om MUMPS, så der vil være en del uddannelse og optræning af programmører medmindre man bruger en USAnsk leverandør med erfaring - men er man så afhængig af denne leverandør?

  • Systemet skal kommunikere med andre systemer i alverdens sprog - hvordan håndterer dette 40 år gamle sprog moderne kommunikationsformer?

Intet af dette taler i sig selv imod at bruge det - men det skal da overvejes og vurderes og holdes op imod et moderne sprog med masser af konsulenter og erfaring... men med mindre domæneviden og mindre specialiceret sprog.

Så jeg er fuldstændig enig med dem, der vil have et pilotprojekt - se at komme i gang :)

  • 0
  • 0
#8 Thomas Ammitzbøll-Bach

Der er i branchen en stigende bekymring for at anvende hjul i nye konstruktioner. Det er der faktisk flere grunde til:

1) Hjulet er en opfindelse, der daterer sig tilbage til oldtiden, og selvom materialevalget har ændret sig, så er der ikke foretaget en større revision, siden kuglelejet blev tilføjet.

2) Der er ingen support. Selvom der er mange fabrikanter, der fremstiller hjul, så er der ingen, der har det grundlæggende ansvar for, at det virker.

3) Ingen af dem, der var med, da hjulet blev opfundet lever i dag. Der er altså ingen, der kan forklare rationalet i opfindelsen eller videreføre de visioner, der lå bag.

4) Der er ikke i hjulet nogen mekanisme, der overvåger performance, sikkerhed og oppetid. Flere har oplevet, at hjulet var punkteret uden varsel, hvilket gør det vanskeligt at bruge i et driftsmiljø.

5) Det er meget vanskeligt at omsætte hjulets funktion til XML.

6) Fordi der ikke er patent på hjulet, er der ingen, der tør investere i hjul, fordi de ikke kan være sikker på at få deres investering igen. Der er adskillige piratkopier i omløb, og ingen kan gøre noget.

7) Specielt på ambulancer og brandbiler, der skal virke 24/7, er det særligt problematisk. Mange steder anbefaler man at gå væk fra hjul på udrykningskøretøjer.

Driver Group har i deres seneste rapport pointeret, at hjulet vil være udfaset om 2 til 3 år, og at den massive investering i vandrende robotter er udtryk for dette.

Thomas

  • 0
  • 0
#9 Torben Mogensen Blogger

Der er ikke mange i Danmark, der har hørt om MUMPS, så der vil være en del uddannelse og optræning af programmører medmindre man bruger en USAnsk leverandør med erfaring - men er man så afhængig af denne leverandør?

Omkostningerne til træning er ofte overdrevet. Der findes flere forskellige lærebøger i brug af MUMPS, så man kunne starte med at lade nogle gode undervisere lære sproget fra bøgerne, kodeeksempler og evt. kurser i USA. Dernæst sættes disse undervisere til at undervise danske programmører. Sammenlignet med de samlede omkostninger til EPJ er det peanuts.

Systemet skal kommunikere med andre systemer i alverdens sprog - hvordan håndterer dette 40 år gamle sprog moderne kommunikationsformer

Systemet bruges allerede til EPJ og lignende i USA, så jeg vil tro, at man har fundet en løsning på dette. Jeg kan heller ikke se, hvor problemet skulle være: Kommunikation sker i de fleste sprog gennem biblioteksrutiner, så det kan MUMPS vel også gøre.

ntet af dette taler i sig selv imod at bruge det - men det skal da overvejes og vurderes og holdes op imod et moderne sprog med masser af konsulenter og erfaring... men med mindre domæneviden og mindre specialiceret sprog.

Konsulenter er ofte overvurderede, og hvis deres erfaring kun bygger på et enkelt programmeringssprog, så bør man ikke hyre dem -- ikke engang til at programmere i det sprog, de kender.

Desuden betyder "moderne" i programmeringsprogssammenhæng ofte bare "langue du jour". Der er f.eks. ikke noget i Ruby og Python, som man ikke har set i andre sprog for 30 år siden.

  • 0
  • 0
#10 Torben Frandsen

Tak for opmærksomheden, PH :-)

Ganske som dig mener jeg at sundheds-it er vigtigt. Meget vigtigt. Derfor bør vi som it-professionelle bidrage med vores viden og erfaring, også uden for de lukkede fora hvor de virkelige beslutninger træffes.

Jeg er ikke enig med dig i at det er en tåbelig detalje, at det er skrevet i MUMPS. Men det behøver heller ikke at være et selvstændigt problem.

Jeg ser to mulige problemer, som, om ikke andet, fortjener en vis opmærksomhed inden man kaster sig ud over Point of No Return. De drejer sig begge om vedligeholdelse. For koden skal vedligeholdes på dansk grund, det er der vist ingen, der kan være i tvivl om.

For det første bør man overveje bemandingsproblemet. Jeg er ikke et sekund i tvivl om, at der i Danmark findes tusinder af udviklere, hvis talent så rigeligt rækker til at lære MUMPS. Men hvor stor er den delmængde, der også gerne vil? Og hvor mange af dem har lyst til at bruge flere år af deres liv på at udvikle og vedligeholde en kompetence, som de kun har ét sted at sælge? Sekundært i denne sammenhæng må man overveje om det er lønsomt at betale det overhead der er, inden alle i truppen taler flydende MUMPS.

For det andet må man tage et alvorligt kig på hvordan kodebasen ser ud. Jeg tror at du og jeg har forskellige erfaringer med legacy-kode. Min erfaring er, at man finder mange uhensigtsmæssigheder fordi det altid er billigere at lave en workaround end at skrive tingene om. Som Torben Mogensen helt korrekt påpeger andetsteds, siger det aktuelle kodeeksempel mere om programmøren end om sproget. Men hvis produktet består at to millioner kodelinjer af den slags, og man gennem 30 år har forlænget verden med brædder og gaffatape, vokser vedligeholdelsesomkostningerne betragteligt fordi hver ændring eller tilføjelse må forudgås af langt mere granskning end ellers.

Med disse flag således hejst er jeg faktisk ganske enig med dig i at man bør give manden en pose penge til at finde ud af om VistA dur til formålet og til at prøve at tilføje en feature eller noget andet, som kan give en realistisk idé om hvordan det er at vedligeholde. Og giv ham ved samme lejlighed en håndfuld kompetente rådgivere, som ikke har penge eller prestige i udsigt ved at råde ham til noget bestemt.

  • 0
  • 0
#12 Torben Frandsen

Konsulenter er ofte overvurderede, og hvis deres erfaring kun bygger på et enkelt programmeringssprog, så bør man ikke hyre dem -- ikke engang til at programmere i det sprog, de kender.

Desuden betyder "moderne" i programmeringsprogssammenhæng ofte bare "langue du jour". Der er f.eks. ikke noget i Ruby og Python, som man ikke har set i andre sprog for 30 år siden.

Jeg tror, det er de færreste af os, der ernærer os som konsulenter, der ikke har prøvet at blive afvist på grund af manglende erfaring med et sprog eller værktøj, som vi ville kunne lære på ret kort tid. Det skyldes ikke manglende erfaring eller økonomisk sans når man jævnligt betaler 10-20% ekstra for konsulenter med erfaring i netop det aktuelle miljø.

  • 0
  • 0
#13 Jan Keller Catalan

Systemet bruges allerede til EPJ og lignende i USA, så jeg [b]vil tro[/b], at man har fundet en løsning på dette. Jeg kan heller ikke se, hvor problemet skulle være: Kommunikation sker [b]i de fleste sprog[/b] gennem biblioteksrutiner, så det kan MUMPS [b]vel også gøre[/b].

(Min fremhævning) Så du er enig i, at det bør undersøges? For en beslutning kan vel ikke tages før man har undersøgt om forventningerne holder stik?

Prøv at kigge på www.thedailywtf.com - specielt den her:

Prøv at læse hele tråden samt diskussionen i http://www.version2.dk/artikel/8238 og du vil se, at det er gennemgået med konklusionen at klytkode kan opstå i ethvert sprog.

Men lad os da se på det:

To give you an idea of what MUMPS is all about, following is an abbreviated list of features pulled straight from the MUMPS FAQ:

CASE SENSITIVITY: Commands and intrinsic functions are case-insensitive. Variable names and labels are case-sensitive.  

Sammenlign med f.eks. PHP - du kan skrive IF eller if, ELSE eller else og PHP er ligeglad. Men skriver du $variablename i stedet for $variableName og du får problemer.

COMMANDS: may be abbreviated to one letter, case-insensitive. Includes commands such as IF, ELSE, GOTO, WRITE, and XECUTE [which is my personal favorite, it allows arbitrary execution of code contained in a variable]

May be... altså ikke nødvendigvis.

OPERATORS: No precedence, executed left to right, parenthesize as desired. 2+3*10 yields 50.

Lidt weird, men paranteser bør efter min mening alligevel benyttes for læsbarhedens skyld

DATA TYPES: one universal datatype, interpreted/converted to string, integer, or floating-point number as context requires.

OK svagt type-sprog

DECLARATIONS: NONE. Everything dynamically created on first reference.

Ja, det kræver så noget koncentration og disciplin fra udviklerne, men formentlig ikke det utroligste, man har oplevet.

LINES: important syntactic entities. Multiple statements per line are idiomatic. Scope of IF and FOR is "remainder of current line."

Næppe den mest praktiske måde, når man er vant til andre programmeringssprog, men kan tillæres.

LOCAL ARRAYS: created dynamically, any number of subscripts, subscripts can be strings or integers. Stored in process space and expire when process terminates.

Forskelligt fra PHP o.lign.?

GLOBAL ARRAYS: arrays that start with a caret symbol. Stored on disk, available to all processes, persist when process terminates. This is M's main "database" mechanism.

Alright, interessante race-conditions, bør nok håndteres 'with great care'

Keep in mind that MUMPS is not one of those esoteric joke languages. It should be, but it isn’t. MUMPS is very real, and has been used for the past thirty years to create and maintain colossal medical information systems.

Jeg synes ikke, det lyder helt SÅ forfærdeligt. Det har sine quirks og er nok en del forskelligt fra andre sprogs syntax, men der må jo være en grund til at det bliver brugt så meget i specielt medicinske systemer.

Men jeg synes stadigvæk det skal undersøges, om det er praktisk med VistA. Opveje fordele og ulemper op imod hinanden og ende op med en konklusion som siger enten Go eller No-go.

  • 0
  • 0
#14 Thomas Ammitzbøll-Bach

Jeg læser også tdwtf, men jeg bruger det altså ikke til at afgøre, hvilket system er bedst til EPJ. Og inden vi vælter bagover, så er her lige et par pointer:

CASE SENSITIVITY: Commands and intrinsic functions are case-insensitive. Variable names and labels are case-sensitive.

Sådan er det også i SQL: Nøgleord er versalrobuste og symboler er (delvist) versalafhængige.

COMMANDS: may be abbreviated to one letter, case-insensitive. Includes commands such as IF, ELSE, GOTO, WRITE, and XECUTE [which is my personal favorite, it allows arbitrary execution of code contained in a variable]

PHK har allerede forklaret det.

OPERATORS: No precedence, executed left to right, parenthesize as desired. 2+3*10 yields 50.

Det gør den gennemsnitslige lommeregner også. Man skal bare vide det. Hvis det er et problem, så er problemet faktisk infix-notationen som sådan, der er problemet. (Jeg møder faktisk mange, der famler rundt i Cs præcendensregler, og har et fast bogmærke i K&R på side 53.) En mere robust notation er OPN.

DATA TYPES: one universal datatype, interpreted/converted to string, integer, or floating-point number as context requires.

Mange sprog har dynamiske typer og foretager konvertering på stedet.

DECLARATIONS: NONE. Everything dynamically created on first reference.

Meget almindeligt.

LINES: important syntactic entities. Multiple statements per line are idiomatic. Scope of IF and FOR is "remainder of current line."

Ku' være bedre, men ku' sagtens være værre...

LOCAL ARRAYS: created dynamically, any number of subscripts, subscripts can be strings or integers. Stored in process space and expire when process terminates.

Det hedder en dictionary, hashtabel eller array med frie indeks. Findes i Python, Perl, awk og PostScript.

GLOBAL ARRAYS: arrays that start with a caret symbol. Stored on disk, available to all processes, persist when process terminates. This is M's main "database" mechanism.

Indbygget database. Er det dårligt?

MUMPS kunne da sagtens være bedre, og det ville ikke være mit første valg, men nogle af os har da oplevet sprog, der var værre.

  • 0
  • 0
#16 Søren Hilmer

Jeg var vist den første, som påpegede at MUMPS kunne være et problem.

Grunden var egentlig, at jeg blev lidt ærgerlig. Jeg så, at man ville prøve at kigge på noget OpenSource EPJ, og tænkte super, det vil jeg da se om jeg kan bidrage til, så derfor undersøgte jeg, hvad det var skrevet i, et sprog jeg ikke kendte (fint nok, jeg elsker at lære nye sprog, Erlang, Scala,...), men da jeg kiggede lidt nærmere på, hvilken slags sprog der var tale om, så neeej, det er livet vist for kort til.

Jeg har på det seneste lært mig selv lidt COBOL, og disse gamle sprog er altså efter min mening, lige trælse nok at arbejde med. Jeg kunne heller ikke finde på at skrive kode i BASIC længere, den tid er forbi.

  • 0
  • 0
#17 Henrik Schmidt

De fleste af jer overser stadig, at der allerede findes adskillige MUMPS/M-baserede systemer i produktion i det danske hospitalsvæsen i dag, og har været det i årevis. Det eneste nye ved VistA, set fra hospitalssiden er, at det er Open Source.

De systemer, jeg selv kender til, er closed source, men til gengæld udviklet i [Danmark|Skandinavien], ikke af amerikanske udviklere. At man ikke har hørt om MUMPS/M betyder ikke, at det ikke eksisterer, men bare, at man måske ikke kender så meget til specialiseret hospitals-IT.

  • 0
  • 0
#19 Brian Palmund

Både H|S og statens serum institut anvender laboratorie systemer der er baseret på Caché/MUMPS.

Vi har lavet et datawarehouse til SSI der ligeledes baserer sig på Caché/MUMPS.

Halvdelen af alt det udstyr der står rundt omkring på hospitalerne og laboratorierne har MUMPS inde i maven. Du hører bare ikke om det fordi det altid bare virker.

Glem diskussonen om problemerne ved MUMPS, jovist der skal bruges rigtige udviklere (ikke en der bare har hygget sig lidt med VB). Det væsentligste er at der implementeret understøttelse for alle mulige internationale standarder (HL7, PACS, Integration til udstyr, osv. osv.) såvel som (i VistA) alle tænkelige forretnings processer (Hvor Danmark dog har valgt at gøre det anderledes fra resten af verdenen)

Caché som vi primært anvender er et fuldt objekt orienteret udviklingsmiljø, som via MUMPS kompilerer direkte ned til den aktuelle hardware, hvor java kun oversætter til bytekode som ikke er optimeret til noget som helst. Det betyder at programmerne er hjerne hurtige og afvikles meget stabilt, hvilket er et forretningsmæssigt must i sundheds it.

Med venlig hilsen Brian Palmund CEO Resulture

  • 0
  • 0
#21 Jan Keller Catalan

Rart at få lidt mere information, Brian, tak for det. Det lyder jo unægtelig noget mere interessant og brugbart end først antaget.

Min kommentar til Henrik Schmidt om

Muligvis, kan du pege på hvor vi har overset det?

Var mest som svar til at vi har [i]overset[/i] en masse anvendelser - for at overse noget kræves at man har været indenfor synsvidde af det.

Giv endelig mere dokumentation om MUMPS' fortræffeligheder og anvendelser :-)

Er der også nogen, der kan give noget indsigt i hvordan de danske arbejdsgange er anderledes end i udlandet?

  • 0
  • 0
#22 Torben Frandsen

Brian,

Mange tak for et indlæg, som kvalificerer debatten mere end hvad Google et al. kan gøre for PH og os dødelige på et kvarter.

Glem diskussonen om problemerne ved MUMPS, jovist der skal bruges rigtige udviklere (ikke en der bare har hygget sig lidt med VB).

For mit vedkommende var den primære bekymring ikke så meget det tekniske ved sproget. Der findes mange andre sprog, som har deres berettigelser selv om de fra en udviklerbetragtning er afskyelige - tag fx de forskellige sprog der anvendes i diverse ERP-systemer.

Nu lyder det jo så til, at der faktisk findes kvalificerede MUMPS-programmører i Danmark. Jeg kunne rigtig godt tænke mig at vide cirka hvor mange der findes i Danmark netop nu, som både kan og vil (husk at regne konkurrenternes folk med (hvis I da har konkurrenter.))

  • 0
  • 0
#24 Jan Vennike

KLASK - ikke een så den smiley jeg sendte efter min tekst, men punkede mig med det samme.

Min dybeste respekt til dem der kan arbejde i MUMPS eller lignende sprog - vi andre har det godt nok nemt i .NET verdenen i sammenligning med de stakkels MUMPS programmører.

  • 0
  • 0
#25 Michael Rasmussen

vi andre har det godt nok nemt i .NET verdenen i sammenligning med de stakkels MUMPS programmører

Det er da vist et udsagn grebet ud af den blå luft!

Skulle et tilsvarende stort system implementeres i .NET, er jeg overbevist om, at de "stakkels" .NET programmører ville få lige så store problemkomplekser, som de "stakkels" MUMPS programmører:-)

  • 0
  • 0
#26 Jørgen Henningsen

Det fungere jo ikke. Jeg kan da godt forstå at lægerne ikke kan arbejde med std. PC'er. De er jo en formiddag om at starte/logge ind og sommetider går det rent galt. Da jeg f.eks. skulle tænde PC'en på arbejde i morges, så hang den bare i noget med nogle personlige indstillinger. Det var noget med en router, som var gået i knæ. Jeg fik først min PC op og spille da jeg fysisk pillede netværket fra. Går det på et sygehus??? Nej vel! Så jeg er enig med koret. Prøv det! Traditionel IT er simpelthen ikke egnet/moden til et sygehus. Vi andre har bare lært at leve med skidtet.

  • 0
  • 0
#27 Morten Kristoffer Hansen

Men PHK har helt ret i mindst én ting: giv IT-chefen for Bispebjerg Hospital en lille pose penge, så han kan teste systemet.

Det er vi i Videnscenter for Software også enige i, hvorfor vi har støttet projektet med halvdelen af de budgetterede midler. Projektet kan findes på Softwarebørsen: http://www.softwareborsen.dk/projekter/softwarecenter/vista-epj-open-sou... hvor man bl.a. kan finde referencer til information om de resultater, der er opnået med VistA.

Med venlig hilsen

Morten Kristoffer Hansen Videnscenter for Software, IT- og Telestyrelsen

  • 0
  • 0
#28 Jarnis Bertelsen

Caché som vi primært anvender er et fuldt objekt orienteret udviklingsmiljø, som via MUMPS kompilerer direkte ned til den aktuelle hardware

Skal det forståes sådan, at programmerne skrives objectorienteret og oversættes automatisk til process-orienteret kode, som så kompileres til maskinkode?

  • 0
  • 0
#29 Henrik Schmidt

Muligvis, kan du pege på hvor vi har overset det?

Okay, overset som i "ved ikke at...". Diskussionen baserer sig meget på, at folk har den opfattelse, at MUMPS-systemer er noget helt nyt og ukendt i Danmark. Som Brian Palmund så glimrende påpeget, er dette ikke tilfældet.

  • 0
  • 0
#30 Henrik Schmidt

Både H|S og statens serum institut anvender laboratorie systemer der er baseret på Caché/MUMPS.

Må jeg lige nitpicke lidt, og påpege at H:S (Hovedstadens Sygehusfællesskab) ikke har eksisteret siden 1. januar 2007? De Caché/MUMPS-baserede systemer, som eksisterer i bedste velgående, drives nu af Region Hovedstaden.

  • 0
  • 0
#31 Brian Palmund

Ja, Caché ObjectScript er et objekt orienteret programeringssprog, hvor man beskriver objekterne på almindelig vis og samtidigt kan beskrive relationer, constraints, værdiområder etc, hvorefter at systemet danner de fysiske datamodeller (Globals/SQL Tabeller) og kompilere koden via MUMPS til optimeret maskinkode.

MUMPS er for application serveren/Databasen som Assembler er for almindelige programmer.

Der er gammel kode der er skrevet i ren MUMPS (eller genereret kode der er håndoptimeret) hvor der ikke er så meget hjælp, men der er også stadigt udviklere der programere direkte i ASM eller skriver SQL i hånden, fordi at deres værktøj ikke kan gøre det godt nok selv.

Derudover eksponeres alle klasser som Java og C++ klasser med automatisk persistens og er automatisk webservice enabled.

Med venlig hilsen Brian Palmund CEO Resulture

  • 0
  • 0
#32 Brian Palmund

"Må jeg lige nitpicke lidt, og påpege at H:S (Hovedstadens Sygehusfællesskab) ikke har eksisteret siden 1. januar 2007? De Caché/MUMPS-baserede systemer, som eksisterer i bedste velgående, drives nu af Region Hovedstaden"

Der var jeg vist lige hurtig/langsom nok :)

  • 0
  • 0
#33 Brian Palmund

Kære Poul-Henning,

Jeg takker for invitationen om at skrive et gæsteindlæg, men da jeg primært forholder mig til de forretninsmæssige aspekter mener jeg ikke at jeg er kvalificeret til at leverer en præsentation der matcher denne blogs forventninger til teknik...

Jeg vil derimod gerne henvise til følgende præsentation der prøver at forklare hvilke udfordringer som dagens systemer står overfor og hvorfor mumps har en berettigelse. http://www.outoftheslipstream.com/node/124

Mvh Brian Palmund CEO Resulture

  • 0
  • 0
Log ind eller Opret konto for at kommentere