ideaman911 wrote on Friday, June 12, 2009:
Rod et al;
Allscripts has repeatedly said they have no plans for direct linkages nor "upload" processing. But working with my wife (the actual prescriber), it has a lot of similarities to the GE MRP stuff I did, in that field data entry can be accomplished by tabbing between fields and typing the data.
In the absence of having actually done so, I believe it would be possible to allow a user of any such portal to effectively map a "macro" which could then be repeatedly run by OpenEMR (at least until that portal redesigned their portal 
by placing its needed data in that macro stream. Note that this would require the macro to actually occur in some other window from that in which OpenEMR was running, perhaps.
That way, OpenEMR users would have the flexibility to use their preferred portal without OpenEMR having to select any one such as "it", but could allow them to nonetheless do all the most desirable things within OpenEMR, thereby enhancing the value added for OpenEMR:
a) Actually track within OpenEMR all the meds our users actually prescribe, AS WELL AS allow additional tracking of other meds by other prescribers which our users could note in the meds records, and use the publically available FDA lists (which are NOT strictly limited to PDF by the way - see my separate email notes) for as much or as little data as our users deem appropriate for them.
b) Allow our users to select a med, then have a drop-down of all the dosage forms available, as well as generic equivalencies, for one-click selection. Once entered for that patient, OpenEMR would prompt for renewals in advance, and could send the scripts for e-Rx or print them, depending on CS status and prescriber preference. Both print and e-Rx could collect for most efficient batch process by the prescriber/facility.
c) For printing, would allow simple formatting for specialty state forms, etc, and include the ability to recall last script used so as to track the state code within OpenEMR but save the manual tedium of keying it (they are almost always a sequential series). But importantly, having once entered the selection, subsequent scripts would be self-prompting for the provider to simply accept, and they would be added to the stream for processing, thereby cutting down on the "Sunday Calls" (as well as every Other day ;-) That would require a patient specific checking of last Rx date and quantity, as well as the fills allowed by their insurers, etc.
d) That would also allow for checking any med shown for a patient against the FDA list for contraindicators, etc and raise a red flag, one of the tenets of the CCHIT. But ALL these would also have the ability of the prescriber to override and yet take advantage of all the efficiencies the technology makes possible.
e) Ideally for any med and insurer, we might consider making a "formulary validator" which would save a lot of silly time by indicating for a prescriber if they are likely to have to get approval. Some of the insurers publish those formularies. Again, though, the prescribers MUST have override ability.
f) Along those lines and recognizing it is unlikely to change in the near future, having a patient specific tracking for authorizations, etc (for both meds as well as for services, with both numerical and date count-downs to alarms) would also prevent rather than having to correct insurance coverage issues.
As I have noted before, I see what needs to occur. My skills are not sufficient to do it. Yet.
Joe Holzer Idea Man
http://www.holzerent.com