Eyefinity Interface

1.0 Overview

The Rx-Universe Eyefinity interface provides a means whereby Rx-Universe retrieves orders from the Eyefinity website, converts them to an Rx-Universe format, and processes them, putting them directly into the Rx-Universe order entry system.

1.1 Restrictions of the Eyefinity Interface:

            The Eyefinity website order entry does not provide for entry of the following items – they are represented in comments on the order; therefore Rx-Universe can not import these pieces of information automatically:

1. Single-eye jobs can not be entered

2. Upper add cannot be specified for occupational multifocals

3. Prism thinning on progressives cannot be specified (lab default will be used)

4. Frame information is basically free-format – this means that the lab must maintain a translation table of the common frame names, colors and manufacturers, but if the dispenser changes the spelling of any piece, it will not match when brought into Rx-Universe.

5. Addons such as AR coatings, SR coatings, are specified in Eyefinity by phrases.  While these phrases are pre-populated on the website, the user can change the spelling of any phrase.  This can result in non-matches for addons at the lab, and hence an unvalid job which must be modified at the lab.

6. The dispenser does not have the ability to specify that a particular blank diameter nor manufacturer be used for lenses.

1.2 Requirements of the Eyefinity Interface

Rx-Universe version 7.40 or later is required to run the Eyefinity interface.  Since Rx-Universe runs as a thin client application on the network, the network server must have internet access in order to obtain jobs from the Eyefinity website.

The lab is responsible to maintain the translation of frame manufacturers, shapes, colors and models to those used in the lab’s inventory system and tracing database, as well as the translation of addon codes as used in the lab.

Lens codes are maintained by OLSS and updates are available from the OLSS website from within the Eyefinity translation screen in Rx-Universe.

2.0 Setting Up Eyefinity to Rx-Universe Translation Data

There are 5 translations of codes that take place between Eyefinity’s information and that used within the lab.  These five types of translations are:

1. Customer numbers

2. Billing names

3. Lens codes (identifying material, style, etc.)

4. Addons (identifying tints, coatings and services)

5. Frame information (frame name, color, etc.)

6. Lens description (from the orlso tag - added in version 7.49)

All translations are done in the Eyefinity Translation File in Rx-Universe; each type of translation is described below.  All Eyefinity conversions are accessed from “Remote”, and then “Eyefinity Translations”. 

Open

In the example above, the second column of the browse window (headed “Type”) indicates the type of translation record:

            A – addon code – from Eyefinity codes to Rx-Universe addon codes
            B – billing name – specifies private billing, or different price list
            C – customer code (Efan to Rx-Universe account number)
            F – specifies frame part
            L – lens code (to Rx-Universe material, style, tint, treatment)
D - lens description (to Rx-Universe material, style, tint, treatment) - added in version 7.49

2.1 Customer Numbers

Because Eyefinity accepts orders from doctors and dispensers all over the country, Eyefinity assigns customer numbers to each doctor and location.  The lab must take that Eyefinity identifier and translate it into the appropriate customer number at the lab, either for billing (in the case of a non-VSP order), or for shipping, in the case of a VSP order.

When processing jobs, if the specified Efan number does not exist in the translation table, it is automatically created, with a blank Rx-Universe customer number, and the order will be saved unvalidated.  The order can later be modified to enter correct billing or shipping information, and the Eyefinity translation table should be modified as well for future orders from that customer.

A customer translation consists of the following information:

Open

Eyf Code:        - is the Efan number assigned by Eyefinity to the dispenser or doctor.
Part Type        - “C” specifies that it is a customer translation
Acct #              - is the Rx-Universe customer number that corresponds to the Efan number.
Description:    - free text description

Please note that proper translation of Efan to accounts is critical – improper translation may result in billing and/or to the wrong account!

2.2 Benefit Names

Eyefinity sends a benefit name as part of each job.  Which benefit names are paid for by VSP and which by the patient are determined by each lab’s contract with VSP.  Therefore, the lab can specify that certain benefit names are private pay, or use a different price list.

The list of benefit names is defined by VSP and each is already in the lab’s translation table (although of course, VSP has the right to add new names at any time).

The pertinent fields for “benefit name” are:

