Home Forums Discussions Problems AC to EZ Claim Export - Place of Service

I see a lot of patients in as Inpatients in the hospital. I enter them into AC, and I have been exporting AC Encounters to EZ Claim. The place of Service I select in AC is Hospital.

When I import the encounters in EZ Claim, the PoS comes out as 22, which is Out-Patient Hospital. How can I correctly select the PoS in AC.

I am also interested in knowing what other users of AC are doing for their Hospital inpatient encounters for EMR and Billing.

Thank You

Satya

We had the same problem and to avoid hassle and confusion, we now enter all hospital and nursing home visits manually into ezclaim.

Are all your office claims transferring fine? Mine do on version 3.6.11 but I am hesitant to upgrade because many people have expressed AC-to-EZClaim issues with higher versions.

We also see inpatient, record it is AC and export to EZ claims and it appears to come back (from the Medicare EOB as 21, inpatient. I don't know how to open EZ claims, so I am skipping to the EOB, maybe it is an error that we are catching some where else in the process. I will look into this.

I am at version 3.6.25.

I am able to successfully export my calims from AC to EZClaim. I select export as "Simple Text File" and it is successfully imported into EZClaim through the Export/Import Utility of EZClaim

When I select export as EZClaim file in AC, the import in EZClaim is failing.

Satya

Thanks Saty, I will give it a shot now that I know someone is doing it successfully on a higher version.

I will let you know if my inpatients come across correctly after the upgrade.

Hello All, just thought I would add a short note here. EZClaim has now added a Scheduler component, and I have tried it out and worked with it, not bad at all. Way back when I was still writing and developing an EMR, I integrated EZClaim and still sell their software when the occasion arises and of late I have been their source they use for customers wanting a data transfer from Medisoft to EZClaim when changing software.

I just thought I would throw that out there. Just did one last week for one of their customers in Florida. Great software and does what it is supposed to do and works with almost any clearinghouse, including their own.
[url=http://www.ezclaim.com/scheduler.php][/url]
http://www.ezclaim.com/scheduler.php

That is going to be a tough sell, AC's scheduler is very nice.

How would this integrate with the AC Scheduler?

By the way, this also uses an ACCESS database...

The 10ft pole rule applies!

George,
For those of us who don't get the reference what are you getting at here in terms of the Access and the 10' poll???

Hockey, we all agree that the single most important component of any software application is the database. Most of what bedevils AC is the access database.

I fail to understand why a company selling a product to be shared among MULTIPLE users would be using ACCESS?

I would not touch a program with an access database with a 10 foot pole!

Let me just say that, despite AC's access database, I have had no major issues with the program. When SoapWare converted to a SQL database, my system crashed!! I have a bad taste in my mouth for this type of conversion. I can only hope that it will be a smooth one with few issues. Conversion to SQL is what led me to change to AC.

Leslie

Leslie, I have full faith and confidence in the AC programmer!

A Jet 4 backend Access database is good for most small physician offices that are small enough to still be able to use a Windows XP P2P network (i.e. objective limitation of 10 for WinXP to the backend AC computer, and the subjective limitation of up to ~20 for a Jet 4 backend database).

Other than the fact that a Jet 4 backend means that chart graphics are very limited, what specifically do you have against a Jet 4 backend? It's a wonderful, inexpensive platform onto which one can develop an excellent EMR, with a rich VBA programming environment. What else does an SQL have that you want? For example, is your AC database that slow? It shouldn't be, and if it is, it's usually because of other factors...

Be careful with what you wish for, as it's going to cost you both in software and hardware resources!

AL

That's sort of what I thought. See so many of us who wouldn't have know one from the other just a few years ago and still don't totally understand the underlying structure behind them, were just shopping and choose based on the usual consumer based stuff. Price, ease of use and maintaning those kind of things. Unfortunately one does not learn most of this stuff until way after then are already deeply committed or have made a serious purchase already.

Now in terms of our small office, although AC is no speed demon, she is certainly fast enough to get us thru our day, especially when all the other positives get factored in. Perhaps AC needs to be revamped to continue to grow in a more healthy fashion or to be able to do things that other potential customers are clammering for; but for us except for the main weakness of the lack of a strong competitive PM module which we are taking a wait and see attitude about, good old AC is good enough for us on most days.

File naming protocall needs to change big time. Something much more like Bert's FAP.

Alborg,

I view all of this "be careful what you wish for" as a red herring. The AC database for each customer is only GROWING not shrinking. As users request more features more tables are going to be added further INCREASING the amount of data the system will have to store.

Your suggestion seems to be to run it as is and HOPE you never reach that threshold. Hope is not a strategy when it comes to software design and architecture.

I understand the misgivings of those who have dealt with poor implementations in switching from Access to SQL Server: that was not because SQLServer is bad, but because the developers were not sufficiently versed in the new product and did not have the requisite skillset to make such a change. Please read the last sentence again!
I posted the following a few months back. I am posting it again for you.

Here is an excellent Article that describes issues with the Jet Engine:
http://www.aldex.co.uk/sqlserver.html

In Microsoft's own words....
The following comes from Microsoft article Q300216.

"Microsoft Jet is a file-sharing database system. A file-sharing database is one in which all the processing of the file takes place at the client. When a file-sharing database, such as Microsoft Jet, is used in a multiuser environment, multiple client processes are using file read, write, and locking operations on the same shared file across a network. If, for any reason, a process cannot be completed, the file can be left in an incomplete or a corrupted state. Two examples of when a process may not be completed is when a client is terminated unexpectedly or when a network connection to a server is dropped.

Microsoft Jet is not intended to be used with high-stress, high-concurrency, 24x7 server applications, such as Web, commerce, transactional, and messaging servers. For these type of applications, the best solution is to switch to a true client/server-based database system such as Microsoft Data Engine (MSDE)[SQL Server Express] or Microsoft SQL Server. When you use Microsoft Jet in high-stress applications such as Microsoft Internet Information Server (IIS), customers have reported database corruption, stability issues such as IIS crashing or locking up, and also a sudden and persistent failure of the driver to connect to a valid database that requires re-starting the IIS service."

Performance
With Access all tables involved in a form, report or a query are copied across the network from the server to the client's machine. The tables are then processed and filtered to generate the required recordset. For example if looking up details for one particular order from an orders table containing, say, 50,000 records then the whole table (all 50,000 records) is dragged over the network and then 49,999 of these records are thrown away (this is an over-simplification since indexing can be used to mitigate this to some extent). Contrast this with SQL Server where the filtering takes place on the server (if designed properly) and only 1 record is transmitted over the network.

This can affect performance in two ways. Firstly SQL Server is highly optimised and can usually perform the required filtering much more quickly than the client machine and secondly the amount of data sent across the network link is vastly reduced. For most databases the main performance bottleneck is data transmission over the network hence reducing this can give a really dramatic improvement in performance.

Predicting likely performance improvements is very difficult .

Alborg asked what does SQL have that you want. For starters, stored procedures and triggers.

Let me explain, a trigger is a database level event that can fire automatically in response to a change in some specific data. Let me give you an example: Take the name history right now AC does not have the ability to store the former name of a patient. With a SQL Server database one could write an ON UPDATE trigger for a name change. The means any time the any of the name fields change the OLD name is AUTOMATICALLY written to the Name History table.

The first part, Stored Procedures are the bedrock of good SQL development. These are queries what are written and stored in the database that perform repeat tasks. Let's say that Bert wanted to integrate his FAP with AC, one of the things he would need is access to the patient record in AC. If AC had a stored procedure named

sp_Patient_SelectByName which required FirstName, MiddleName, LastName he could then get a list of all the patients with a first name 'George' to select the patient he wants. Because that query happens exclusively at the database level, it does not affect the AC program itself.

Lastly Charting and Graphing ARE NOT, repeat ARE NOT, an inherent function of the DATABASE engine. As a matter of fact take a look at
www.dundas.com or
www.componentart.com/charting/gallery/

and you will see that companies are now developing charting engines that work with just about any DATA PROVIDER be it Access, SQL Server, Oracle, DB2 or other database.

Hi gkfahnbulleh:

Your points are well taken, but I don't discuss my perception of SQL vs. Jet lightly.

First, a little about me. I'm a full-time physician (oncologist, hematologist, internist) with a private practice in Arlington, Virginia. I have a partner and 4 employees. My office has 8 working computers (1 server and 7 nodes).

I'm an avid programmer, too, going back to 1990 when I first learned to program in Paradox for DOS, a very decent file-server relational database. In about a year I made my first EMR/PMS. In 1995 I ported it over to MS Access. Since then I've also programmed in the MS Word platform as well as Satellite Forms (for the Palm- I once had a Palm-based EMR too).

Oh, before we begin our discussion- some clarifications for the non-technical: "Access" means the program that usually is split into a front-end and a back-end. You can have an "Access" database with an SQL backend, and you can also have an "Access" database with a Jet 4 backend. What we'll be discussing here is the difference between Jet 4 and SQL as a backends.

>>> The AC database for each customer is only GROWING not shrinking. As users request more features more tables are going to be added further INCREASING the amount of data the system will have to store. Your suggestion seems to be to run it as is and HOPE you never reach that threshold. Hope is not a strategy when it comes to software design and architecture.

My patient database is now 18 years old and I've seen about 20000 new patients. My MS Access-based program is not unlike AC, except possibly that it's about twice it's size, with about 800 objects (forms, reports, tables). It's PMS I realized yesterday when I downloaded it for the first time is very similar to EZ Claims. I also have an oncology module which helps me with chemotherapy. My largest table, even after occasional compacting, is my accounts table, which holds approximately 71000 records. In the late 1990's my LAN ran with an 11 MBPS, from about 2000 thru the present day it's run at 100 MBPS, and I'm in the process of upgrading my LAN to a Gigabit LAN (1000 MBPS). At no time did my software run poorly, even at the lowly 11 MBPS LAN speed. A file server topology has served me well for a long time.

I'm still waiting for that "threshold", and my belief that the Jet 4 backend is more than enough for a small to medium sized office is not based on "hope". I'm more than ready, though, to go to SQL if and when I need to do so. I do feel that physicians are being led to believe that they have to buy a Maserati when a Honda will do- and many vendors play into that game due to their belief that-

1) physicians have large pockets full of cash, and more money can be made with an SQL backend, and
2) their sincere belief that they lose sales to other vendors who continue the fallacy that not having an SQL backend means that an EMR is second-rate, which is not true, and
3) the back end of an Access data base can be upgraded. MS Access also allows for the creation of an adp file to work with the back end of an Access data base upgraded to SQL. When using an ADP file, you select the server and data base to connect to, much like a SQL interface with either windows nt or other password identity methods. The ADP files follow the SQL structure a little differently than a normal mdb access data base.

