Fundamentally the current FreeB suffers from several design decisions which in my opinion just didn't pan out, was a great leap none the less (still great work by fred, no question). 1) Compiling the psuedo-xml into perl, the compiler has tended to be more problematic than the actuall billing work. 2) Fractured XML-RPC api, way too many different functions and due to the "dumbness" of the compiler a tendancy to call the same functions over and over again. This certainly contributes to the mind-numbng slowless at least in OpenEMR's case. It is interesting to realize that freeb and anything that completely implements it's api is at the leading edge of what web services can do, by last count there are 100+ api function calls as well as a typical round trip taking as many as 500. I can't think of another application which uses half that many, by contrast the accounting integration in OpenEMR uses 2, possibly 3 calls. 4) Spaghetti code and more often than not incorrect code documentation, take a look at the actual formatbin files as well as my personal favorite Loop.pm . 5) FreeB has/had a flawed packing algorithm so that individual codes are not spread across HCFA's as efficiently as possible which appears to be an issue with some payers, mainly clearing houses. So anyway with that out of the way, the lessons I learned are: X124010A is an un-standard, it will not be possible to have a universal format or translator as each payer requires different and frequently mutally exclusive things. Ideally the different formats will subclass a master format, worst case every payer has a totally different format and to makes changes across all you have to find/replace. A claim needs to be processed in less that 1 second including the web services call. Many other applications are able to meet this requirement doing things of similar complexity. Callbacks are a bad idea, I actually implemented freeb and openemr and I would love to have that time back and I blame callbacks for the most part. When making a call to FreeB the calling application has to know what payer it is sending a claim to and must supply all of the suitable data(this sounds more problematic than it is in practice), both XML-RPC and SOAP support complex nested data structures that makes this reasonable. A minimum set being required is a good idea and extended information should be added using flexible "data soup" type structures rather than something more rigid or formal. The result of the call must be returned as part of the services response even if its a PDF and needs to be base64ed. This is a step for scalability, large payers are interested in freeb but if it uses local file system that makes horizontal scalability difficult. Possible solutions: PHP using a templating engine like smarty where PHP has a few simple WS function calls like startClaimTransation(specify payer format based on lookup table of supported options, loadPatient, LoadResponsiblePerson, loadInsurer, loadCodeData, endClaimTransaction. These build an in session structure and when endClaimTransaction it errors and gives you a chance to recall any of the loadFunctions, or rollback or if successful returns the completed claim data in the format you asked for. PHP takes the in session structure and maps it into templates structures that a different smarty templates turn in to x12 or HCFA formatted files. Smarty supports includes so common things like header etc can have defaults or you have the option of reimplementing should the particular payer require it. I have been using smarty to generate PHP code lately and this concept works very well. Python is also a good choice because almost all platforms have it natively and it also supports being built into a standalone executable. It could potentially use a very similar architecture to above. I should also say that while I have heard several people groan at the use of PHP for this it is important to recognize the most of the people who potentially/probably will could do the work for this are involved with PHP based EMR's so that should be taken in to consideration. While in an ideal world it might be neat to build an XML structure of the data and XSLT it into that payer formats having experimented with this recently it is difficult because XSLT is somewhat limited in areas where having functionality will make building this a lot faster. In a nutshell this would take a really long time, XML just doesn't like being dumbed down to HCFA and X12. There are a few schemas for X12 out there but I am not aware of a professional one yet, just institutional, so that would have to be created as well which is no small undertaking. The upside is that the knowledge about particular payers including Zirmed, Proxymed, Medi-cal, CMS, BCBS is already there or close to there. This is the hard part when you really get down to it, in my estimation there are about 600 different payer formats but the use of clearing houses mitigates this quite a bit for most. Probably a bit long winded, sorry for that. -- Sincerely, David Uhlman -- Walter Alfonso Núnez Rivera Médico - Programador Pascual de Andagoya 140 Lima 32 Perú