FMK Teknik

Er vi ikke blevet lovet at triforkfaellestest altid har seneste takst?

/pds

At det ville være meget ønskelig at man kunne oprette/vedligeholde assistenter. Der er da et lille skridt i den rigtige retning at man kan forspørge om en given bruger har de rettigheder man forventer, frem for at ende med at lave kald som bliver afvist med en kryptisk meddelelse.

Det er dog med glæde at der bliver blødt op for hvem der har skrive rettigheder, og det kan vel næppe gå for stærkt for at få det i drift, også selvom det måske betyder at vi skal op 1.2.4 eller direkte til 1.2.6.

Det er lykkedes nogen at oprette uden en IndicationStructure (er mit gæt, se fejl herunder)

Er det en fejl der oprettet i JIRA?

Er det muligt at få fjernet/rettet den fejlende ordination?


</soapenv:Envelope><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:medcom="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" id="Envelope">
  <soapenv:Header>
    <mc:stack xmlns:mc="http://www.dkma.dk/medicinecard/xml.schema/2009/01/01">dk.medicinkortet.exceptions.SchemaValidationException: Skemavalideringsfejl cvc-complex-type.2.4.a: Invalid content was found starting with element 'mc2008:RouteOfAdministrationStructure'. One of '{"http://www.dkma.dk/medicinecard/xml.schema/2009/01/01":IndicationStructure}' is expected.
   at dk.medicinkortet.ws.validator.ValidationSender.invoke(ValidationSender.java:38)
   at org.apache.axis2.engine.Phase.invoke(Phase.java:292)
   at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:212)
   at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:377)
   at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:45)
   at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:96)
   at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:145)
   at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
   at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:120)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
   at com.trifork.eas.web.container.p.doService(&lt;obfuscated&gt;:357)
   at com.trifork.eas.web.container.p$a.doFilter(&lt;obfuscated&gt;:401)
   at dk.medicinkortet.filter.RequestLogFilter.doFilterInternal(RequestLogFilter.java:64)
   at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
   at com.trifork.eas.web.container.p$a.doFilter(&lt;obfuscated&gt;:399)
   at com.trifork.eas.web.container.p.forward(&lt;obfuscated&gt;:156)
   at com.trifork.eas.web.container.p.run(&lt;obfuscated&gt;:83)
   at com.trifork.eas.web.container.HttpServletRequestImpl$a.run(&lt;obfuscated&gt;:706)
   at java.security.AccessController.doPrivileged(Native Method)
   at com.trifork.eas.web.container.HttpServletRequestImpl.service(&lt;obfuscated&gt;:725)
   at com.trifork.eas.web.container.ReflectiveWebContainer$d.invoke(&lt;obfuscated&gt;:1094)
   at com.trifork.eas.web.container.ReflectiveWebContainer.handleRequest(&lt;obfuscated&gt;:1128)
   at com.trifork.eas.web.container.ReflectiveWebContainer.access$0(&lt;obfuscated&gt;:1103)
   at com.trifork.eas.web.container.ReflectiveWebContainer$a.service(&lt;obfuscated&gt;:112)
   at com.trifork.eas.http.o.processRequest(&lt;obfuscated&gt;:230)
   at com.trifork.eas.http.a.connectionEstablished(&lt;obfuscated&gt;:236)
   at com.trifork.eas.http.o.connectionEstablished(&lt;obfuscated&gt;:67)
   at com.trifork.eas.tcp.a.connectionEstablished(&lt;obfuscated&gt;:232)
   at com.trifork.eas.tcp.a$a.execute(&lt;obfuscated&gt;:222)
   at com.trifork.eas.threadpool.b.performWork(&lt;obfuscated&gt;:174)
   at com.trifork.eas.threadpool.b.run(&lt;obfuscated&gt;:128)
   at com.trifork.eas.threadpool.b$b.run(&lt;obfuscated&gt;:206)
</mc:stack>
    <wsse:Security>
      <wsu:Timestamp>
        <wsu:Created>2011-12-14T11:21:01Z</wsu:Created>
      </wsu:Timestamp>
    </wsse:Security>
    <medcom:Header>
      <medcom:SecurityLevel>1</medcom:SecurityLevel>
      <medcom:Linking>
        <medcom:FlowID>ba48061c-48c0-4741-87c9-38a7c6ed0548</medcom:FlowID>
        <medcom:MessageID>AAABNDxN1aFJiLrq7SrdIVNPU0k=</medcom:MessageID>
        <medcom:InResponseToMessageID>c6591da6-f3e2-4f60-83fc-4cd58115904b</medcom:InResponseToMessageID>
      </medcom:Linking>
    </medcom:Header>
  </soapenv:Header>
  <soapenv:Body>
    <soapenv:Fault>
      <faultcode>Server</faultcode>
      <detail>
        <medcom:FaultCode>4001</medcom:FaultCode>
      </detail>
      <faultstring>Skemavalideringsfejl cvc-complex-type.2.4.a: Invalid content was found starting with element 'mc2008:RouteOfAdministrationStructure'. One of '{"http://www.dkma.dk/medicinecard/xml.schema/2009/01/01":IndicationStructure}' is expected.</faultstring>
    </soapenv:Fault>
  </soapenv:Body>
</soapenv:Envelope>

Inden jeg opretter dette i JIRA som et ønske, var det måske på sin plads at vende mulighederne her.

Det er først for nyligt gået op for mig at det er muligt for lægerne at slette (eller annullere, jeg kender ikke den direkte term) en aktiv recept på PEM. Med aktiv mener jeg selvfølge en elektronisk (EDI/FMK) recept der ikke er fuldt indløst. Det er endda en funktionalitet som endda ikke er kendt af alle læge, og en udbredelse af dette ville kunne afhjælpe flere uheldige situationer, som allerede har været årsag til mindst én alvorlig UTH.

/pds

• MOCES2 understøttes af Seal.net og Seal.java fra version 2.0 og 2.1, som kan downloades nu.

Jeg kan kun finde:
Seal.java i version 1.5.13 http://digitaliser.dk/group/374971/resources/type/150019
Seal.Net version 2.0.0.4 http://digitaliser.dk/group/375117/resources/type/150019

Jeg bruger ikke java, så den ved jeg intet om, og Seal.Net er ikke mig bekendt officielt blevet opdateret (der er mindst een kendt fejl) de sidste to år.

Så det ville da være rart at vide hvor version 2.1 af disse er at finde.

/pds

Jeg har fået oplyst fra Lægemiddelstyrelsen at en Receptserverrecept (PMO) først slettes to år efter seneste effektuering, dvs. recepter kan teoretisk være op til fire år.

Det ville være interessant med en officiel udmelding om levetiden og reglerne for sletning af LMO'er, for som allerede nævnt, bør dem uden udløb aldrig slettes, uanset om der er en tilknyttet recept eller ej.

/pds