>>> I understand the misgivings of those who have dealt with poor implementations in switching from Access to SQL Server: that was not because SQLServer is bad, but because the developers were not sufficiently versed in the new product and did not have the requisite skillset to make such a change.

Same goes with poorly written Jet 4 backends. A poorly written Access/Jet 4 file-server database leads to poorly performing software.

>>> Microsoft Jet is a file-sharing database system

True, but remember- in the days where there were only 11 MBPS LANs I once read in one MS Access book that Access would never run well on a P2P LAN. It did in my office, and well. Nowadays, with Megabit and Gigabit LANs the difference between a file-server and a client-server performance is nil in the small to medium sized office setting.

Also, you can also design look up tables to be local on the client to avoid network congestion as the client is not having to access the back end for look up information.

>>> Microsoft Jet is not intended to be used with high-stress, high-concurrency, 24x7 server applications, such as Web, commerce, transactional, and messaging servers. For these type of applications, the best solution is to switch to a true client/server-based database system such as Microsoft Data Engine (MSDE)[SQL Server Express] or Microsoft SQL Server.

Sure, an SQL is appropriate in an airport, in a bank, and in the NYSE. It's overkill in a small to medium sized medical office. MS SQL Server is expensive and will double or triple the cost of AC, both up front and in the cost of hiring IT professionals to manage it.

