Uploaded image for project: 'Kuali Rice Roadmap'
  1. Kuali Rice Roadmap
  2. KRRM-134

Enhance KIM with additional features to support KPME and KS establising KIM as the central person repository (Person Registry)

    Details

    • Type: Rice Enhancement
    • Status: Closed
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Component/s: KIM
    • Labels:
      None
    • Rice Theme:
      Kuali Application Business Drivers
    • Priority Score:
      0
    • Impact if not Implemented:
      Each application will need to create their own registry extension likely resulting in duplication of the same task. Rice will fall behind other open source registry options that are being developed
    • Priority - KFS:
      No Priority
    • Priority - KC:
      No Priority
    • Priority - KS:
      No Priority
    • Priority - Rice:
      No Priority
    • Effort Estimate:
      Very High ~ 2500 hrs

      Description

      The KPME and KS teams would like to request that KIM be enhanced to include many of the features that would typically exist in a person registry. This may include items such as: Rich user interface for collecting person data, extension of the current KIM person data model to support more core person attributes, tools to search and identify potential matches for existing persons in KIM, tools to handle merging identities when duplicates exist. Below is an email from 5/24 where this topic was initially raised.

      ----------------

      In the past couple of months, the KPME team has been working to define the scope of KPME. You will find a high level diagram of our modules with some detail of each at https://wiki.kuali.org/display/KPME/KPME+Project+Documentation . One of the areas that we have some questions surrounds the collection of employee bio-demographic data and KPME's relationship with KIM.

      If we look at the relationship between HR and KIM today at IU, employee bio-demographic data is added to HR and is fed periodically to KIM to support those systems with a dependency on KIM. Given that HR employee data and Student Data at IU currently resides in a single database (PeopleSoft), the managing of duplicates and giving all people a single identifier is somewhat easy to manage. As we move to fully integrated Kuali systems, HR and Student will not be in the same database.

      My question is, what thought and planning has been given to the collection and maintenance of basic bio-demographic data for persons in KIM as it relates to other Kuali modules? One approach is for KIM to be the source of basic bio-demographic data that all Kuali applications use while each Kuali application adds attributes unique to their application within that application. That would imply that KIM provide robust tools for identifying if a person already exists, adding new persons, finding and dealing with duplicates, etc.

        Attachments

          Issue Links

            Activity

            Hide
            masargen Matt Sargent added a comment -

            There are 3 basic "components" of the KIM updates request that we have. They are listed in order of importance...

            1. Data Model – there are attributes that may be added columns to existing KIM tables or possibly a new KIM table or 2. This is something that both KPME and KS will need direction on in the immediate future (Q2 2012?). For KPME this does not mean that all is in place by the 2.1 release for example, but that the general direction is agreed upon.

            2. Search Match and Merging – A critical component of this is logic to allow users or applications to perform search/match logic of various setups on existing persons to ensure no duplicates are being created. Additionally tools to combine/merge duplicate records will be needed.

            3. Interface – while the basic, delivered KIM screens in Rice will likely be updated to allow the entry of any new items from #1, having hooks/APIs for applications to enter information with their own screens or documents (HR eDocs?) is also needed.

            Show
            masargen Matt Sargent added a comment - There are 3 basic "components" of the KIM updates request that we have. They are listed in order of importance... 1. Data Model – there are attributes that may be added columns to existing KIM tables or possibly a new KIM table or 2. This is something that both KPME and KS will need direction on in the immediate future (Q2 2012?). For KPME this does not mean that all is in place by the 2.1 release for example, but that the general direction is agreed upon. 2. Search Match and Merging – A critical component of this is logic to allow users or applications to perform search/match logic of various setups on existing persons to ensure no duplicates are being created. Additionally tools to combine/merge duplicate records will be needed. 3. Interface – while the basic, delivered KIM screens in Rice will likely be updated to allow the entry of any new items from #1, having hooks/APIs for applications to enter information with their own screens or documents (HR eDocs?) is also needed.
            Hide
            masargen Matt Sargent added a comment -

            Reassigning to Maury for the time being.

            Show
            masargen Matt Sargent added a comment - Reassigning to Maury for the time being.

              People

              • Assignee:
                masargen Matt Sargent
                Reporter:
                aaneal Aaron Neal (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: