Indfør offentlige straks-betalinger nu!

I dagens Berlingske argumenterer jeg for at offentlige myndigheder bør indføre straks-betalinger i forhold til private leverandører.

Det er beskæmmende, at offentlige myndigheder presser leverandører med en betalingsfrist, som typisk er løbende måned plus 30 dage. Hvad er logikken i, at den store køber, der har likviditet til laveste rente, tvinger leverandører med langt ringere lånevilkår til at yde ekstra kredit? Og har det f.eks. en betydning, at denne part, som har som overordnet formål at skabe vækst og arbejdspladser i Danmark?

Det korte af det lange er, at den offentlige sektor i Danmark har alle forudsætninger for at betale deres leverandører hurtigt. Den offentlige myndighed kan stille krav om at en faktura skal indeholde en reference til et ordre- eller rekvisitionsnummer, og det gør det enkelt at konstatere, om en given faktura vedrører en bestilt (og leveret) vare eller ydelse.

Det virker omsonst, at man fra offentlig side med den ene hånd iværksætter skatteyderbetalte vækst- og støtteordninger, når man samtidig "låner" penge fra de selvsamme virksomheder med den anden hånd.

Gratis e-faktura via NemHandel? Kan det være rigtigt?

Jeg bliver ofte spurgt om det virkeligt kan være rigtigt, at Tradeshift gør det muligt at sende gratis e-faktura til NemHandel. En simpel søgning på nettet om NemHandel returnerer en masse annoncer for tjenester der tilbyder afsendelse til Nemhandel for 2-3 kr pr. faktura. Hvorfor skulle man betale for den slags, hvis der er et gratis alternativ? Og hvis Tradeshift gør det gratis, hvorfor gør vi så ikke mere ud af at fortælle om det?

For at besvare det første spørgsmål. Ja - med Tradeshift er det 100% gratis at sende elektroniske regninger til NemHandel. Hvis ikke din virksomhed befinder sig på C20 indekset eller er blandt verdens 1000 største, så er det faktisk 100% gratis at udveksle regninger med hvem som helst. Det være sig elektronisk eller som en email med vedhæftet PDF. Tanken med Tradeshift er at det skal være muligt at udveksle e-fakturaer og andre forretningsdokumenter med alle kunder og leverandører på en samlet platform.

Kernen i Tradeshift er virksomhedens forretningsnetværk. Man inviterer kunder og leverandører til at blive en del af ens netværk, og så udveksler man dokumenter og status-meddelelser med netværket. Man kan også udveksle dokumenter med kunder der ikke er en del af ens netværk - så sker med med email og PDF.

Når man sender en e-faktura til en kunde på NemHandel, så skal man selv oprette kunden i sit forretningsnetværk, og angive at kunden befinder sig på NemHandel. Det er ret let - se et eksempel på en registrering nedenfor:

Mao. det er super let at sende fakturaer fra Tradeshift - både via NemHandel, via dit forretningsnetværk på Tradeshift og via email.

Det sidste spørgsmål er så, hvorfor vi ikke gør mere ud af at fortælle om alt det vi kan omkring NemHandel?

Vi har selv været en central del af indførslen af elektronisk fakturering i Danmark. Jeg stod mere eller mindre alene med tilretningen af alle de tekniske standarder (OIOXML) tilbage i 2004, da det hele skulle på plads. Det var undertegnede og Christian Lanng, der i foråret 2005 skrev det første notat om visionen for det, som vi i dag kender som NemHandel. Og hele arkitekturen for NemHandel blev lavet i juleferien 2005.

Den korte forklaring er, at vi har "sejret af helvede til". Danmark er et foregangsland hvad angår udrulningen af elektronisk fakturering til offentlige myndigheder. Nu er det den private sektor der skal høste fordelene, og der har vi valgt at satse på nogle af verdens største virksomheder. Dem er der også nogle stykker af i Danmark, og vi er stolte af at være leverandører til flere af dem. Men mange af denne type virksomheders leverandører befinder sig i udlandet, og Tradeshift er en global platform med brugere i over 190 lande. Det betyder at vores marketingsindsats er rettet mod et globalt marked af store virksomheder og deres underleverandører, og det er årsagen til at vi ikke gør et særligt nummer ud af vores understøttelse for NemHandel, som i bund og grund er et dansk fænomen.

