IT Services is a broker and consumer of university data about people, accounts, groups, and organizations. Much of this data comes to IT Services from the central systems and via the Registries run by Administrative Systems (AS). Where there are gaps in this data, IT Services will seek to either enhance existing data feeds or to integrate data downstream of AS. This can mean either agreeing to standards that allow university data to be exposed as services, replicating data into aggregation or downstream systems, or both. The term "directory" is used in this document to refer to the collection of services that publish person, account, organization, and group information, and not necessarily an LDAP (Lightweight Directory Access Protocol)-based system. In the medium term, IT Services wants to provide a unified front end and a service interface (or set of service interfaces) to data from the University, from LPCH (Lucile Packard Children's Hospital), and from SHC (Stanford Hospital & Clinics). Our long-term goal is to provide a collection point (or service standards) and access control for attributes provided by data sources around the Stanford community.
The University, as well as its two affiliated hospitals, are served by the IT Services Operator Services Center (OSC). Approximately 1.4 million calls are processed annually through the call center, and it is important that the right tools be available to support that volume. Getting accurate information about both people and organizations is required to provide that level of efficiency. While IT Services does have an LDAP tree for organization data that is the back end for Stanford Org searches (in StanfordWho), current constraints on the Org Manager limit how and where that data is displayed. In particular, the Operator Services Center does not have the data access they require. IT Services aims to solve both the university problem and the SHC/LPCH problem, although the paths for each may be quite different. IT Services plans to to collaborate with the organizations that the call center serves to create a common data policy regarding directory information and how it is displayed to operators, versus how it may be printed or displayed to the public. Creation of the common directory will ultimately serve the interests of the entire campus and its affiliates, as well as the tens of thousands of members of the public who use our services. An inter-organizational governance group will be chartered to support the continuing automation of directory maintenance, as well as to recommend/approve data policy changes and/or procedural changes that may be needed.
- There is no current organization information in the systems used by the OSC. The directory system (Amcom) used by the call center that serves LPCH, SHC, the SOM (Stanford University School of Medicine) and the university contains only the organization data created when the system was implemented a decade ago, as well as manual records that the agents create as they learn of a new number or a change.
- University person data is obtained from a nightly feed through the Person Registry. SHC and LPCH person data is obtained nightly with a feed from the medical center. The problem with these mechanisms is that privacy flags do not function properly with Amcom, frequently denying call center agents information that they should have to accurately process calls. In addition, information in those two data feeds is not uniform.
- All person data is brokered through the person registry, which, while it contains canonical information about a person, publishes a relatively narrow attribute set.
- Multiple systems and disparate data policies across the organization lead to challenges for both communication and integration efforts.
Because of the high volume of calls processed in the Operator Services Center for the two hospitals as well as for the university, it is apparent that improvements to the way directory information is created and maintained will have a significant impact on many stakeholders. Accurate and efficient call handling is essential to effective clinical services. It also has the potential to impact Stanford's image with the 1.4 million individuals who call every year. Because the current state is comprised of multiple directories as well as data policies and formats, it will require a chartered project team with executive and financial support to achieve success. However, with that in place, providing a unified interface to university, SHC, and LPCH directory data is a 2011 goal.
The goals around a community-sourced directory should follow this work as well as the work on the account services migration. Improved workflow systems are required to support authorization for attribute release, given the distributed data owners of a community-sourced directory service.
- Eliminate the constraints in the organization data that limit the information available to the OSC staff.
- Work with Administrative Systems to either encourage the use of Org Manager among SHC and LPCH departments, or build a more complete data feed from canonical systems in the hospitals to the Organization Registry.
- Work with Administrative Systems to re-examine the privacy policies for person data transferring between SHC, LPCH, and the central university systems. Make sure that the resulting policies are applied consistently. Ensure that the OSC and other vetted service providers have access to person data regardless of privacy settings.
- Integrate person and organization data into OSC applications.
- A unified directory or common query interface to data for Lucile Packard Children's Hospital, Stanford Hospital & Clinics, the School of Medicine, and Stanford University to house person (faculty, doctor, contractor, and staff) and organization data. (Note: Patient information is not part of this effort.)
- Create a directory structure and attribute access workflow where information providers from around the university can contribute and govern access to data sourced locally for use by other applications. This may be an extension of the Registries infrastructure done in concert with Administrative Systems, or may be an effort downstream.
- An inter-entity directory governance group to review and authorize policy and procedural changes as needed.
- Obtain support from CIOs (Chief Information Officers) of the four organizations.
- Obtain a data policy agreement among LPCH, SHC, SOM and University IT Services, including shared privacy settings.
- Broker the conversation between Administrative Systems and LPCH, SHC, and SOM to determine information delivery methods.
- Work with Administrative Systems on the creation of web services interfaces for person and organization data.
- Determine whether IT Services should be populating the Organization LDAP tree based on the web services interface, and re-write Org Slog if so.
- Build an adjunct container in OpenLDAP for additional person attributes not sourced from the Registries.
- Fully populate the organization directory with Org contact info.
- Build or update feeds for person and organization data into OSC systems.
- Charter a project to implement the new directory framework.
- Create a governance group to assure continued support and maintenance of the new directory.
Measures of Success
- University call center agents can process calls accurately and promptly without the need for repeated attempts to locate the correct organization or person.
- Information in the Directory is presented in a consistent manner with common, accepted standards for display of information to the call center versus the public.
- Accuracy and completeness of web-based and printed directories is enhanced.