What problem would it solve?
Consider a synthetic example involving patient contact information. Three systems provide the same business concept under different field names: preferred_phone, preferredPhone, and PreferredContactNumber.
You map these into one common property. But that still leaves important questions: Was the number recently verified? Do the systems disagree? Is it missing because nobody asked, because the person declined, or because the integration failed? Does the current case step actually require it?
Pega already supports source abstraction, aggregation, and configurable Data Page refresh behavior. The proposed extension would build on those capabilities rather than present them as new inventions. (Pega Academy)
The added behavior would be a consistent, explainable answer to: “Does this data meet the requirements of this particular case step?”
The reusable data structure I would propose
Keep business values in normal, typed Pega properties. Add the following supporting structures rather than replacing everything with a generic name/value table.
| Proposed structure | Example fields | Purpose |
|---|---|---|
| Data Element Definition | ElementKey, BusinessMeaning, DataType, DefinitionVersion |
Defines exactly what the field means, preventing similarly named but different concepts from being treated as equivalent. |
| Source Mapping | SourceSystem, SourceField, ElementKey, TransformRule, MappingVersion |
Documents how each source supplies the common element. |
| Field Evidence | EntityKey, ElementKey, ValueReference, SourceRecordID, VerifiedAt, RetrievedAt, MissingReason |
Preserves the source and condition of each candidate value. |
| Workflow Requirement | CaseType, Stage, ElementKey, Required, MaxAgeDays, SourcePolicy, ConflictAction, ContractVersion |
Specifies what a particular workflow step requires. |
| Readiness Result | Status, ReasonCode, EvidenceReferences, ContractVersion, EvaluatedAt |
Explains whether the data passes the requirement and why. |
Two design details would make this especially useful.
First, distinguish “retrieved recently” from “verified recently.” In the proposed design, fetching a ten-month-old phone record today would not make the phone number newly verified. Preserve both dates and evaluate the appropriate one.
Second, preserve the meaning of missing data. Do not treat “not asked,” “declined,” and “integration error” as the same blank value. HL7 FHIR already defines these kinds of missing-data distinctions, so the article should acknowledge and reuse those concepts where appropriate rather than claim to invent them. (HL7)
A concrete example others could implement
Start with one administrative follow-up case and its preferred-contact-number field.
For an illustrative policy, suppose case intake does not require a phone number, but the telephone-outreach step requires a valid number verified within the organization’s chosen period.
The same record could therefore pass the intake requirements but return this result for outreach:
Element: PreferredContactNumber
Case step: Telephone outreach
Status: NEEDS_REVIEW
Reason: VERIFICATION_TOO_OLD
Required action: Verify the number before proceeding
Contract version: 1.0
The verification period would be a configurable demonstration setting, not a clinical or regulatory requirement.
For conflicting values, I would make the first version conservative: preserve the competing values and request review unless an explicit source-selection policy resolves the conflict. Do not silently assume the newest value is correct.
This would let the case explain which field failed, which requirement failed, and what needs attention—rather than returning a generic validation error. Existing authorization and communication-permission controls would remain separate; a READY result would not grant permission to use the data.
How I would build it in Pega
Use Data Pages and Data Transforms for the integration layer. Data Pages would retrieve the source records, and Data Transforms would map equivalent fields into the common structure while preserving their evidence. These are established Pega capabilities; the new work would be the contract structure and evaluation behavior you build around them. (Pega Academy)
Create one reusable readiness evaluator. It would accept the entity, case type, stage, and contract version; evaluate the required elements; and return READY, NEEDS_REVIEW, or BLOCKED with reason codes. Invoke it before the relevant server-side action, not only when displaying the screen. Re-evaluate when the underlying data or requirements change.
Publish executable tests with the example. Include scenarios for missing values, unknown verification dates, stale values, conflicting sources, integration failures, and different requirements at different stages. Pega unit testing supports testing individual rules and setting up controlled test data, making this a practical way for others to reproduce the behavior. (Pega Academy)
For the first release, I would exclude patient identity matching, clinical decisions, and automatic changes to source systems. That keeps the contribution focused and testable.
What would make the article valuable—and potentially distinctive?
Publish an implementation package, not just a conceptual article. Include the data dictionary, synthetic source payloads, mapping examples, evaluation rules, test cases, and the Pega version on which you tested it. Use only material you are authorized to share, without employer schemas or real patient information.
Then compare the implementation with a baseline that uses ordinary field mapping and required-field validation. Measure whether it detects the intended problems, how often it incorrectly requests review, how much processing time it adds, and whether another case type can reuse it without duplicating the evaluator. Report actual results, not assumed improvements.
There is an important originality boundary: data contracts, data-quality requirements, and service-level expectations already exist in standards such as the Open Data Contract Standard. Adding those ideas to a diagram would not, by itself, establish a new contribution. The work worth investigating is your particular executable Pega design, its differences from existing approaches, and the demonstrated benefits of using it. (Bitol)
My recommendation is to start with this small, working example: one common contact element, two source systems, two case stages, and a reusable readiness evaluator. That would give the community something concrete to implement—and give you a clear technical contribution to test, improve, and document through genuine use.