You can use MS SQL Server Express, but it has a governor to only allow 5 concurrent connections at a time, unlike Jet 4 which can be used in up to 20 consecutive connections without any significant degradation in performance, but you can push the limits (up to 255 connections actually) if you are a real cheap b*stard!

>>> If, for any reason, a process cannot be completed, the file can be left in an incomplete or a corrupted state. Two examples of when a process may not be completed is when a client is terminated unexpectedly or when a network connection to a server is dropped.

That rarely happens, and the only time that I had problems was with a LAN that had Windows 2000 mixed in with Windows ME. I used the latter as my "back end" which caused an undocumented Windows bug that would drop connections and led to a few corruption problems.

In the modern Win XP P2P LAN table corruption is a rare event, and when that occurs it's NOT a major problem (usually affects one record)... I see this occur maybe once every 2 to 3 years.

>>> stored procedures and triggers.

A MS Access form has numerous events associated with all of the form elements, and you can save SQL queries either as objects or in code, which can be called up at any time. These are the backbone to great Jet 4 development too...

I always save my SQL queries in my code so that when I convert my software to an executable mdb file, they are hidden.

>>> Lastly Charting and Graphing ARE NOT, repeat ARE NOT, an inherent function of the DATABASE engine.

The MS Office software comes with the MS Office Graphic Library activex control whose reference can be set, essentially making this an "inherent" feature. Pretty nifty, really. You can do that with any of the different MS Office softwares (s.a. Access, Word, PowerPoint, Excel, etc). The companies you mention make other activex controls that adds extra power, but this comes at a significant cost.

LASTLY...

Access still has it's place and there is always the big debate of whether Access or SQL is the right answer. The answer I think depends highly on the user and what they need to accomplish and how. For the small peer to peer office needing a mutli user program Access can still fit the bill quite well, as AC has done so well over the years . The queries are better placed on the client instead of the back end, but the options are there for either/and or both.

If you beef up the equipment used in a network, i.e. a server pc with at least 1-4 GB of ram, that also helps out in serving the data to the clients. Clients should also have beefed up ram, with at least 1 GB (I prefer 2-3 GB). If you have a rather large program, you can also split the back ends to have 2 instead of one, so again, many design options and choices.

This is an important topic in that for a small office to purchase the obviously super-robust entails that purchase of not only an expensive server, but also the up-front $1000+ SQL fee and also the technical expertise to maintain this complicated setup. The savings of a Jet 4.0 vs. an SQL is wide. An SQL can total ~ $15000 for a multi-processor RAID server with a multi-license SQL backend vs. a mere ~$3000 for a setup with 6 ebay barebone computers in a 1000 mbps LAN configuration. The Jet 4.0 backend is free, expandable to reasonable limits, and easy to maintain (and program).

