CMDP common mistakes
CMDP · Understand the traps and how to avoid them.
Treating data governance as an IT project and assigning accountability to the technology department rather than to clinical and operational data owners.
Candidates carry over a general IT mindset where systems teams own data, and they conflate stewardship (day-to-day quality) with ownership (accountability for definition and use).
What to do instead
Separate the roles explicitly: executive/domain owners are accountable for data definitions and appropriate use; stewards execute quality and standards work; IT operates the platforms. Place ownership in the business/clinical side of the organization.
Describing a data dictionary as a technical schema (table and column names, data types) instead of a business glossary of approved definitions, owners, and permitted values.
Candidates with engineering backgrounds default to physical metadata, and the exam's governance framing of 'definition and meaning' is easy to overlook.
What to do instead
For governance questions, define terms with business meaning, owner, approved values, and source of record; reserve physical schema for architecture questions.
Conflating a terminology with a classification or code set, for example treating SNOMED CT as a billing code system or ICD as a fully compositional clinical ontology.
All of these are 'medical codes' at a surface level, and candidates memorize names without learning each standard's purpose, granularity, and maintenance body.
What to do instead
Build a comparison table: purpose (clinical documentation vs. morbidity/mortality reporting vs. reimbursement vs. lab observation), granularity, compositionality, and governance body for SNOMED CT, LOINC, ICD, CPT, RxNorm, and UMLS as a metathesaurus.
Assuming a single terminology or a direct one-to-one map will handle all semantic interoperability needs.
Vendor experience often involves one system's internal codes, and candidates underestimate semantic gaps, post-coordination, and the need for map maintenance.
What to do instead
Recognize that mappings are many-to-many, versioned, and require human review; use reference terminologies with interface terminologies and value sets, and plan for map governance and versioning.
Judging data quality on completeness alone and declaring a dataset fit for use without assessing accuracy, timeliness, consistency, and validity against the intended purpose.
Completeness is easy to compute and visually obvious, so candidates anchor on it and skip dimension-by-dimension reasoning.
What to do instead
Evaluate each quality dimension against the specific use case; a dataset complete but stale or mis-coded is unfit. State the intended use first, then judge fitness.
Treating data validation as a one-time cleanup at go-live rather than designing edit checks, range and logic rules, and reconciliation at the point of capture and continuously.
Project-era remediation work leaves an impression that quality is a discrete project, and candidates underweight prevention versus correction.
What to do instead
Describe validation as layered controls: source-level edit checks and required fields, interface validation, periodic profiling and reconciliation, and feedback loops to the capturing staff.
Applying HIPAA as if it were a single universal rule, ignoring the distinction between covered entities, business associates, and the minimum necessary standard, or confusing it with GDPR's lawful-basis framework.
Candidates memorize 'HIPAA protects PHI' without the applicability structure, and cross-jurisdiction privacy questions invite blending regimes.
What to do instead
For each scenario, identify the entity role, the permitted purpose (treatment, payment, operations, research with authorization or waiver), and the minimum necessary principle; keep GDPR's legal-basis and data-subject-rights model distinct.
Proposing de-identification by simply removing names and identifiers without addressing re-identification risk, the safe harbor versus expert determination distinction, or the limits of pseudonymization.
Candidates equate de-identification with deleting obvious fields and do not consider linkage attacks or residual quasi-identifiers.
What to do instead
Distinguish the two HIPAA de-identification methods, describe residual risk assessment, and note that pseudonymized data remains personal data under many regimes.
Confusing source documentation, the source data, and the transcribed or entered record, and failing to describe audit trails and query resolution in clinical data management.
Candidates treat the EHR screen as the source of truth and overlook ALCOA+ principles and the distinction between original records and derived datasets.
What to do instead
Anchor on attributable, legible, contemporaneous, original, accurate records with an unbroken audit trail; describe how queries are raised, resolved, and closed with documented rationale.
Presenting a dashboard that encodes categories with color alone, truncates axes to exaggerate differences, or aggregates in a way that hides clinically meaningful subgroups.
Candidates focus on tool mechanics and aesthetic polish rather than perceptual accuracy and the clinical decision the visualization supports.
What to do instead
Choose chart types by the question being answered, start quantitative axes at zero unless justified, use redundant encoding (not color alone) for accessibility, and show subgroup breakdowns where Simpson's-paradox-style aggregation could mislead.
Treating interoperability as a transport problem (an interface or API exists) rather than a semantics and workflow problem (the receiving system can use the data correctly).
Candidates equate HL7 or FHIR message exchange with meaningful exchange and skip content, mapping, and consent considerations.
What to do instead
Distinguish syntactic, semantic, and process interoperability; for each scenario identify the exchange standard, the terminology binding, the consent/authorization handling, and how the receiving workflow consumes the data.
Designing an architecture or retention plan without mapping data across its lifecycle stages, so archival, legal hold, purge, and backup copies are left unaddressed.
Candidates think in terms of the production database and forget that copies, backups, and derived analytics datasets each have their own retention and disposal obligations.
What to do instead
Walk each data asset through creation, use, sharing, retention, archival, and disposition; specify retention schedules, legal-hold overrides, and disposal verification including backups and derived extracts.