Every mid-to-large-sized healthcare organization will at some point need an enterprise data warehouse to consolidate data from its many source systems. The first question most will ask is, “Do I build it from scratch or buy a model?”
For some organizations, the answer to this question is simple and obvious. For others, it may be the source of internal debate on whether someone else can create a model that will address their nuances. Some will argue that a pre-built model will save time and money and should be explored as an option, while others may curb discussions due to the belief that their electronic medical records vendor already has it figured out.
In this webinar, we explored the pros and cons of building your own data model vs. buying one and looked at real customer use cases to help weigh the pros and cons of this critical enterprise decision. Topics included:
-How experience plays into the equation
-Which solution delivers value more quickly
-Which solution helps reduce the risk to the organization
-How easy is it to integrate other solutions
-How the decision to build vs. buy can impact your internal team
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Healthcare Enterprise Data Model: The Buy vs. Build Debate
1. Thank you for your time
and attention today.
Please visit us at Perficient.com
Healthcare Enterprise Data Model:
The Buy vs. Build DebateNovember 18, 2014
facebook.com/perficient
twitter.com/Perficient_HC
linkedin.com/company/perficient
2. Perficient is a leading information technology consulting firm serving clients throughoutNorth America.
We help clients implement business-driven technology solutions that integrate business processes, improve worker productivity, increase customer loyalty and create a more agile enterprise to better respond to new business opportunities.
About Perficient
3. 3
•Founded in 1997
•Public, NASDAQ: PRFT
•2013 revenue $373 million
•Major market locations:
•Allentown, Atlanta, Boston, Charlotte, Chicago, Cincinnati, Columbus, Dallas, Denver, Detroit, Fairfax, Houston, Indianapolis, Minneapolis, New York City, Northern California, Oxford (UK), Philadelphia, Southern California, St. Louis, Toronto, Washington, D.C.
•Global delivery centers in China and India
•>2,200 colleagues
•Dedicated solution practices
•~90% repeat business rate
•Alliance partnerships with major technology vendors
•Multiple vendor/industry technology and growth awards
Perficient Profile
4. BUSINESSSOLUTIONS
Business Intelligence
Business Process Management
Customer Experience and CRM
Enterprise Performance Management
Enterprise Resource Planning
Experience Design (XD)
Management Consulting
TECHNOLOGYSOLUTIONS
Business Integration/SOA
Cloud Services
Commerce
Content Management
Custom Application Development
Education
Information Management
Mobile Platforms
Platform Integration
Portal & Social
Our Solutions Expertise
5. Healthcare Practice
Strategic Partners
Experts in Consumer-Driven Healthcare Technology
HEALTH PLAN
PROVIDER
Connected
Health
Business Intelligence
and Analytics
Interoperability & Integration
Information
Exchange
Regulatory
Compliance
Solutions & Services
CONSUMERS
Select Clients
Global Delivery Centers/Offshore Delivery
Domestic Delivery Center
6. David MeintelDirector of Healthcare, Perficient
David has 20 years of experience in data warehousing and analytics in a wide range of industries. Focusing this experience in the last 4 years exclusively on the healthcare industry, David has worked with a large number of provider and health plan organizations to assist them in better leveraging their data assets.
Our Speaker
7. Agenda
•Brief look at the challenge in healthcare causing the need for a data warehouse
•Evolution of the solution to the challenge
•Discuss key factors in the decision to buy or build your data model
•Reality!
8. The Challenge
Regulatory Compliance
Population Health Management
ReduceRe-Admissions
Service-Line Management
Claims Analysis
Other…
9. Evolution of the Solution
Organizations move from siloedsolutions to consolidated operational data stores to enterprise warehouse…
Operational
10. Enterprise Data Model
Data structures to hold all of the key decision making information for the enterprise integrated across subject areas such as:
Clinical
Claims
Financial
Operational
11. Enterprise Data Model
•Architected to be extensible
•Phased implementations
•The “single version of the truth” for the organization
•Have evolved greatly over the years
12. Enterprise Data Model (example)
Core Provider Content
Payer Content
Supply Chain Content
Core Master Data
Provider Patient Data
Payer Patient Data
Supply Chain Data
•Person
•Patient
•Organization
•Facility
•Distributors
•Product Pricing Tier
•Price Activation
•General Ledger
•Accounts Payable
•Accounts Receivable
•Contract (Supplier)
•Member (Insured)
•Subscriber
•Member Enrollment
•Member Enrolled PCP
•ADT Event (Hospitalization)
•Biospecimen
•Encounter
•Finding
•Lab Result
•Payer
•Regulatory Agencies
•Contact
•Groupings/Hierarchies
•Unified Standard Codes
•Supplier
•Wholesaler
•Distributor
•Unified Standard Codes
•Practitioner
•Unified Standard Codes
•Groupings/Hierarchies
•Reference Data
•Allergy
•Diagnosis
•Discharge Summary
and Instruction
•Imaging
•Procedure
•Surgery
•Survey
•Appointment
•Bill
•Bill Encounter
•Care Team & Role
•Contract (Patient)
•Contracts
•Disease Management
•Encounter
•Episode
•EOB
•COB
•Provider Network
•Campaign
•Premium Payments
•Location
•Order
•Patient Life Event
•Patient Medications; Includes Order, Dispense, Administration, Formulary
•Problem (chief complaint, etc.)
•Event (General)
•Exposure & Lifestyle
•General Ledger
•Location
•Patient Satisfaction
•Payroll
•Immunization
•Product Master
•Policy
•Coverage
•Benefit
•Claims (all types)
•Claims (Adjustments)
•Purchase Order
•Invoice
•Product Item Master
•Purchase History
•Contracts
•Suppliers
•Wholesalers
•Unified Standard Codes
•Groupings/
Hierarchies
•Ambulatory Encounter (date, time, type)
•Ambulatory procedure
•Ambulatory Test order
•Ambulatory Result
•Ambulatory Diagnoses
•Ambulatory Billing
•Wellness Targets
•HEDIS Measures
•PQRS Measures
•ACO Measures
•Quest Measures
•Agreement
•Money Item
•Financial Transaction
•Claim Recovery
13. Buy vs. Build
Key areas to consider:
–How experienceplays into the equation
–How is time to value impacted
–How is riskfactored in with the decision
–How easy is it to integrateother solutions
–How the decision to build vs. buy can impact your internal team
–How will costbe impacted
14. Experience
Key points to consider
–Buy
•Experience comes bundled in
•Top sellers of EDM have years of experience both technical and healthcare
•Clinicians, technologists and business analysts to bridge the two
–Build
•Does your current staff have the requisite experience?
•If not, you will likely need to hire or contract someone who does
•In addition to IT resources with technical skills, this will require plenty of support from your line of business resources (clinicians, etc.)
Many of our customers have existing data warehouses that we end up replacing and most were built internally.
15. Time to Value
Key points to consider
–Buy
•Large portion of design is already done for you
•Customizations willneed to be done regardless of what your vendor tells you
•Often times you can implement in a phased approach to reduce time to value even more
–Build
•The more experience your team has the faster this will go
•Often time subject area driven to reduce time to value
•Only build what you need, can reduce time as well
Implementing something that is already designed, will be faster than designing and building it yourself.
16. Risk
Key points to consider
–Buy
•Lower typically due to
–Level of experience and resources that went into it
–Refined over time (customer experiences incorporated)
–Repeatable so potential issues are known
•Sometimes monolithic in nature can cause scope to grow larger than needed
–Build
•Higher typically due to
–Organizations typically don’t do this lots of times, so no experience
–Common mistakes are likely to be encountered due to lack of experience
Manage scope and leverage experience to mitigate risk.
17. Integration / Accelerators
Key points to consider
–Buy
•Standardized models encourage accelerators
•Integration points need to be standard and often times take a lowest common denominator approach, which sometimes causes slight increase in effort
–Build
•If you build it yourself, you have the ultimate in flexibility to design interface the way you want them
•Integrating with outside solutions will likely take more effort due to no standard approach for vendors to build to
When standards exist, so does common integration points and pre-built accelerators…don’t reinvent the wheel.
19. Staff Impact
Key points to consider
–Buy
•Many key decisions on design are made for you
•Staff doesn’t have to be experts in designing model which lessens the pressure in early phases
•Learning curve for potential new technologies
–Modeling tool, ETL tool, Metadata management etc
•Consulting assistance for peeks in need often more effective than hiring a large team
–Build
•Every decision is yours to make, increases pressure
•Analysis paralysis is a common issue, trying to make perfect
•Leverage strengths of team in choosing technologies
Make sure staff is setup for success, not failure.
20. Cost
Key points to consider
–Buy
•Initial purchase price may seem high
•Total cost of ownership generally lower
•Other accelerators also help to reduce total cost of ownership
–Build
•Pay as you go
•Paying to reinvent the wheel
Buying might cost more up front, but will save money over time.
21. Summary
Experience–Leverage experience of people who have done what you are trying to do
Time to Value–Implementing a model that is already designed will be faster
Risk-Managing scope and leveraging experience will mitigate risk
Integration / Accelerators–Don’t reinvent the wheel
Staff Impact–Know your staff and make sure they are set up for success
Cost–Buying a model might have higher initial costs, but building will cost more over time
22. Reality, Buy and Build
Buy
–Data model
•Leverage the experience of many
•Don’t reinvent the wheel
–High value initial use case
•Physicalize required portions of the data model
•Connectivity to your source systems to populate model
•Gain quick value for investment made in model
Build
–Custom analytics for your use case
•Leverage existing investments in tools
•This is what your end user with interact with the most
–Additional use cases
•Follow patterns from initial use case
•Leverage experience and iterate