12.4 Emerging Technologies and Data Governance

12.4 Emerging Technologies and Data Governance

Quick Answer: Emerging technology is allowed only when it advances a stated strategy at an acceptable risk. Data governance—ownership, stewardship, quality, and master data—is how you keep that technology from creating a second chart, a shadow AI corpus, or an unowned feed. No owner, no production.

Tasks B.5 and B.6 close the design chapter. B.5 asks whether you can evaluate a new tool without becoming the vendor’s implementation arm. B.6 asks who owns the data that tool will create or consume. Together they prevent the pattern CPHIMS punishes: a pilot that bypasses interoperability design (12.1), compliance intake (12.2), and the RPO you just funded (12.3).

CPHIMS practice questionsPractice questions with detailed explanations

Evaluating emerging technology against strategy

“Emerging” is not a synonym for illegal, and it is not a synonym for mandatory. The design question is: does this technology advance a written organizational objective at a risk the board would recognize?

Pilot design is part of B.5. Write success criteria and kill criteria before go-live. Time-box the pilot. Do not auto-renew into an enterprise standard. Prefer non-production or tightly limited production with a rollback. A successful pilot still re-enters the 12.2 compliance gate before scale.

Examples in CPHIMS language:

• Ambient AI scribe. Strategy = documentation burden. Require a BAA, retention rules, identity of the author, sampling for accuracy, and a plan when the note is wrong. “It writes faster” is not a measure unless you also watch addenda and safety.
• Consumer wearable or RPM feed. Strategy = a named chronic-care outcome. Require identity binding, device pedigree, missingness rules, and inbox ownership (Chapter 3). A firehose of steps is not a care program.
• SMART on FHIR third-party app. Strategy = a specific workflow gap. Require launch context, scopes, write-back rules, and a steward for any problem or med it creates.
• Blockchain for “the longitudinal record.” Usually fails strategy-fit unless you have a real multi-party provenance problem that existing HIE, TEFCA, and audit controls do not address. Hype is a scan input.

Do not let a model card replace a data-use decision. Do not let a sandbox API key become a production extract.

Data governance vocabulary — keep the roles distinct

Data ownership is accountability for a domain: purpose of use, quality bar, access policy, and retention. The owner is usually a clinical or operational executive (CMIO for problems and orders, HIM for the legal record, revenue cycle for claims identity)—not the application analyst who clicks the build.

Data stewardship is the operational care of definitions, code tables, issue queues, and day-to-day quality. Stewards investigate duplicates, accept or reject a definition change, and escalate to the owner when the bar cannot be met.

Data custodianship is where IT usually sits: platforms, backups, access mechanics, and pipeline reliability. Custodians do not get to redefine “allergy” because a table is inconvenient.

Data quality is fitness for a stated use, along dimensions you should be able to name:

Duplicate rate, overlay rate, and interface-error age are quality SLAs, not “engine noise.”

Master data are the slow-changing nouns the enterprise must share: patient, provider, location/unit, organization, plus reference catalogs (formulary, lab dictionary). Master data are not a warehouse fact table. If the patient or location is wrong, every interface in 12.1 is wrong. Reference data are the allowed values and code systems. Metadata and lineage say what a field means and where it came from—mandatory when AI or quality reporting consumes the field.

MPI/EMPI is a master-data program with survivorship rules, not a nightly job nobody owns. Golden-record decisions need a steward and an appeal path, because a bad merge is a wrong-patient event.

Operating model

• A data-governance council with clinical, HIM, quality, revenue, and IS seats—not an IT CAB alone (same spirit as CDS governance in Chapter 9).
• Named domain owners and stewards, published in a RACI, not implied.
• Change control on catalogs and master data, with versions you can reconstruct.
• Classification (public / internal / confidential / ePHI) that drives API and emerging-tool design.
• Quality reports on a standing agenda: MPI duplicates, overlays, feed lag, completeness of required USCDI or measure elements.
• An exit clause in every emerging-tech contract: return or destroy ePHI, revoke keys, and document lineage.

Where emerging tech and governance collide

1. A SMART app writes problems and no steward owns the problem list.
2. An AI vendor trains on identifiable notes without a use decision from the data owner.
3. A marketing “engagement platform” mints a second patient identity and never talks to the EMPI.
4. A device cloud becomes the de facto system of record for vitals, with a worse RPO than the EHR.
5. A “de-identified” extract is still re-identifiable and leaves without a classification check.

Design rule: no production emerging technology without a named data owner, a quality bar, master-data alignment, a 12.2 compliance pass, and an exit that returns or destroys ePHI. If you cannot say who owns the data Tuesday morning, you are not ready to evaluate the algorithm.

Scenarios and exam traps

Scenario. A vendor offers a free ambient-scribe pilot if the health system “shares notes to improve the model.” Strategy-fit might exist, but B.6 fails until an owner decides purpose of use, a BAA exists, and training on identifiable notes is an explicit, recorded decision—not a click-through.

Scenario. Population-health marketing buys an engagement app that registers patients with email as the only identifier. Treat it as a master-data incident. Bind to the EMPI or do not launch.

Scenario. The application analyst is listed as “owner” of the enterprise problem list because they can edit the data dictionary. Reassign ownership to a clinical executive and keep the analyst as builder or custodian.

Scenario. A pilot succeeds on one clinic’s well-resourced panel and leadership wants system-wide default-on next Monday. Re-enter B.5 evaluation for equity, workforce, and TCO; re-enter B.2 for certification and privacy. A happy clinic is not a scale decision.

Watch these traps:

1. Treating a demo or hype cycle as strategy alignment.
2. Letting IT or the vendor “own” clinical meaning.
3. Confusing stewardship (operations) with ownership (accountability).
4. Standing up a second identity or catalog and calling it innovation.
5. Auto-promoting pilots.
6. Skipping exit and lineage because the algorithm is accurate in a slide deck.

Domain 3 design is now a chain: interoperable layers (B.1), a process that absorbs law and trends (B.2–B.3), BC/DR you can actually run (B.4), and technology that does not outrun its data owners (B.5–B.6). Selection and implementation in Chapter 13 assume this design exists.