Men fortvivl ikke - Danmark er på rette kurs med OIOUBL og deltagelsen i PEPPOL-projektet, som forbinder Danmark med resten af Europa i en fælles infrastruktur. Vi ser frem til at hjælpe endnu flere danske virksomheder med at høste fordelene ved elektronisk fakturering og tættere relationer med kunder og leverandører.

Why the OASIS Business Document Exchange TC is important for the future of e-business

Exchange of most business documents still happens on paper. Why is it that we in 2011 after several decades of use of advanced ERP solutions and PC’s at everyone’s desk still use paper as a medium to carry data between IT systems in different organizations?

The answer is simple:

We use paper as a medium to carry data between IT-systems in different organizations because we have still not solved the interoperability problem between service providers. And there are several layers of interoperability that we must address:

• Organizational interoperability: Alignment of business processes and business models 
• Legal interoperability: Alignment of legislative frameworks ensures a level legal playing field 
• Semantic interoperability: The content and semantic meaning of business documents 
• Technical interoperability: Transport protocols, security, trust 

But one may argue that we have interoperable answers for each of the interoperability layers. E.g. the OASIS UBL TC has standardized semantic interoperability for a number of business documents. The CEN WS BII has standardized a number of business processes describing the exchange of UBL documents. The ebXML framework has provided technical interoperability with ebMS and a whole framework for entering bilateral exchange agreements.

This is all good - but it is not a complete solution! No single framework has described interoperability across all layers where different service providers acts as intermediaries between businesses (the four-corner-model).

And the SMTP/Email model does not work when it comes to real e-business with exchange of business documents carrying real value. Elements like trust mechanisms, addressing mechanisms, security in transport and non-repudiation becomes very important when we exchange confidential business data.

The OASIS Business Document Exchange (BDX) TC aims to specify the remaining pieces in the four-corner-model.

• Establishing trust between service providers 
• Addressing recipients and their capabilities between service providers 
• Secure and reliable transport between service providers 
• Secure and reliable transport between a service provider and an end customer 

The vision of the BDX TC is that one or more global instances of service provider networks built on the BDX specifications will evolve. This would allow a seller in the US to receive a purchase order and return an invoice to the corresponding buyer in Spain. It would be sufficient for the buyer and seller to be connected to independent service providers. The service provider may never have exchange business documents between each other before but the exchange will still go through.

If you can recognize some of these challenges and would like to contribute to the solution – then I encourage you to join the BDX TC. Lets solve this now – once and for all.

Mikkel Hippe Brun
Chair, OASIS BDX TC

CSO & Co-founder, Tradeshift

Updates on OB10 US patent - Current status

Resume

OB10 has applied for a US patent (which is currently being examined) and has received a European patent on an "Communication routing apparatus". The original application was filed in the US on December 3rd 2001 and the European patent was granted on October 29th 2008 by the European Patent Office (EPO). There is however a 9 months period where a "Notice of opposition" can be sent to EPO (i.e. by the end of July 2009).


The US patent describes a middleware product (e.g. an ESB) where the ESB acts as an intermediary messaging hub between many IT-systems. It basically describes how electronic invoices received from multiple sources and in multiple formats are converted into a standardized format. Finaly the invoices are converted into the desired format of the intended receivers (multiple formats). Static and dynamic data is added in the conversion process to the standardized format.


Current status of US patent
The transaction history for the patent application is made available by the United States Patent and Trademark Office on the PAIR system (Patent Application Information Retrieval - Search for Application number 10/006267).





The transaction history shows that the patent was rejected on October 30th 2008. New arguments/remarks were received on March 17th 2009 along with amendments to claim 18 and claim 48). The patent was then forwarded to an examiner on May 19th 2009 and I assume that it is still under examination.

Amended claims
OB10 has amended text to two claims in the application (see latest version as of March 17th 2009 here):

18.(Currently Amended) An invoice routing apparatus comprising:

