Amazing Charts alpha v4

gchiu:

Actually it may be that the lack of sophisticated templating is AC's strong point.

Something to ponder ...

Hi Brian: 

there are freeware programs which enable "text macro triggers", and lots of us use them.

Can you give some examples for the above programs please. Will try. May need to bug you again to get instructions how to use them.

Regards.

Most frequently cited:

http://www.shortkeys.com/

AC User Board thread on Macros/Templates:

http://amazingcharts.com/ub/ubbthreads.php?ubb=showflat&Number=6946

I reviewed shortkeys a few years back.  Shortkeys is not networkable (going on memory) so if you are using AC on more than 1 computer I would worry that adding macros would be cumbersome.  A few of these non-networkable macro programs have solid import tools, thus mitigating the synching problems somewhat.

This is a great tip which gets around the "I can't find the template" in AC. 

Some updates from AC users conference.

http://www.amazingcharts.com/ub/ubbthreads.php?ubb=showflat&Number=8917&page=0&fpart=2

 Its nice to finally know that Amazing Charts is completely paperless.

Some office may choose to use a little paper, but that's their choice, and not

forced by the EMR.

Some office may choose to use a little paper, but that's their choice, and not forced by the EMR.

Layne, you make me laugh!  I appreciate that you're taking a shot over Medtuity's bow with your comment, so I will be happy to take on your challenge of Medtuity's design.

When designing an EMR, particulary one that is designed to be used for perpetuity, there are some assumptions that must be made in the user interface very early on and a prime assumption is whether information should be available electronically.  Medtuity was never designed for creating an encounter note electronically and immediately printing it for a paper chart....yes, it can be done, but its design was in anticipation of a more demanding user.

Guessing as to whether needed information is in a paper chart or in an electronic record is an exercise meant to frustrate the user.

As a user, when reviewing a chart electronically, it makes sense to assume that if you click on an item, that it is available for electronic viewing.

The  real reason that an EMR vendor "doesn't force a user to be paperless" (to paraphrase you) is because the EMR was not designed to be paperless from the beginning. 

By the way, many of our practices started with paper records but elected to go paperless. An EMR not designed to be paperless is gambling on a short lifespan, IMHO.

Hello Jon,

Any reason why you are going towards SQL Express database? is this not a 38 bit database? How about using a 64bit SQL db like SQL Premium or Enterprise.

SQL express has limited admin functionalities and capabilities. How about MySQL?

Thanks

Tim

Tim,

That would be 32-bit or 64 bit, not 38-bit.

Both SQL Server 2005 and MySQL have 64-bit versions. To take advantage of 64-bit SQL Server requires a 64-bit processor and operating system, such as Windows Server 2003 running on a 64-bit processor.

These would allow more than 4GB of memory to be accessed.

For the average small practice running an EMR, the quality of the SQL code and database design will have far more to do with performance than going from 32-bit to 64-bit machine.

A bit of trivia, but if you look at the info for a Xeon processor, you may see some data like

address sizes : 38 bits physical, 48 bits virtual

mchasemd:

Some office may choose to use a little paper, but that's their choice, and not forced by the EMR.

Layne, you make me laugh!  I appreciate that you're taking a shot over Medtuity's bow with your comment, so I will be happy to take on your challenge of Medtuity's design.

Matt, what are you talking about?  Go back one page and you'll see the discussion where I had asked Joseph to answer Dr. Murdoch's paperless challenge.  Medtuity was not part of our discussion.  Joseph, thanks again for the info.

Layne,

In another thread of the same date, a physician was wondering if he should use Medtuity or Amazing Charts.  My suggestion was that a prime decision to be made was whether he anticipated being paper-based or paperless.  I related that all Medtuity users are paperless.  If he wanted to continue with paper, then he should consider Amazing Charts.  Your comment on this thread, "Some office may choose to use a little paper, but that's their choice, and not forced by the EMR"  appeared at the same time on a thread you haven't touched in weeks.  That was the basis of my comment and chuckle.

To turn a compelling design decision into a negative, seemed a reach, and at such an opportune time.

Matt, I found the thread you referred.  Sorry for any confusion with my post above. 

Joseph, any more updates on pending Version 4 ?

mchasemd:

Both SQL Server 2005 and MySQL have 64-bit versions. To take advantage of 64-bit SQL Server requires a 64-bit processor and operating system, such as Windows Server 2003 running on a 64-bit processor.

These would allow more than 4GB of memory to be accessed.

I'm not contradicting you exactly, but 4GB sounded a little small, so I checked the wikipedia areticle on SQL Server to find:

SQL Server normally supports up to 2 GB memory on x86 hardware,^[disputed] though it can be configured to use up to 64 GB if the Address Windowing Extension is used in the supporting operating system. For x64 hardware, it supports 8 TB of memory, and 7 TB for IA-64 systems (currently it is limited by Windows Server 2003 SP1 to 1TB). However, when running x86 versions of SQL Server on x64 hardware, it can access 4 GB of memory without any special configuration.^[3]

Which leads me to belive that one might never be able to predict what your memory limit is, but configured right on essentially consumer hardware, you could store terabytes.  While current Xeons certainly should be able to run x64 versions of Windows, I know current core2duo processors can as well.  I would suspect that c2d can also run windows server 64-bit, too.