The question was put to me “When will the IT industry provide reusable clinical and administrative data warehouses for the Medicaid enterprise?” It was a thought-provoking question that was well worth considering.
Currently the healthcare insurance and provider industries are guided to target reporting that is defined by government regulation and motivated by financial incentives. These specific measures do lead to the creation of tracking and reporting system scoped to meet the requirements for reimbursement from government programs. This does not lead to a comprehensive data warehouse model or analytic platform for the Medicaid enterprise.
Federal government reporting regulations and the new procurement rules for “modularity” do not strictly require a comprehensive data warehousing platform. With an overwhelming task of re-doing MMIS systems, States are struggling with merely defining “modules” and ensuring the basic required functionality is being achieved. Though the business and policy people recognize the need and value for analytics, those are not “requirements” and, thus, are pushed off for future scoping. Unfortunately, that means most of the early modular MMIS EDW RFP’s have been dominated by traditional reporting measures and pre-written applications for tracking statistics, rather than requirements which will set the States up for future flexibility and growth.
The RFP’s lack serious and specific requirements that focus on the future extensibility, data normalization and virtual views of data within a data warehouse platform. Thus, the vendors responding to these RFP’s, in order to provide competitive bids, must often use technologies and infrastructures which are minimally capable of providing reports and data aggregation.
Existing HHS (Health & Human Services) model standards and systems
There are existing data models or standards (for example, MITA, National Human Services Interoperability Architecture (NHSIA) and National Information Exchange Model (NIEM), that attempt to serve as a foundation for a state based HHS data warehouse. While these are a start, they fall short of what is needed to define a data model.
- MITA specifications serve as a good “ruler” to measure the content and capability of a data model for HHS. Running MITA scenarios against the data model in the form of a “data scenario” can provide valuable insight on how the model is designed to work.
- The NHSIA architecture framework does not lead to a granular solution that is specific enough to generate a standard comprehensive HHS data model.
- The National Information Exchange Model (NIEM) serves as a basis for information exchange, but does not lead to a data warehouse model. It only helps determine the requirements needed for development of a data model.
There are barriers to producing a common HHS data model. Some barriers are:
- The lack of maturity in the Health and Human Services information technology infrastructure and industry groups.
- The desire of software vendors to gain and hold market share for their proprietary products.
- The scope and funding of development projects for specific state HHS systems are impermanent and inconsistent due to political issues. Data model process can take many years to complete and it is hard to ensure that money will be available as administrations change.
- The U.S. historical and constitutional based desire for local control by states and municipalities is a foundation that limits the ability of a Federal government to dictate standards and systems. Consequently, governments other than the U.S. may be more likely to define and force development of a standard data model.
Administration of health and human service programs by states and municipalities creates disparate requirements for standards and systems. From the perspective of a commercial IT development company the market is sparse and fragmented. The funding of development projects for specific HHS organizations can be impermanent and inconsistent. For these reasons and others, the market place has not developed comprehensive standard data models.
How might these barriers be overcome? How might a common data model be created and adopted? I will suggest my favored solution in my part two of this blog.