• an invoice receiver for receiving data corresponding to a plurality of invoices from a plurality of sources;
• a database for storing input invoice mapping definitions;
• an input processor device for processing the data corresponding to the plurality of received invoices within said invoice routing apparatus, the data for each invoice being converted by said input processor into an intermediate invoice in a standard intermediate form having predetermined characteristics and to provide the intermediate invoice in a data warehouse; the input processor configured to select an invoice mapping definition from the database in dependence on the sender of each received invoice and using the selected input invoice mapping definition when converting said data for the received invoice into said intermediate invoice;
• an output processor device configured to convert each of said intermediate form invoices obtained from the data warehouse into a final invoice in a form selected in dependence on an identity of a party being invoiced, the output processor obtaining an invoice destination identification from each intermediate invoice and selecting an output invoice mapping definition in dependence on the invoice destination identification; and
• an invoice transmitter device for transmitting each of the final invoices from said invoice routing apparatus to the party being invoiced;
• said input processor device further being configured to:
• add static data to the data corresponding to the received invoices when processed into said standard intermediate form;
• add dynamic data to the data corresponding to the received invoices when processed into the standard intermediate form; and,
• validate the data corresponding to the received invoices when processed into the standard intermediate form before transmission by said transmitter to the party being invoiced.

48. (Currently Amended) An invoice routing method comprising:

• receiving data corresponding to a plurality of invoices from a plurality of sources;
• storing input invoice mapping definitions;
• providing an input processor device and configuring the input processor device for performing an input processing of the data corresponding to the plurality of received invoices, converting the data for each invoice into an intermediate invoice in a standard intermediate form having predetermined characteristics and providing the intermediate invoice in a data warehouse;
• configuring the input processor device for selecting an invoice mapping definition from the store in dependence on the sender of each received invoice and using the selected input invoice mapping definition when converting said data for the received invoice into said intermediate invoice;
• providing an output processor device and configuring the output processor device for performing an output processing for converting each of said intermediate form invoices obtained from the data warehouse into a final invoice in a form selected in dependence on an identity of a party being invoiced,
• configuring the output processor device for obtaining an invoice destination identification from each intermediate invoice and selecting an output invoice mapping definition in dependence on the invoice destination identification; and
• transmitting each of the final invoices to the party being invoiced;
• said input processing by said input processor device further including:
• adding static data to the data corresponding to the received invoices when processed into said standard intermediate form;
• adding dynamic data to the data corresponding to the received invoices when processed into the standard intermediate form; and,
• validating the data corresponding to the received invoices when processed in the standard intermediate form before transmission to the party being invoiced.

The amended claims above shows that OB10 is trying to patent:

1. A piece of software (an apparatus) used to convert invoices 1) from multiple sources and formats, 2) to a standardized format and 3) finaly converted and delivered to multiple formats and destinations. Such an apparatus is "off the shelf" functionality in many middleware products and was "off the shelf" functionality at the time of application.
2. A business method involving the convertion of invoices 1) from multiple sources and formats, 2) to a standardized format and 3) finaly converted and delivered to multiple formats and destinations. This is a well know business model offered by many service providers and value added network operators prior to the application of the US patent. This business model is today also known as the "Three corner model".

As mentioned in the above: The software functionality (apparatus) and the business method has been described publicly prior to the application of the US patent. (e.g the TradeCard solution - see "Notice of opposition" against OB10's Communication routing apparatus patent)

References

US Patent Claims on a Communication routing apparatus as of March 17th 2009

United States Patent and Trademark Office - USPTO

"Notice of opposition" against OB10's Communication routing apparatus patent

I feel very stongly about the patent OB10 has received on an "Communication routing apparatus". See my previous post on the subject. To me it is like if somone reinvented the weel and then claimed to be the original inventor eventhough everyone else is driving around in cars.

I will keep updating this post with references to examples of common practice and publications dated before the orginal filing of the patent. If you would like to add something to my list please contact me or make a comment.

Protocol conversion has been common practice for 20+ years
We have had Value Added Networks in Denmark for more than 20 years. I have colleagues who have worked there and I know what they did for a living. They were not just network operators - they were value added network operators (VAN). The value add was to connect any customer via any protocol to other customers via any other protocol. (This is the protocol part of the OB10 patent.) They connected businesses and the public sector in b2b, b2g and g2g scenarios. Since way back his was everyday business for several companies providing services to the health sector the automotive industry and in eprocurement. This has been so common that no-one could imagine that someone would take out a patent on this practice.

Expired US Patent 5,708,828 from January 13th 1998 by Coleman [added June 12th 2009]
Coleman got another amazing patent very similar to the OB10 patent. Fortunately this patent has expired due to "NonPayment of Maintenance Fees". The title of the patent is "System for converting data from input data environment using first format to output data environment using second format by executing the associations between their fields". The existance of this patent was used as one of the reasons to reject several claims in the US version of the OB10 patent on October 30th 2008. The exmainer quoted the following lines from Coleman:

"the present invention comprises an improved system and method for converting data between different formats or types. The present invention converts data to a pre-defined generic data object or generic data type and then converts data from this generic type to the new format. This simplifies the conversion process."

The examiner also compared the two illustrations of the patents (see below) and stated that

"Figure 2B clearly discloses applicant's invention as shown below. One can easily see the similarities by the comparison of Figure 1 of the instant invention."

So the Coleman patent has clearly shown the USPTO and the EPO that the generic protocol and content transformation was prior art.

UN/EDIFACT [added June 6th 2009]
Well EDIFACT has been around for several years. Here you can find definitions of EDIFACT messages from 2000. These messages format were used (and are used) by different industries to exchange business business documents in a standardized format. The VAN operator would then as a value added service offer to do content conversions from and to various customer formats. To do such conversions would most often be the rule rather than the exception. There were many advantages to this approach for the customer: 1) Version changes in the standardized format would be dealt with by the VAN, 2) The company could out source the conversion and configuration. 3) The company would not have to deal with supporting many different protocols and content formats for all their business partners.