The overall stability and speed will not differ much between the 2 setups in a small to medium office setting, but the Jet 4.0 customers will be happier since in these Medicare-cutting times they will have more cash in their pockets at the end of the day.

Thank you Al for the enlightening info here. You mention:

How can you tell that governor that I need 6th and 7th concurrent connection on board?

Can we buy additional licenses?

Alborg wrote


Now you are trying to scare people into thinking they will have to pay 15000 for SQL Server to run AC. Do not poison the well.

There is no governor in SQL Server 2005. So when you make this statement it tells me you are more interested in scaring people than in conveying accurate knowledge.

Euan Garden states this plainly in his SQL MythBusters:


http://blogs.msdn.com/euanga/archive/2006/03/09/545576.aspx

Alborg wrote:

When you write software for YOU, you can demand that YOUR computers have Office. When you write software for COMMERCIAL consumption you cannot insist that every machine has Office installed. Which version? Office 2000. OfficeXP, Office 2003, Office 2008?

I am a Microsoft developer, and I develop software for the least common denominator. Any software package I build will have the following. The ability to read and write word, excel, pdf files without saddling the user with extra costs.

Actually the 6th login wouldn't be allowed. But gkfahnbulleh is right on the governor issue- MS got rid of it after the MDSE was upgraded to MS SQL Server Express. There are other limitations, though- check http://en.wikipedia.org/wiki/SQL_Server_Express.

The cost issue is real- I remember going through this with Terry, the CEO of DescriptMED EMR. His EMR went from free to about $4000 a lecense when he upgraded his software to SQL. Same happened with SOAPWare. Costs just go up... it could be a good thing, especially if you add graphics and inking which tend to bloat a Jet 4 table tremendously very quickly, but the enduser has to decide what is in the best interests for his particular situation.

>>> When you write software for YOU, you can demand that YOUR computers have Office. When you write software for COMMERCIAL consumption you cannot insist that every machine has Office installed. Which version? Office 2000. OfficeXP, Office 2003, Office 2008?

I am a Microsoft developer, and I develop software for the least common denominator. Any software package I build will have the following. The ability to read and write word, excel, pdf files without saddling the user with extra costs.

Actually, I used to think about distributing an mde database by using the "developer" version of MS Office (i.e. "runtiime" distribution), but Barbara Duck (emrupdate moderator) convinced me that what she does is the way to go- it's best to have the endusers simply have a license of Office in every computer. The cost of MS Office is cheap and it makes for cleaner upgrades and distribution. Anyhow- if you need MS Word, how will you simulate this program without actually having a version of MS Word on your computer?

