There is no plugin. I'm currently working on this too. The USB solution is not amenable to Troi's serial plugin so my IOGear reader can't talk to the plugin. I need it to read control data from our CBC machine's control smart card directly into the PaperCutPro EMH/practice management software that I created.
Presently the Troi program works great and I have both our CBC machine and Urine analysis machine communicating directly with PaperCutPro via serial cables. The staff inserts the sample into the lab instruments along with the patient number and walk away. Troi's serial plugin monitors the RS232 buffer and the populates the lab data for the correct patient.
Similarly I have a control 'patient' record but the control results are not handled the same way as a real patient sample. They are dumped onto a smart card. Thus I need a serial, not USB, reader to try and connect with the Troi serial plugin and see if I can get to that smart card data.
Smart card's are another animal though and your solution, like mine, will depend on the embedded programming of your particularly 'instrument.' I am not sure how that is exactly with my CBC machine, but one thing is for sure. The data doesn't pop up like regular disk drive volume, so I've read. You have to know what to ask for and where on the smart card.
If anyone has a solution or more information or can correct my understand if its wrong, then it would be much appreciated.
Ron Smith, MD
well, there must be a way, that's for sure. There are SW-Products which already work on Mac.
This link might be another hint, maybe providing some resources (SDK / API):
There I've found a universal driver I installed. The ReadMe file could be of any help?!
Installation instructions for the
HID Global OMNIKEY CCID Driver
For Mac OS X 10.5 and greater on Intel-Architecture.
* OMNIKEY 1021 USB
* OMNIKEY 3121 USB
* OMNIKEY 3621 USB
* OMNIKEY 3821 USB
* OMNIKEY 6121 USB
* OMNIKEY 4321 USB
What you need
 Mac OS X 10.5 or greater
on Intel-Architectures (i386 x86_64).
 This driver supports our synchronous API, which
can be downloaded from http://www.hidglobal.com.
* MacOS 10.7 support added.
* Moved to universal binaries supporting MacOSX since 10.5 on 32 and 64 bit Intel platform.
* Use libusb-1.0 instead of libusb-0.9.X.
Q: What driver version am I using at the moment?
A: You can determine the driver version number
by having a look at the PCSCLite bundle directory
(for Apple PCSCFramework 4.0 this is
else /usr/local/pcsc/drivers): The bundle for
our devices is called 'ifdokccid<PackageSuffix>.bundle'.
The driver is also printing a version string
every time a reader is activated by PCSCLite:
This string can be found either in the system log
or on the console you started PCSCLite daemon from.
Q: I am experiencing problems using smartcard XYZ !
A: Please send an email to our support address
containing a description of the chain of events
which lead to the misbehavior (reader plug-in/-off,
SC insertion/removal, commands sent to the SC or
at least the program used to talk to the SC),
also include the name and ATR of the smartcard,
and add the PCSCLite log events (should be written to
your system log /var/log/messages or similar).
Your operating systems version may also be helpful.
Q: RFID reader and slot are registered twice.
A: Through a not traceable problem with the PCSC
framework the RFID slots are registered twice.
But both of the listed devices work correctly and
without any further problems.
Q: I started the PCSC daemon (pcscd) by myself, but it doesn't work!
A: First make sure that only one instance of pcscd is
running on your system. When you connect a new
card reader to the system, the security daemon
(securityd) starts a new instance of the PCSC daemon
and forces it to connect. With two pcscd instances
running the OS doesn't know which one should be used
what resides in conflicts.
When you force the securityd to stop you will not be
able anymore to start other programs and to login or
authenticate users until you restart Mac OS. If your
reader stays connected to the system, end all PCSC
daemon instances and start the pcscd in debug mode
if necessary. So no new instance would be loaded
by the system.
Q: After inserting a T=0 & T=1 smart card, the card reader device loses the shared mode status
A: Apple's Mac OS X PCSC Framework version and the
built in security daemon are starting predefined
smart card applications, which are trying to connect
to an inserted card. For an unknown reason, through
multiple tries of establishing a connection with the
T=1 protocol, the PCSC daemon gets a time out and
connection errors occur.
As one result the daemon doesn't reinitialize the
shared mode status of the device and blocks any
further connection attempts to the card, but it
does not affect the reader's availability.
Q: After bringing out Mac OS X from Standby mode the smart card devices are not available anymore
A: The Wake-Up procedure in Mac OS X forces all USB
connected devices to remap and reload their drivers.
Therefore the PCSC daemon tries to initialize the
plugged-in device with an already loaded driver,
which causes failures and the shutdown of the daemon.
Restarting the PCSC daemon or reconnecting the card
reader device re-initializes its resources and the
Q: How can I remove the driver bundle
A: If you want to remove the driver delete the directory
'ifdokccid<PackageSuffix>.bundle' within the directory
Q: Where is my open ccid driver
A: The driver installation routine creates a backup of the
open ccid driver named "ifd-ccid.bundle.tar.gz.bak"
within the directory "/usr/libexec/SmartCardService/drivers".
As far as i assume, it's about to send some APDU commands (Application Protocol Data Unit) to the SmartCard reader (kind of a request). My plan is to send them by Unix Terminal commands (Mac) and VB Shell commands (Win).
Both can be performed by TROI File PlugIn.