Commerce One and xCBL [added June 6th 2009]
Commerce One was a very successfull company doing business in the area that is described by the patent prior to 2000. Look here at an announcement from December 17 1999, where Commerce One announces an updated version of the XML-based de-facto e-invoicing standard - xCBL. It was made available at a number of repositories - one of them being BizTalk.org operated and owned by Microsoft. BizTalk.org was the home of a number of XML Schemas for different purposes and BizTalk was a middleware product that could do (gues what) protocol conversion and content conversion. The same was the case for the Commerce One products I believe. The characteristics of the OB10 patent are that static and dynamic data is added to the input protocol and the input content. But there is nothing novel to that. It is part of what you would have to do for this setup (see illustration) to work.

The illustration above was found on the Internet Archive Wayback Machine from May 2000.


The method of cross-translation with OmniMark [added June 8th 2009]
OmniMark from Stilo is a pearl-like language used to do content transformations. I has around since the late eighties and was in the beginning used by CD-ROM developers, technical documentation experts and CD-ROM publishers [Source: Omnimark at Work: Getting Started, Architag Press, 1997]. OmniMark supports (and supported) a content transformation model called cross-translation, which is a combination of an up-tranlation and a down-translation. The idea of a cross-translation is that you can set up a number of up-translations from various formats to a standardized format (could be SGML or XML). The tool makes it relatively easy to do such transformations from unstructured or structured data because you are guided by the DTD or the XML-Schema. The second part of the cross-translation is to do a down-translation to one or more output formats. To add static data to this process is a no-brainer (this is specific to the European patent). See also the Guide to OmniMark 5.0 from 2000

OmniMark also had the capability to send and receive data on different transport protocols. What protocols that were available in 2000 could be further. Anyway - the book about OmniMark programming cited above clearly shows that the described method of content conversions were common knowledge as early as 1997, and thus does not deserve to be part of a patent in 2000. I am furthermore confident that service providers / value added network providers used OmniMark in 2000 to support thier business.

The TradeCard Solution described publicly in October 2000 [added June 10th 2009]
TradeCard provides hosted technology, online services connecting buyers, suppliers and their service providers. In October 2000 TradeCard published a Technical Overview of their platform. Here are som quotes from the Technical Overview:

XML provides the TradeCard system with a mechanism for translating and integrating business data from disparate systems. Thus, TradeCard can ensure the free exchange of business documents, regardless of format or application.
...
Translation Services
All business documents are stored as XML within the TradeCard system. The TradeCard Messaging Infrastructure makes it possible to have multiple data formats within a single business transaction. For example, a seller may upload an invoice from an automated supply chain system directly into the TradeCard system. Then the buyer may view the invoice in HTML via a web browser. A freight forwarder may send the advance shipping notice in EDI format. All of these document types are stored internally in the TradeCard system as XML. Yet externally, the customers of TradeCard are not required to have XML compliant interfaces on their systems.
...
Message Broker
The web browser is only one of many methods that can be utilized to access the TradeCard system. All non-browser access to TradeCard is achieved by messaging. Messages are delivered in a variety of mediums and formats including SMTP, FTP, EDI, and custom formats. The TradeCard Messaging Infrastructure converts the messages to TradeCard XML formats. Message queuing services are provided by IBM MQSeries.

