McKesson produces many Healthcare applications including Series 2000, STAR, Care Manager and Image Manager. There are many more applications in their portfolio, but these are the prime applications that we find at healthcare facilities when we present eTrust Single Sign-on and Admin.

Each of these applications incorporates their own user and group management paradigm and authorization and authentication tables.

This document addresses the Series 2000 application with regards to building a custom option for provisioning users from eTrust Admin. Ken Lee and Mark Wettlaufer traveled to Lake Mary, FL to meet with the Series 2000 Development Group on 10 May 2004 and came away with a positive feeling about the chance of success in developing a custom option.

Key findings for Series 2000

• Runs on the iSeries AS/400 hardware from IBM
• Utilizes the iSeries DB2 UDB database
• User tables address authorization (ACLs) while authentication is handled by OS/400 security
• Application is heavily customizable and dynamic based on client needs
• Security Code is another name for the password sting for the Series 2000 account and is currently stored in clear text with future plans for some sort of encryption
• Password refers to the OS/400 account password
• A user within Series 2000 is uniquely identified by:
  • library name for database instance
  • hospital code
  • 4 character “printed code”
• All user information is primarily stored in three (3) tables and has a very simple structure
• Client customizations (the dynamic nature of the application) are stored in fixed, known table names and/or “flat” files
• Database tables accessible from Win32 applications with an ODBC connector (there is also a JDBC connector)
• A user is defined to belong to a group code AND can have additional individual function codes authorizing additional functions

Concerns for developing a Custom Option for eTrust Admin

• Dynamic / customizable nature of Series 2000 – every Series 2000 environment will be different, so our option needs to be able to read the tables / flat files where these customizations are stored and be dynamic / flexible
• Sanity edits – our option will need to emulate the input edits performed by the user management interface of Series 2000. For example, individual users can be assigned certain rights based on the nursing station or clinic codes being used.       Series 2000 performs a “sanity” check to ensure that a nursing station or clinic code is already defined in the system before being assigned to a user. Since we will be accessing the tables via ODBC, we could store anything in any field, but that “garbage data” could have adverse effects on the system
• Security Code storage – currently in clear text so this is not a concern but we will require commitment from McKesson to either disclose the encryption algorithm / key or provide a trusted connection or API mechanism once they implement encryption of the Security Code.

Where do we go next? Recommendations

Series 2000 looks like a very good candidate for developing a custom option for eTrust Admin. CA has many common customers with McKesson that have Series 2000 and therefore, have the pain of user management within this application. A custom option would allow our common customers to achieve all the values that eTrust Admin can provide.

The interface appears to be simple. We can get to the tables via ODBC and from McKesson’s own admission, the user tables are an extremely simple format.

To proceed, we should

• Secure the source for the one custom option being developed for Cingular Wireless (if legally possible). The CARE option at Cingular seems like it could be a very good model for the Series 2000 option because CARE is also table driven (the dynamic, customizable nature of Series 2000)
• Arrange another meeting with the Development Group at McKesson to arrange transfer of user table schemas and source code fragments of the “sanity” edits
• Arrange a contact point at McKesson for questions as we proceed
• Arrange for testing at McKesson
• Develop a prototype of the management screens within the Admin Win32 GUI to demonstrate to McKesson and two or three prime customers for comment
• Target two or three prime customers for beta testing this option
• Secure agreement from McKesson to be ready to provide an API or disclose the encryption algorithm / key once they institute Security Code encryption