Eyf code:         The text of the benefit name
Conversion type:  “B” for benefit name (Price list option)
Private pay:     A Y or N flag; if “Y”, jobs with this benefit will be billed to the doctor, otherwise jobs with this benefit will be billed to VSP (unless the job is specifically created as a private pay job).
Price List#:      If the benefit plan initiates different pricing, the price list number to use for orders with this benefit can be specified.  If left blank, the regular price list for the billing customer will be used (whether VSP or the dispenser).
Description:     Free text description

2.3    Lens Codes

Eyefinity uses a numeric code to represent lens products.  For example, lens code 2599 is a Plastic AO Easy progressive; code 2137 is a Poly SV Brown3 Transition lens from Younger.  There are thousands of these codes used by Eyefinity, and each code must be translated to the equivalent Rx-Universe product(s).

OLSS provides a table of these Eyefinity codes already translated to the standard inventory codes used in Rx-Universe.  While it will not normally be necessary for a lab to ever modify an existing lens item, nor create additional ones, access to the codes is permitted for viewing.

Lens records consist of the following fields:

Eyf Code:        The numeric code used by Eyefinity
Conversion Type:   “Lens” for lens code
Lens Style:      A valid Rx-Universe lens style code (in this case PHYDRX for Physio DRX)
Lens Material  A valid Rx-Universe material code (in this case C for Poly)
Tint:                 An optional field, if present must be a valid Rx-Universe tint code (in this case GY3 for Gray 3)
Pretreat:           An optional field, if present must be a valid Rx-Universe treatment code (in this case TR8 for Transitions VIII)
Manuf:            An optional field, if present must be a valid Rx-Universe manufacturer code (blank in this case)
Description:     Free format text description
Thickness:       Can specify a particular thickness for the job for this lens code

Rx-Universe provides an easy way of updating lens codes from a centralized database administered by OSI.  See the next section entitled “Updating Lens Codes” for information on this.

2.3a   Lens Descriptions (added in version 7.49)

Eyefinity has some codes intended to be used when ordering products not available through the VSP program, or proprietary products. In such cases, a code such as 1210 is sent, which specifies an “other” Polycardonate lens. A description can be sent in the file indicating which specific lens is to be supplied, and the lab can translate that to their preferred lens product. Note that this lens description is often free-text, so it can be sent from the Eyefinity website in different ways - the lab would need to translate all the different possible values in order to translate the values sent.

For example, the payload file from Eyefinity might contain:
orlsc=1210
orlso=Basic progressive clear

Code 1210 is defined, by Eyefinity, as:

The “POLY 5” in the remarks indicates the code designates a Poly lens, that is progressive (the 5), so any further details can be sent in the orlso tag. In this case, if the lab opted to use a lens style called “MYPROG” for the progressive design, they could set up a lens description record as follows:

Now, when the order is received, the orlsc=1210 will translate to Poly, and the orlso tag will translate to a MYPROG lens with a scratch coating.

Note that if the ECP sends “Basic progressive coated”, this would be a different description, and the lab would have to maintain both values for the incoming text to be translated in all cases.

2.4    Updating Lens Codes

Eyefinity adds new lens codes approximately monthly.  Each of these codes needs to be cross-referenced to the equivalent Rx-Universe codes for lens material, styles, tints and pre-treatments.  OLSS will translate new codes as they are released by Eyefinity and make them available to Rx-Universe labs using the Eyefinity interface.

Rather than distributing these codes by CD or other media, OLSS has chosen to make them available via a web-update.

To obtain the latest lens codes from OLSS, from the Eyefinity Translation browse window, the button with the picture of the globe will access the OLSS cloud server for translations:

Click this button, and you will be asked a question similar to the following:

If you respond Yes, Rx-Universe will access the OLSS website, and automatically update your translation table with both new lens codes and any changes to existing lens codes. 

During the update, you will see a screen similar to the following:

Should you get an error similar to the following:

This indicates that Rx-Universe was unable to connect to the OLSS web server.  Check to ensure that your internet connection is working – if it is, please contact Rx-Universe Technical Support to advise that the lens update file is not available over the internet.

2.5    Addon Codes

Many different codes are provided by Eyefinity which identify different characteristics of the order.  Some of these codes are for billing purposes, others affect the processing of the lens.

Each of these codes sent by Eyefinity can be translated into an Rx-Universe addon code, tint code, and/or pretreatment code.

Eyf code:         This is the code that comes from Eyefinity (in this case “QT CRIZAL ALICE(A”)
Conversion Type:    “Addon”
Addon-code:   A pricing addon code that is applied on the pricing page.
Pretreat:           Applies a code to the Rx for blank selection.  Some codes, such as ARC, can be set up as optional pretreatments, with a corresponding pricing code.  Thus, whether a lens is selected with the pretreatment or not, proper pricing is applied to the job.
Tint code:        As with pretreatments, applies a code for tint for blank selection.
Description:     Free text description.

There are several types of information in an Eyefinity order that CAN result in an addon code.  Billing names, addon codes, lens color code, lens tint code, all of the MiscOption and MiscOptionDesc fields, and group comment codes.  Many of these codes (L064, AD, JA, etc.) do not need to be translated into Rx-Universe codes because they either do not affect processing, or are already specified in other parts of the order.  However, it is the lab’s responsibility to review the codes and ensure that proper translation is done to the Rx-Universe pricing codes used by that lab.

If a code exists without a translation being done (for example, L064), that code will be brought into Rx-Universe and saved as an addon, which will cause it to print on work tickets, etc., to ensure a service isn’t missed. If the code is a billing code only and doesn’t need to exist as an addon, setting the “Code” field above to “ZZZZZZ” will cause the code to be omitted from the addon list on the order.

A note is required concerning tints. Eyefinity uses two billing codes to indicate tints - MN (solid tint) and MP (gradient tint). With the billing code, they can specify the colour of the tint in two ways,

If they send the tint in the ortc tag, Rx-Universe looks for a translation in the table of MN (or MP) plus the tint as specified in ortc. For example, a Brown 2 tint might be sent as a solid tint, in which case Rx-Universe would look for a translation for “MN BROWN 2”, as follows:

The other way the tint can be specified is with a combination of ortc=other, and then the tint description placed into ortnt as a free-text description. In this latter case, Rx-Universe will look for the addon to use for the MN or MP code by itself, and then place the tint description into the addon remarks on the order itself:

And on the order itself:

2.6  Frame Information

Translation of frame information is a particular challenge with Eyefinity jobs, because Eyefinity allows free-format descriptions of frame information to be made on the website.  Thus, a manufacturer such as Safilo may come up by default as “Safilo” when entering the order on Eyefinity, but the user has the ability to change that.  If Rx-Universe is set up to recognize “SAFILO”, but the order comes over with “SAF”, “SAFILLO”, “SAFL”, or some other spelling, Rx-Universe will be unable to match the code and properly translate it.

When orders come over from Eyefinity, Rx-Universe will attempt to find a trace record with the frame information provided, after trying to translate the fields.  If Rx-Universe fails to find a match, the nominal measurements for the frame will be used as the frame measurements for the job.  If the job is a “Frame to Follow”, the job will be validated.  If however, the job is a “Supply Frame” job, then the order will be saved Unvalidated, and the lab will have to modify the job to put it into production.

Because a frame is made up of multiple descriptions in Eyefinity, each of frame name, frame manufacturer and frame color can be translated.  Rx-Universe will then build a frame description from those parts, combined with the eye size and bridge size, and attempt to locate an inventory record (if supply frame) and a trace record.

Note that any frame piece can be translated to any combination of Rx-Universe manufacturer, name, type, color and eye, bridge and temple sizes.

Eyf Code:        The frame piece description sent from Eyefinity
Part Type:        “F” for frame piece
Frame Manuf: The Rx-Universe manufacturer to use for this piece
Frame name:   The Rx-Universe frame name to use for this piece
Frame type:     The Rx-Universe frame type (groove, etc.) to use for this piece
Eye:                 The nominal eye size of the frame
DBL:               The nominal DBL or bridge of the frame
Temple:           The nominal temple length of the frame
Color:              The Rx-Universe color to use for this piece

3.0    Setting Eyefinity Communications Parameters

Rx-Universe uses an internet connection to download orders from Eyefinity using ftp (file transfer protocol).  The computer that Rx-Universe is running on (usually the server, running as a thin client application), must have an active connection to the internet.

Each lab is assigned a user name, password, and a base name for file naming, by Eyefinity.  These values are stored in Rx-Universe on the “Eyefinity Options” screen. 

From the main menu, select “Remote”, then “Remote Order Processing”.  The following screen will appear:

Make sure the “Use Eyefinity Interface” option is checked, and then select the “Eyefinity Options” button.  If you cannot select the Eyefinity checkbox, you may not be registered as an Eyefinity lab – please contact Rx-Universe Technical Support for assistance.

Once you select “Eyefinity Options”, you will be presented with a screen similar to the following:

Eyefinity pause (minutes):      Selects the interval to check Eyefinity for orders.  This should be set to some delay to prevent Rx-Universe from constantly checking the Eyefinity ftp site.
Create Eyefinity Log:             If checked, Rx-Universe will create a file EYEFIN.LOG which contains a log of each step in the communication process.  This file is located in the default Rx-Universe folder.
Send shipping info in status: If checked, will send shipping info such as tracking number with the Eyefinity status updates.
Use WinScp for communications: This uses an alternative program for file transfer which may be required based on lab firewall settings.
Use VisionStar encryption key:  This changes the encryption information used on files sent to/from Eyefinity. This is assigned by Eyefinity.
User name:                              This is the login name for Eyefinity, assigned by Eyefinity.  It is case-sensitive.
Password:                                This is the password assigned by Eyefinity.  It is case-sensitive.
Base file name:                       This is also assigned by Eyefinity.
VSP account #:                       This is the lab’s account number for billing to VSP.
Eyefinity lab ID #:                   This is also assigned by Eyefinity.
Alert Email: If set any differences between Eyefinity’s expected WIP orders and the actual WIP orders will be sent here.

4.0    Processing Eyefinity (and other) Remote Orders

Processing of Eyefinity orders is consolidated into the Remote Order Processing module of Rx-Universe.  From the “Remote” menu, choose “Remote Order Processing”, or start the automated remote order processing screen on the server.

Initially, and at intervals specified by the “Eyefinity Pause” time, Rx-Universe will initiate a connection to Eyefinity and download any orders waiting for the lab.  When this happens, you will see a screen similar to the following:

Please note that the exact messages shown will depend on the lab’s user name and set-up.

Once the Eyefinity jobs have been downloaded, they are pre-processed into regular Rx-Universe remote order files, and placed into the incoming order folder for processing.  (This is usually a folder called OMICSTX on the working drive).  These files will be named:

Account.Ennnn

Where Account = account number being billed to
Nnnn = a 4-digit sequential number (stored in the VCAREM Special Number)

As each order is processed, it is placed into the Active Orders table.  If the order was processed (blanks could be selected, pricing was done), a work ticket is automatically printed.  If there were any problems with the order, the order is saved unvalidated for later review at the lab.

5.0    Sending Status Back to Eyefinity

Eyefinity provides the ability for the lab to send back status on jobs, permitting the dispenser to see the status of their jobs in the lab.  Rx-Universe allows the lab to control how much information to send back to the dispenser.

As jobs move through the lab, they are tracked at devices and scanners as part of Job Tracking.  A job may pass through many stations between the time it arrives and the time it is complete.  Rx-Universe allows the lab to choose which stations will trigger a response back to Eyefinity that the job has moved.

On the Job Station file, a field allows that field to be marked as an Eyefinity station (or reporting point).  Since Eyefinity supports only a limited number of status codes, the status code can be selected from the dropdown list on the screen for each job station:

To ensure proper reporting of Status back to Eyefinity, the lab needs to ensure that the job tracking stations are set up to properly indicate when jobs pass through each Eyefinity stage of the lab process.

6.0    Viewing Eyefinity Orders (valid and unvalid)

Orders received from Eyefinity (and other sources) are stored in the Active Order table along with other orders.
On the order entry screen, the source of the order (if not manually entered) is shown as follows:

The original order that came from Eyefinity is always available to the user.  From the customer service screen, with the order in question highlighted, use right-click, “View”, “View Raw Order File” to see what Eyefinity sent:

This is a standard scrollable list box – you can use your mouse or keyboard to scroll up and down to see the entire original order.  The first portion of the order, to the EOJ=END OF JOB line, is the order that Rx-Universe created from the Eyefinity order (in standard Rx-Universe VCA/GIF format).  Everything after the EOJ line is the text as it came from Eyefinity.  While we recognize that labs won’t often have the information to interpret all of the information shown, it is useful to verify customers sometimes (especially if an order has been received through Eyefinity, in error, from a customer that the lab doesn’t have).  It may also be useful when working with technical support at either Eyefinity or Rx-Universe to resolve issues.

7.0 Daily Process for Eyefinity Orders

1. Process jobs from Eyefinity throughout the day (this will be automatic in many cases).

2. Check the Eyefinity Translation table for new entries with no corresponding Rx-Universe translation.  Customer records, Lens codes, and Addons should be checked regularly.  Frame items should be checked if the lab supplies frames for orders.

3. At least monthly, run the option to update lens codes from OSI web site.

8.0 Checklist Before Implementing Eyefinity Interface

1. Install Internet connection from server (high speed is best).

2. Obtain list of Efan accounts that have placed orders within the past 60 days, from Eyefinity.  Build Customer translation file with Efan and Rx-Universe account numbers.

3. Set up any addon codes that will be coming from Eyefinity - these are usually a combination of the pricing code (QT, QN, etc) plus the description of the coating. A list of current addons is released by Eyefinity monthly.

4. Obtain your Eyefinity basename, username and password for their ftp site.

5. Set up the Eyefinity customer number (the account you use to bill Eyefinity)

6. Set up the VSP price list if desired (VSP pays what they calculate is due based on the job as entered by the ECP, not based on what the lab sets up in pricing).

9.0 Enhancements in March 2007

Eyefinity has made several enhancements to the interface effective 27 March 2007:

1. Eyefinity jobs now send the B, ED and Circumference for a frame

2. New status 93 to identify jobs waiting for a frame

3. New frame status field indicating whether a frame has been received for a frame to follow order.

4. Ability to send back shipping information with status on Eyefinity jobs

In addition, there are other enhancements which will be forthcoming from Eyefinity in the near future – Rx-Universe has been enhanced to support these features as of version 6.00.58, in anticipation of their release by Eyefinity:

1. The dispenser will be able to specify which eyes are to be done for an Rx (both, left only, right only, or neither).

2. The dispenser will be able to request a particular diameter lens blank to be used.

3. The dispenser will be able to request that a stock lens specifically be used for a job.

B, ED and CIRCUM measurements can now be entered by the dispenser and submitted to the lab.  These fields are now fully supported by Rx-Universe and no change is required by the lab.

Waiting for a frame - A new Eyefinity status has been added – status 93 indicates that a job is waiting for the frame to be sent by the dispenser.  To allow a lab to easily identify these jobs, set the Eyefinity frame status to 93 for the job station that is used to identify orders waiting for frames:

Frame Received status - A new frame status can now be sent to Eyefinity indicating whether a frame has been received for a frame to follow job.  To do this, the lab must have a job tracking station that indicates when a frame is actually received.  This station would be set up similar to the following:

Note the field towards the bottom right “Frame Received” – when a job is scanned to this station, Rx-Universe marks the order as the frame having been received. To indicate that you want to send this status back to Eyefinity, ensure the appropriate option is checked on the Eyefinity setup screen (under Remote Processing):

Shipping information - Eyefinity can also now accept shipping information back from Rx-Universe.  To do this, a lab must use the shipping method field, on the account and/or order, to actually identify which shipper is used for an order.  If the “Send shipping info status” field (above), is checked, then this will be sent back to Eyefinity as the shipper.  While Eyefinity also accepts a tracking number, Rx-Universe does not store this nor send it back.

10.0 Description of Communications

Eyefinity makes orders available, and receives status information, by means of encrypted files on their ftp site.

The root ftp site is ftp://echannel.eyefinity.com, files to be transferred are contained in a subfolder “prod” under this folder.

The login credentials (name and password) are different for each lab, and are provided by Eyefinity.  Similarly, each lab has a different basename for file transfers, and this is also provided by Eyefinity. 

Rx-Universe uses a program called omftpcrypto.dll to communicate with the Eyefinity ftp site and encrypt/decrypt the payload files as required. Note that omftpcrypto.dll requires a Visual Basic component called msinet.ocx. Previous versions of Windows installed this by default, but this is no longer true with Windows10. Beginning with the version 7.47 InstallShield, Rx-Universe will install the msinet.ocx component in the Rx-Universe folder, but if you have a version of Rx-Universe for which you get either of the following when trying to run the Eyefinity interface:

Follow these steps:
1) open a command prompt windows with administrator rights
2) go to the root Rx-Universe folder (ie C:\RXUNIVERSE}
3) type regsvr32 omftpcrypto.dll
4) you should receive a message:

5) copy the msinet.ocx file to the same folder (please contact Rx-Universe support if you need this file)
6) type regsvr32 msinet.ocx
7) you should get the confirmation message:

The interface with Eyefinity should now work.