The Technical Overview clearly shows that the "invention" that was claimed by OB10 had indeed already been implemented and described by TradeCard and others in the industry. The European patent contains added characteristics describing how static and dynamic data is added to the input protocol and the input content (also mentioned earlier). These characteristics are not described in the TradeCard Technical Overview, but there is no invention in adding static and dynamic data. You cannot do protocol conversions without adding dynamic data and unfolding keys to static data (e.g. an address) is trivial and is also an implicit and trivial feature of middleware poducts like the IBM MQSeries used in the TradeCard solution.


References
EDIFACT on Wikipedia
Internet Archive Wayback Machine
Omnimark at Work: Getting Started, Architag Press, 1997
TradeCard Technical Overview

OB10 patent on ESB middleware and VANs pattern?

OB10 has received a patent on an "Communication routing apparatus" by the European Patent Office (EPO). The original application was filed on December 3rd 2001 and the European patent was granted on October 29th 2008. There is however a 9 months period where a "Notice of opposition" can be sent to EPO (i.e. by the end of July 2009).

An attempt to patent an old pattern known from middleware products and VANs
The patent describes a middleware product (e.g. an ESB) where the ESB acts as an intermediary messaging hub between many IT-systems. It basically describes protocol conversion and content conversion between 1) senders 2) the hub and 3) receivers.

[Note on June 5th 2009: This is my interpretation of the patent and I have tried to describe the patent with a more familiar terminology. I have however been corrected today by a patent attorney. The characteristics of the patent are that static and dynamic data is added to the input protocol and the input content (see added text below in italic). But really - there is nothing to it - and in my mind this does not change anything. This was apparently added to the European patent because the first description was found to be known by EPO. So please be aware that there is a difference in the text between the US patent and the European patent! You should go to the source for an authoritative description.]

