Bigger than the MPI

In 2012, Value City Hospital initiated an organizational realignment when it added a third hospital to its healthcare system. Situated in one county, the health system also included four physician practices and two urgent care centers. Value City knew that the integration and management of master data would be key to the success of the organization. The master data subject areas considered the core of success for the program included patient, supplier, employee, and provider master data.

In 2013, a master data management program was created that included a data governance council made up of senior-level stakeholders. The mission of the data governance council team was to align and consolidate people, processes, and technologies. This was followed by the establishment of data stewardship committees for each of the core master data areas with one central team managing master data delivery across all information technology projects.

The first task was for each data steward committee to evaluate the way its core master data were created, read, updated, deleted, and searched (CRUDS). For example, patient master data are created at the time of a patient's first visit to any of the health system's facilities; it is read based on the contextualized views which are based on the role of the viewer; updates can occur for name, address, and phone number; patient master data are never destroyed; and the master data are searched by the R-ADT system and clinical and financial management information systems.

After conducting the CRUDS analysis, each set of master data was evaluated in terms of its metadata. This included attribute names, data types, allowed values, constraints, default values, definition, and data sources. During this process, the teams found that there were multiple data sources that needed to be reconciled and that the metadata from these various sources were not the same. For example, the three clinics and two urgent care centers had different master patient indexes than the two hospitals. To reconcile this problem, each data steward team developed a model for its master data. This included attributes in use, their data type, allowed values, and so on. The source systems were then mapped to the data model.

Once the master data attributes were agreed upon and source systems mapped, the next step was to create a master list by cleansing, transforming, and merging the source data. Once the teams were assured that a clean and consistent master data list was achieved, the master data could be uploaded and maintained in the architecture solution decided on by the data governance council, which in this case was a transaction hub implementation.

Discussion Questions

What benefit did development of a CRUDS evaluation provide?

What is the benefit of a data model for master data? Would this data model be different than the logical data model for a relational database?

How do you suppose agreement on the final master data attributes was achieved?

Why do you think the organization choose a transaction hub configuration?

What was the role of the data steward committees after consolidation of the master data?