More later (I'm between patients).

Cheers,
Al

Alborg, so it comes down to cost. For a system like AC there should be no additional costs for hardware to run SQL Server Express.

Also be reminded that if you buy Small Business Server you get SQL Server with 5 CALS. If you are worried about concurrency issues you should rest assured that ADO.Net address much of that issue because it is based on the "disconnected data set"


This means that the issue of concurrency is reduced many fold. When you need a "Patient" record it connects to the database gets the record and disconnects.

Please read the following article:

http://aspalliance.com/836_An_Insight_into_ADONET

But the issue of concurrency is more theoretical than reality... in 12 years of using MS Access, I have not had a table crash due to innate Jet 4 table access issues. I'm sure that most AC users would agree, or else they would have posted such, and I have yet to see someone complain of "bumper car" crashes.

I do like that MS did take the MSDE counter off- that was a good move on their part.

Alborg you started by saying one of your dings against SQL Server was a 5 cal license. I gave you information that there is no governor in SQL Server Express. I provided you with an article which described the ADO.Net architecture.

Now you claim [qoute]the issues of concurrency is more theoretical than practical[/quote]


Alborg, unless I am missing something, there have been numerous complaints on here about networking access and remote use of AC.

Apparently you are unwilling to accept that access has its limitations, and if this product is to grow, and be the feature rich app people are asking for, it will have to move off access.

I will not tarry any longer.

Alborg wrote:

So your Access database with 10 users is now cheaper WHEN YOU REQUIRE every user to have office installed? Office runs anywhere from 200 - 400. An additional cost of 2000 - 4000 to the end user.

As for the second part of your question :

Pity you don't know about this.

For MS-Word: Please visit www.textcontrol.com

As you can see, they make BOTH .Net and ActiveX components that are redistributable ROYALTY FREE.

For MS-Excel please visit
http://www.componentone.com/SuperProducts/ExcelNET/

They make a royalty free Excel Component which allows your application to create and edit Excel, WITHOUT having excel on your computer.

So instead of DEMANDING EVERYONE who uses your application have MS-Office, it is better to build your application with the included functionality of reading, writing, and editing MS Word and Excel without that requirement. I've demonstrated that it can be done!

Most of the issues usually deal with the environment that Jet 4 has to work in. If someone is having difficulty with a Jet 4 backend, then by all means an SQL may be just the ticket. That is why they both exist.

In fact, maybe even a NextGen would be preferable too! (heck, it only costs $30000 per license...

Just about all computers in a medical environment have MS Office of some sort installed, even those in the hospital, so there really isn't any extra cost.

>>> Pity you don't know about this.

Why be so rough? This is just a discussion. Geez. Of course you can buy components, and there are several companies that sell stuff for MS Office. So what? BTW, you weren't familiar with MS Access' activex add-ins, s.a. for adding in Graphing, but I didn't go out of my way to argue about it, even though this is critical to Office development.

Wrong,Alborg. I knew about ActiveX for Access and VB6. This is old Technonogy, 10 years old to be exact. I use .Net for everything, and there is a .Net component to do just about anything you need.

Again your issues with SQL Server Express seem to be that you KNOW access and will not venture into "unknown" territory. I have seen this so many times. Where programmers who do not know about a technology or are too comfortable with what they know and do not want to step outside their comfort zone, do everything in their power to convince their bosses that the new technology is bad and will ruin them.

I live and breath the implementation right on the edge, and I can tell you that VB6 does not even come close to matching the power of VB9.

Something about demanding that end users have Office installed sticks in my craw. When you deliver software for commercial consumption you have to be very careful about demanding that OTHER software MUST be installed.

But if you are going to demand I have office then WHICH VERSION of Office am I required to have? Right now available on the market we have '97, 2000, XP, 2003, 2005, and 2008.

Can you INSURE that your software written for Access 2003 will work on Access 2008?

What if it won't and I feel there are features in Office 2008 I must have? All of a sudden your software has become a bottleneck in my upgrade process.

Conversely, when you upgrade your program to Access 2008, I will also be REQUIRED TO UPGRADE my Office.

Another issue with using these older development environments is "DLL Hell" .Net addresses this because installed apps do not share assemblies but have all the assemblies they need in their own space. This allows you to run multiple versions of an application without breaking the older versions.

Hi gkfahnbulleh:

I can see that you are really into the edge of software technology and are very passionate about your industry and what you do. I can also see that what I say as a physician/enduser/programmer may seem like heresy to you. The real problem is that we are looking at EMR from 2 different views- you as a developer/seller and I as an developer/enduser who sees that a lot of the upgrades that Microsoft puts out is "fluff".

I hope to get into .Net technology one day and I'll even get into MS Office 2010 when it comes out (skipping MS Office 2007 like I did MS Office 2002 until it came with a laptop that I bought). The programs that I choose to learn are those that will impact my business (medicine) right here and right now, how they impact my workflow seeing patients. Everything from programming for my Palm, programming in InstallShield technologies, and this week I've mastered MS Frontpage 2003 to create my website (to be up this weekend!).

Getting back to the issue of Jet4 vs SQL, the thing that will eventually get me to want SQL would be its ability to handle large files, including graphic pics, ink files, faxes, and other scanned in material.

>>> Where programmers who do not know about a technology or are too comfortable with what they know and do not want to step outside their comfort zone, do everything in their power to convince their bosses that the new technology is bad and will ruin them.

I kind of don't work for you so I don't have to put up with your "hot air" Gospel of what language I have to work in. It just seems interesting to me how AC, using "old technology" as you would refer to anything less than the most up-to-date .Net programming platform has done so well with its userbase. This is probably because in the end, the tricks and simplicity of the program is what the end users want and expect.

>>> I can tell you that VB6 does not even come close to matching the power of VB9.

And, so why should I jump and get into VB9 at this very instant? I'm sure that most likely I'd be stating these words, though, if my next job depended on it (like in your case).

>>> Something about demanding that end users have Office installed sticks in my craw. When you deliver software for commercial consumption you have to be very careful about demanding that OTHER software MUST be installed.

Again, in the typical medical office and in almost all hospitals MS Office rules. Just about every computer has a version of MS Office on just about all of their computers. It's a general industry standard, especially in healthcare.

>>> Can you INSURE that your software written for Access 2003 will work on Access 2008? What if it won't and I feel there are features in Office 2008 I must have? All of a sudden your software has become a bottleneck in my upgrade process.

The EMR that I use at my office will work with MS Office 2000, 2002, and 2003. Not Access 2008. My EMR is not for sale, but if it were, and you wanted to use Office 2008, then you would have to look for a different EMR.

>>> Conversely, when you upgrade your program to Access 2008, I will also be REQUIRED TO UPGRADE my Office.

Say I wanted to add inking- I'd have to get an SQL backend and upgrade folks to Office 2002 or later. Heck, you can buy MS Office 2002 on ebay "buy it now" for a mere $139 here: http://cgi.ebay.com/MS-Office-XP-Pr...160258746533&_trksid=p3286.m14.l1318

>>> Another issue with using these older development environments is "DLL Hell" .Net addresses this because installed apps do not share assemblies but have all the assemblies they need in their own space. This allows you to run multiple versions of an application without breaking the older versions.

I have 3 computers, each with a different version of MS Office that I use to make sure that the appropriate dlls are loaded correctly. I have all the necessary dlls that can cause problems when missing filed under "common dlls", "office 2000 dlls", "office 2002 dlls", "office 2003 dlls". I have executables that will install these dlls when necessary. It's not a big deal and actually, both the MS Word and MS Access EMRs that I've written have a activex controls that will work on all 3 platforms.

Alborg wrote:

What in the world are you talking about it's ability to handle large files?


The ability to add "ink" has ABSOLUTELY NOTHING, REPEAT NOTHING to do with the database. Adding Ink to an application is part of the TabletPC SDK.

Alborg, I think you should spend some time actually understanding the differences between .Net, the CLR, and the Database (SQL Server), then we can have a more fruitful discussion.

Look, gkfahnbulleh, when you save your graphic images into a backend database SQL (including ink files, s.a. drawings and script), you are using table real estate, which you cannot do well in a Jet 4 table platform.

In your note above you are simply acting like a condescending jerk. You are right- we cannot have a fruitful discussion. You are intent on attacking and having an argumentative discussion. We will simply have to agree to disagree.

I will end it now.

Alborg, if you want to save images in the database, in any database you do it as a BLOB(BINARY LARGE OBJECT). Access does have the ability to store images; however, that is not the issue.

Most document management systems DO NOT STORE the images in the database, instead they store the "the image location" in a column. So you would create a directory, c:\myapplication\images. You would have a standard naming convention for each image filename. In a law firm, for example, you would used a convention like clientID_CaseID_DocType_Version_DocDate. The naming convention allows you to identify the document even if you do not have access to the database.

From a network security aspect, you would grant access to the file location to the application, not to individual users. You would then control the user access by controlling their access in their database rights.

Another reason for doing this, is that you have to "stream" images into and out of the database in order to "present" them to the UI (User Interface). This can generate a lot of load on the server in a very small environment, say of 5 or 10 people.

But you do not have to take my word for it. Bert has developed a EDM (electronic document management) application FAP. Ask him if he stores his images in the database.

Your second reason for going to SQL Server was the use of Ink. Inking has nothing to do with the database but rather with the programming platform, .Net vs VB6.

What has happened here Alborg, is that you gave three (3) major reasons for NOT USING SQL server:
1) the governor
2) no need to store BLOBS
3) no need for ink