1. Data can be received by a hub from different IT-systems (senders) on many different transport protocols. (The patent describes an external system producing an electronic invoice as an example of it's use). A new input transport protocol only needs to be added once. Several input systems can use the same transport protocol but could also use different protocols. [Added June 5th 2009: Dynamic data is added to the input signal. In other words the hub creates a new envelope for the data with "transaction code, a transaction id and the mapping definition used". Nothing new here - you need an envelope so you need to do that!]


2. Data is then converted to an intermediate form (by the hub). It is described how the original invoice in one format is transformed to a neutral invoice format by the middleware product. This could for instance be the upcoming Cross Industry Invoice from UN/CEFACT or Universal Business Language from OASIS. [Added June 5th 2009: Static data is added to the data. E.g. name and address of the source of the invoice. Again it is quite common to unfold information from a key. If an input invoice only has a supplier identifier then you should insert the name and the address of the source.]


3. The next step is that the data is converted from the neutral format to the desired format of the receiver. (e.g. this could be a conversion from the Cross Industry Invoice to the SAP idoc format).


4. Finally the data is sent to the receiver on a transport protocol supported by the receiver. New transport protocols only needs to be implemented once in the system.

I my view this is standard functionality in many middleware products and most ESB's. I also believe that the described pattern of transformations of protocols and content describes exactly what Value Added Network Operators has been making a business on for the last 20+ years. The "VA" (Value Added) in the VAN acronym - is to do transformations on protocols and contents like it is described in the patent.

One of the inventors is also advisor to an EC expert group on e-invoicing
One of the inventors of the patent, Stefan Foryszewski, is also advisor to the European Commission's Expert Group on Electronic Invoicing. The group was formed in November 2007 with the task to establish a European Electronic Invoicing Framework by 2009. The purpose of the expert group is defined here:

"By Decision 2007/717/EC, the Commission has set up an Expert Group on electronic invoicing (e-Invoicing). The tasks of this Group will be to identify the business requirements, to allocate responsibilities for the execution of specific work and to propose the necessary steps for the creation of the European e-Invoicing Framework. This framework is to establish a common conceptual structure to support the provision of e-Invoicing services in an open and interoperable manner across Europe." Source: Original call for applications

"The (purpose of the) European e-Invoicing Framework is to establish a common conceptual structure, including business requirements and standard(s), and propose solutions supporting the provision of e-Invoicing services in an open and interoperable manner across Europe." Source: Mid-Term Report of the European Commission Expert Group on e-Invoicing

The original call does not require the applicant to sign a "patent non-assert agreement" nor does it require the applicant to inform about patent rights that might be covered by the work. This should perhaps be the case with future expert groups?

I asked Stefan Foryszewski the following questions in an email on May 25th 2009 but have (so far) not received any answer:

"Dear Stefan Foryszewski,

I write to you in my role as Technical Director in the PEPPOL project. I have some questions regarding the OB10 Patent on a "Communication routing apparatus" submitted by yourself and some colleagues (http://bit.ly/Kh95m). There is only a few weeks to make objections to the patent and I want to make sure that I understand the implications that the patent has on the Framework for Interoperability and existing Value Added Network operators and other service providers.

Can you please explain how an FFI compliant instance (e.g. PEPPOL) would be (or would not be) affected by the patent? Such a framework would have a standardized format for e-Invoices (e.g. CEN/ISSS BII in UNCEFACT CII syntax or OASIS UBL syntax) and transformations between this format and other invoice formats would be the norm for most service providers. The same would be the case for the transport standards. Is this not exactly what you are describing in your patent? How do you intend to enforce your patent? Are you just protecting a pattern that can be used freely by anyone?

My personal opinion is that the patent is describing an already established pattern for exchanging and transforming e-Invoices. (Event at the time of filing in 2001).

Best regards
Mikkel Hippe Brun"

Possible threat to global e-invoicing

Electronic invoices are specifically mentioned in the patent, but other types of business documents are also covered. I am neither a developer of middleware products nor a Value Added Network operator / Service Provider. I am however the technical director of the PEPPOL project (Pan European Public Procurement Online) which is an ambitious European e-procurement infrastructure. I do not see the patent as a direct threat to the PEPPOL infrastructure. But it is (in my mind) a direct threat to the service providers connecting to the infrastructure and the middleware products used to making it possible.

It all depends on whether service providers and suppliers of middleware products will oppose the patent and whether OB10 will seek licenses for the use of its patent.

I urge suppliers of Middleware products and service providers to send an opposition to the patent. This could hit you hard! I have been told that an opposition has to be made for each individual country covered by the patent, so it is not a trivial task lying in front of us. [Added June 8th 2009 - I have made a new blogpost where I am collecting evidence that could be used for an opposition.]

Appeal to OB10
So my appeal to OB10 is to quickly come up with a "patent non-assert statement". There is a saying that if you are not part of the solution then you are part of the problem. Private companies and government institutions will have to spend lots of time and money to oppose your patent. It does not bring us anywhere and it confirms the impression that more government regulation is needed. You are putting yourself in a delicate position and you are not helping the industry. Save us that burden NOW! Participate in the expert group and let us change the landscape of global electronic invoicing. There are 25 million SME's in Europe that will be participating in electronic business processes within the next 10 years. Let us help each other to get them "connected". There is so much money to be saved and and also a lot of money to be made. Let us not delay this for one second.

Links:

Patent: "Communication routing apparatus" on European Patent Office homepage

Latest version of amended US patent as of March 17th 2009

Direct link to PDF of patent on "Communication routing apparatus" where information about the 9 months "opposition period" can be seen at the bottom. For some reason it is just the first page you get in the PDF.
Full text of European patent

Patent: "Communication routing apparatus" on Google Patent Search homepage. Observe: US patent text - not European.

European Patent Office (EPO)

EPO Notice of opposition

30 minutters daglig spildtid med login

Politiken bragte i dag et par spændende artikler med overskriften "Læger: Vi spilder tiden på it-bøvl" og "Den elektroniske tidsrøver". Artiklerne er skrevet af Line Prasz og Marie Louise Sjølie, og fortæller historien om hvordan indførslen af EPJ (elektroniske patientjournaler) har betydet at læger og sygeplejersker nu bruger uforholdsmæssigt meget tid på at skrive login og password og vente på at EPJ-systemet bliver klar. Ifølge artiklen er alle enige om at EPJ er vejen frem, men i praksis har indførslen af EPJ betydet en mere presset arbejdsdag eller at man ikke kan behandle det samme antal patienter. Hjertelæger på Gentofte hospital har opgjort deres daglige spildtid i forbindelse med login til 30 minutter om dagen.

Artiklen giver stof til eftertanke og bekræfter gammel viden omkring brugerinddragelse. Der hersker næppe nogen tvivl om at brugerne har været inddraget i udviklingen af EPJ-systemerne, men på trods af brugerinddragelsen er man ikke endt med et system, hvor kunderne langt fra tilfredse med de praktiske erfaringer. I denne blog vil jeg udfra en teknisk synsvinkel kommenterer på 2 af de områder, som fremhæves i artiklerne:

1. Brugerne skal konstant logge sig på systemet, og det tager tid før systemet er klar til brug.
   
2. Selv simple handlinger som fx at ordinere medicin kræver mange klik med musen.

Problemet med gentagne login
At lægerne konstant skal logge sig på systemet, skyldes kravene til sikkerhed. Der skal være sporbarhed i hvem der fremsøger hvilke data og det skal sikres at brugerne kun kan tilgå de informationer, som de er autoriserede til at tilgå. Uvedkommende må med andre ord ikke kunne tilgå personfølsomme oplysninger. Disse krav kan understøttes på mange forskellige måder.

Traditionelt håndteres sikkerheden ved at brugerne manuelt skal logge sig på deres system ved at taste brugernavn og kodeord. Tilsvarende, at hvis en computer har stået ubenytted hen et vist stykke tid, så bliver den sidste bruger automatisk logget af systemet. I artiklen beskrives det hvordan personalet flytter sig mellem forskellige computere, og derfor konstant skal logge sig på. Det giver sig selv, at ovenstående ikke er tilfredsstillende når der er travlhed på en afdeling.

Spørgsmålet er så, hvad man kan gøre for at opfylde de samme krav til sikkerhed og sporbarhed, men samtidig gøre det hurtigere for personalet at udføre deres arbejde? Fx kunne man gøre forsøg med brugen af RFID-chips eller lignende teknologier. Der findes eksempler på afdelinger, hvor man i dag overvåger personalets bevægelser for at sikre at de rigtige ressourcer er tilrådighed til operationer. Den samme teknik kunne bruges til at forberede evt. brugerinteraktion ved en computer. Man kunne forestille sig, at hvis sundhedsfagligt personale kommer i nærheden af udvalgte computere, så ville systemet automatisk hente brugerens seneste session ind i hukommelsen for det tilfælde at brugeren satte sig foran computeren. Forskellige grader af nærhed i forhold til computere kan derfor være styrende for om computeren blot forebereder evt. interaktion eller om skæmen decideret skifter til direkte interaktion. Når brugeren kommer helt tæt på er der måske kun behov for at indtaste kodeord eller aflæse fx et fingerafktryk for at brugeren kan få adgang til sin seneste session.

Hvis alle bevægelser i en hel afdeling overvåges, så er et er mit bud, at det er tilstrækkeligt, at brugerne autentificeres når de møder på arbejde. Dvs. at systemet aflæser en RFID-chip og at brugeren indtaster sit kodeord. Herefter er det alene et spørgsmål om at registrere, hvem der gør hvad på systemet. Et rimeligt krav ville så være, at skal autentificeres igen, hvis brugeren forlader det overvågede område og kommer tilbage igen.

Problemet med at selv simple ting bliver besværlige
I forhold til artiklens beskrivelse af hvordan en simpel ordination af medicin, også giver anledning til en langsommelig registrering, kunne det også være interessant at eksperimentere med RFID-chips. Hvis patienterne også var udstyrede med RFID-chips i deres "armbånd", ville det være muligt at hente deres journaler frem i takt med at lægen gik sin stuegang. Der ville dermed ikke være tale om et scenarie, hvor lægen først skal hente journalen frem ved sengekanten ved at indtaste et CPR-nummer, og derefter navigere frem til en elektronisk recept. Med "intelligente" systemer, som automatisk "forbereder" de mest sandsynlige handlemønstre fra brugeren, er det sandsynligt, at man kan skære en væsentlig del af ventetiden væk ved mange af de hyppigt forekommende handlinger.

Ubiquitous computing
De teknologier som kan realisere ovenstående kaldes for "Ubiquitous computing" (computerkraft i alt). I lande som Japan og Sydkorea er der afsat enorme forskningsbudgetter i forhold til udforske området. Feltet er ikke særligt synligt forskningsmæssigt i Danmark. Eksemplerne fra EPJ viser, at der er enorme effektiviseringspotentialer at hente, hvis man kan reducere spildtiden omkring fagsystemerne. Man må derfor håbe, at de første forsøg med teknikkerne i forhold til EPJ-feltet allerede er under udforskning i Danmark. Det kan kun gå for stærkt.