I have demonstrated to you that all three of those reasons are either incorrect or have no relevance in the decision to move to a SQL Server database.

I apologize if you feel I have been condescending. Saying you have been "programming" for 15 years does not tell me anything, especially when some of the reasons you give for not using SQL date back to 2000 (SQL Server 2000/MSDE).

Addendum
In medicine, you physicians are REQUIRED to take a certain number of CME courses and in order to remain Board Certified, you have to take an exam every X number of years. The purpose of these CME's and Exams is to ensure that physicians are well versed in the most modern and relevant treatment modalities/techniques/standards which will allow them to deliver the best product(medicine) to their customers(patients).

Well the same principle applies in software design/development. For me, it is not about using the latest Microsoft Fluff, but rather embracing the newer technologies which make development of software easier.

Let me give you an example: One of the most difficult things to do is to develop a web application. It requires you know HTML, JavaScript, your web technology (ASP.net, PHP), a programming Language (VB, C#, Perl), understand database design and access language. All of this just to present a single web page with data to the Client. Microsoft has been developing over the past 3 years a new technology called SilverLight, which promises to be an upgrade over current web development, by replacing the HTML, JavaScript layer and allowing you to write VB, or C# on the client. This will be in the official release of Silverlight 2.0. This holds great promise however, until it is actually released with that capability, I do not intend to embrace it. There are not enough hours in the day, for me to waste with technology that is not mature, no matter how promising!!! www.silverlight.net
End Addendum

I will not argue with you about how you treat a patient, but you intend to argue with me ad infinitum about software design/development...something you do as a hobbyist and not professional.

Blob images were first develped back in around 1993 and I was able to use them first in the DOS environment under the developmental platform Paradox for DOS back in 1993.

Look- I'm not going to perpetuate this SQL vs. Jet 4 anymore with you. We simply need to agree to disagree.

>>> I will not argue with you about how you treat a patient, but you intend to argue with me ad infinitum about software design/development...something you do as a hobbyist and not professional.

Now I see why you are so aggressive and nasty in your postings- you are defensive of the fact that a physician can program to solve problems in his office instead of hiring someone like you. Rest assurred, I'm not trying to take your job nor am I trying to compete with whatever you do, which is why I'm not actively seeking Microsoft certification.

When discussing technology (like religion), you should state your reasons for doing things and avoid denegrating others with a different opinion. It only belittles you and your message.

>>> This holds great promise however, until it is actually released with that capability, I do not intend to embrace it. There are not enough hours in the day, for me to waste with technology that is not mature, no matter how promising!!! www.silverlight.net

Thank you- that's exactly how I feel about a lot of the newer technologies that are coming out from Microsoft on a yearly basis. I'm not alone- check out the MVP (MS "Most Valuable Professionals") letter in defense of maintenance of unmanaged VB6/VBA in parallel to managed VB.NET signed so far by 265 MVPs.

Programming is not just a "hobby" for me, as I use the very programs that I've developed on a day-in day-out basis as a tool to see my patients faster and more efficiently. SQL is not in the equation at thie time.

BTW, have you developed an EMR and/or a PMS?

I think the problem here gentlemen is the fact that perhaps Gee wants to give us the very best and leading edge while most of us here can not afford such and Al is one of the strongest and best defenders of the rights of small low paid, low cost providers offices to be able to use nice, neat tidy packages like his own and AC without a massive enterprise based entity like CCHIT telling us all what we must have and pay for.

For many of us AC users and docs like Al who was talented enough to create his own program, such programs are basically good enough. Just as I would not purchase some enterprise size program to do my bookkeeping when $150 every other year QuickBooks is enough for most small and even medium sized businesses. There are some really big players running their places on nothing but QB's.

I think most of us here who are not professional programers get really scared when we hear talk about growing AC too much, too cutting edge, high tech. If AC goes the way of SoapWare or the Dodo bird we will all be up the CCHIT river without a paddle. As much as we really want AC to add some useful features or clean up some of it's know "issues" I'm sure none of us would want that to come with some NexGen price tag, bloat or impersonal corporate culture.

AC is really unique in this industry with this IPod, Mac, Apple kind of community feeling and thing surrounding it. And part of that is based on culture, some of it on the product doing 9 out of 10 things we need it do all day at an almost unbelievable price (especially in this industry where everyone sees us as just a conduit to their money from our pockets), as well as her simple to learn and use design. It is this combination of things that makes this product what it is and has created all this user support. AC is sort of our EMR saviour and we are all very defensive of her. Even Al who doesn't even use her himself, because he too views AC as something to be held up as a viable alternative to all the large, enterprise sized and priced pieces of CCHIT that are attempting to use our own government against us to force their over priced products down our throats.

You two have just engaged in the inside, tech version of what Gee and Myself went thru many months ago. Gee, yes staying current and cutting edge is great for those who can afford it. But many of us like our older models just the way they are, even with all their flaws. Would I love to have some new G3 Hemi Grand Cherokee for a really fun daily driver? Sure I would, but I can't even come close to affording it. And I really like, a whole lot, my older, first generation 5.2 Magnum one with two solid axles for off roading. Is it the as fast as a newer Hemi with independent suspension? No, but get the two on a trail and watch my older two solid axle one leave it spinning its tires stuck in the first big obsticle.

Older can be better or more valued to the owner or user. New can be real cool and on the edge too. Gee your ideas are great for larger companies that can afford to build and go in that direction no doubt about it. But for the mainly starving solo PCP's here that use AC in the face of declining payments and the ever controlling insurance industry, cheap but well put together tools like AC are all we can afford and we will be dead in the water if Jon decides to take her too far too the other extreme. There really is no other product out there that can fit this niche the way AC does and we hope and pray that Jon keeps her in such a format as to allow us little guys to continue to be able to afford to use her....

Does this all make sense????

Be good guys.

Alborg wrote:

What you offered as "opinion" regarding SQL Server was, stated as fact and was based on 3 incorrect premises. It is not possible for me to refute those facts and not call into question "your opinion."

In any event, we are talking past each other. I do sincerely apologize if you feel I have been condescending, but I do not know of any other way to say "that is not correct" other than to say "that is not correct."

Thank you for taking a closer look at what I meant when I wrote about developing a file naming convention for naming individual document files. You realized I was not talking about GUIDs.

I have developed a web-based patient management system which allows doctors to keep track of their hospital rounds / visits / consults and apply the appropriate billing codes and share that information with the rest of the doctors in the hospital. The system also contains a componentized "code engine" that allows doctor to construct their own "code" groups. For example, in cardiology, one procedure code is may be accompanied by several other codes. With the "code engine" the doctor can create a master code set which would automatically apply the other codes for that procedure.

Lastly, it does not matter what profession you are in, database design and management is at the core of ANY system you build. Yes even for medicine...it's all in the database.

>>> I have developed a web-based patient management system which allows doctors to keep track of their hospital rounds / visits / consults and apply the appropriate billing codes and share that information with the rest of the doctors in the hospital.

I was wrong in the governor issue in the MS SQL Express upgrade to the MDSE- thank you for the correction. The need to store graphic files and inked notes are usually stored directly to an SQL database, although yeah, you can use GUIDs on occasions.

I developed a thumb drive-based hospital tracking system using the MS Word software that is installed on all of the 2 hospital's that I visit computers. It's actually pretty cool, using VBA and a MS Access Jet 4 tables to hold the lookup data (the visit data is stored on the Word document). I can also store it on my MS Access EMR/PMS which also fits on my thumb drive. (The Jet 4 tables are about 100MB in size after 18 years of data collection.) Nowadays I am using the latter, since I have the EMR open to access patient medical data already. There is also an issue with the MS Word thumbdrive where I need to add a new form to more rapidly gather in data... just need to do a few things first before that gets updated.

Unfortunately, in my main hospital (Virginia Hospital Center), they are starting to limit the Web access to one computer per station, so accessing the Web would be difficult. It seems that many of the nurses were wasting time on the Web, rather than in patient care.

The idea to use the thumb drive, BTW, came from a friend of mine at emrupdate, Gilbert B. Carter, MD, JD, FP, who developed the "Ten Second Medical Record", http://www.tensecondmedicalrecord.com/.

Alborg, we have more in common than we have that are different; so let's get along...

Connectivity, with all of the new phones you have all the internet connectivity you need without having to depend on the hospitals internet connection. As a matter of fact, I am looking to porting my RoundingList as an iPhone webApp and a WinMobile app. No I will not be using SQL Server Express...I will be using VistaDB www.vistaDB.Net. I will also be using WCF (windows communications foundation) http://msdn.microsoft.com/en-us/netframework/aa663324.aspx for secure remote connection back to the database. Yes and I'm hoping it will be able to talk to AC!

Hockey, I believe AC has a very nice core. It also has loyal users. What is needed is EXTENSIBILITY. The ability for 3rd parties to build modules which EXTEND the functionality but do not interfere with the main program.

One such program is what I wrote about above. Bert has FAP. There will be others. I believe the powers that be are thinking about the best mechanism for this type of collaboration.

The users, after purchasing the core module, will then BUY ONLY THE MODULES important to them. The program will "grow" yet maintain its small town feeling.

Gee,
But in the reverse, if I felt that the Imported Items sections was better and still allowed me to pull my "paper" back out in an easier fashion, just in case AC blows tomorrow I wouldn't even want or use a FAP. Sometimes the main product should still do what the main product can and should do. As much as I think I'm OK with the concept of a SDP the devil is in the details. And the owner of the main program should not use it as an excuse not to continue to grow and develop their program.

At what point do I need to now purchase five sepatate programs with five separate EULA's, support packages, and all the other headaches just to have the features that perhaps should have just been there all along??? Now I have to pay Gee and Bert goodness knows how much plus perhaps another fee to Jon for the interface activation just like with the ECG's and the rest??? It may be a cozy relationship for all the software vendors, but it may be living expensive hell for all the users.

At some point the product should do the main things it should do. And it bothers me that certain obvious flaws like the imported items section has been left there to roit as it has when people talk about it's limitations all the time. There is a new thread on it right now as we speak. Tell me with a straight face that any EMR in today's medical enviornment shouldn't have a section like II's that works really well with all the tests and paper that come flying into an office every day. Bert should never have felt so left alone in left field that he finally designed an alternative in the first place that now some of us are seriously considering using. This really should be in my EMR. And good cusomizable way to store papers in relation to the patient and their chart. It almost shouldn't have to be said. Just like better more accurate tracking and recording in the Rx section. I don't want some extra expense add-on Rx writer, I just want the one we have already in AC to work the way the rules say we should record these things and to allow us to "E" fax them without having to pay those other mandate bozos who are trying to take over that one part of the market by buying our government for thier own greedy needs too.

Now perhaps something as Not as real EMR as a PM module, perhaps a relationship with a few more folks like EZ Claims is now that I could understand. But as much as I like FAP and mainly because it saves my data my way, and names the darn files with the patient's name and the date of the scan, simple standard naming system, the Imported Items should blow FAP out of the water and poor Bert would not have to had to have written and developed the darn thing in the first place. Granted Bert loves playing with tech, but he has an office with patients to run. This is a feature that should just be there and that it should work as needed. It shouldn't be another $500 add on. Same thing with the Vaccines too. Bert has been working on Viper and it seems really good. But tell me again with a straight face that a really good vaccine tracking and recording system shouldn't be part of any valid EMR that's core users are PCP's??? Jon should have Viper on steroids already... Get it???

So pardon me if I reserve judgement on all of this, but I think my middle of the road view here is the correct one. EMR should do what any and most EMR's are attempting or are doing, or what paper charts can now. Then and only then can you sell me at added prices and "added value" other add on programs do neat but not everyone needs them features. Like a USB direct to chart ECG or Spirometry. And even there, most EMR's are doing this these days. Us small underpaid offices just can't afford to pay for five more expensive taxi-meter leases and relationships just so we can get done what is part of everyday life and business in our world. That the main program, parent company should see as it's core responsibility.

I would rather pay Jon and AC a few hundred dollars more to clean up and develop these things inside their own programs many times more, than I would to be in the future that you seem to envision with the users purchasing half a dozen modules from other vendors (whether thru AC or privately) that then pumps the price right thru the roof and turns AC into some emasculated version of what it is today with lots of holes that then need to be plugged with lots of "Added Value" I believe is the term add ons. AC always tried to stay away from too many modules because the idea was that it had most of what you needed and wanted already for one really great price. I hope she stays that way....

HockeyRef, as I said earlier, it is one thing to develop software for your own use, and it is another to develop software for commercial consumption. Bert developed FAP for Bert. If he wants to make it commercially available then he has to become a "software" company.