Solution: ClearView Medical Center

Work in Progress

This content is currently being reviewed for accuracy and will be updated soon.

Architecture Decisions

AD-1: Health Cloud as Coordination Layer, Not EHR Replacement

Decision: Deploy Salesforce Health Cloud as the patient coordination and care management layer on top of AthenaPrime. AthenaPrime remains the system of clinical record.

Rationale: AthenaPrime will not be replaced (stated constraint). Health Cloud’s Person Account model, Care Plan, and Episode objects align well with patient coordination workflows. Treating Health Cloud as a coordination layer limits the EHR integration surface to HL7 event feeds rather than a full data migration of clinical documentation.

Trade-off: All clinical decision data still lives in AthenaPrime. Providers must context-switch between two systems for full clinical history. Accepted because replacing AthenaPrime is out of scope and out of budget.

Alternatives considered: Full clinical migration into Health Cloud. Rejected: AthenaPrime is the contractual system of record; a full migration would require extensive clinical validation and adds regulatory risk.

---

AD-2: Salesforce-Native Integration (No Middleware Platform)

Decision: Do not procure a separate enterprise integration platform. Use Salesforce Platform integration capabilities: Apex REST endpoints for HL7 inbound, Apex callouts with Named Credentials for ClearBill REST, and a thin AWS Lambda worker for SFTP retrieval to LabConnect. MuleSoft Anypoint and other middleware platforms are ruled out by the $1.4M budget constraint.

Rationale: Budget is $1.4M covering licenses, implementation, migration, and year-1 support. A middleware platform license (MuleSoft, Boomi, Informatica) would consume a significant portion. The integration volumes are moderate (2,000 HL7 messages/day, 780 lab results/day) and well within Salesforce async processing limits. The 4-person IT team cannot own a separate middleware platform.

Trade-off: Error handling, retry logic, and CMRN lookup all land in Apex and Flow. This increases code complexity on the Salesforce side compared to a dedicated integration platform. Mitigated by building a shared integration utility class used by all three channels.

Alternative: AWS Lambda as a thin middleware layer for future integration scaling at phase 2 acquisitions. Heroku Enterprise is also technically capable but entered sustaining engineering mode in February 2026 (no new enterprise subscriptions); it remains viable only for organizations with existing Heroku contracts.

---

AD-3: Sharing Architecture: Context-Sensitive Cross-Facility Access via Platform Events + Sharing Sets

Decision: Use a combination of role hierarchy (facility-scoped), manual sharing triggered by a Platform Event on encounter check-in, and sharing revocation on encounter close. Billing uses Permission Set Groups with explicit FLS lockdown. All cross-facility access events are captured via Salesforce Shield Event Monitoring.

Rationale: Requirements 8 and 9 are in direct tension. A static role hierarchy or sharing rule cannot grant access at encounter time and revoke it afterward. A Platform Event-triggered Flow grants a temporary sharing record when a patient checks in and removes it on encounter close. This is the lightest-weight mechanism that satisfies both requirements without a custom sharing recalculation that would stress the sharing model at scale.

Trade-off: Sharing record volume increases with encounter volume (~290,000/year). Sharing records must be pruned regularly. The encounter-close trigger must be reliable: a failed encounter-close risks leaving an open sharing grant.

Alternatives considered: Custom Apex Managed Sharing with a dedicated trigger. Viable but harder for a 4-person IT team to maintain. Approval-process-based access. Too slow for a walk-in urgent care encounter.

---

AD-4: Salesforce Shield + External Audit Archive

Decision: License and configure the full Salesforce Shield suite: Event Monitoring, Platform Encryption (Shield Encryption), and Field Audit Trail. Add a nightly EventLogFile export to customer-managed cloud storage (the same S3 bucket used for other compliance archives) to satisfy the 6-year retention requirement.

Rationale: Requirement 13 (field-level encryption for SSN, DOB, financial account) requires Platform Encryption. Requirement 25 (CISO on-demand audit report without IT) requires Field Audit Trail for field-level change history beyond the standard 18-month limit. Requirement 12 (full access audit log, 6-year retention) requires Event Monitoring for access telemetry, but native EventLogFile retention is 30 days by default and a maximum of 1 year with Shield Event Log File Storage; neither meets the 6-year HIPAA retention bar. A nightly Apex job extracts EventLogFile content via API, writes it to an external S3 bucket using a Named Credential and an AWS Lambda staging step, and tags each object with a 6-year lifecycle policy. The CISO audit reports read from in-Salesforce EventLogFile for the recent window and from the archive for older queries.

Trade-off: Shield adds license cost and introduces encryption key management overhead. The encryption key hierarchy and key rotation schedule must be documented in the BAA-adjacent governance materials. The external archive adds an additional component to the integration landscape but reuses the same AWS Lambda pattern already in place for SFTP, keeping operational surface area limited.

---

AD-5: CMRN as the Load-Bearing Identity Key

Decision: Before any migration data enters Salesforce, run a pre-migration dedup and MPI process to assign a CMRN to every unique patient. Facility MRNs are stored as External ID cross-reference records on a custom Patient_Identifier__c child object. All integration channels resolve inbound identifiers to the CMRN before writing.

Rationale: Three integration channels (HL7, ClearBill, SFTP lab files) use different identifier formats. Without a single resolution key, each channel independently duplicates patients. The CMRN object design supports the two future acquisitions by simply adding new identifier rows without schema changes.

---

System Landscape

Legend

AthenaPrime and ClearBill remain in place. NorthCare is decommissioned at Month 14 after verified migration. Health Cloud is the coordination and patient management layer, not a clinical documentation replacement.

---

Data Model

Core Health Cloud Objects

Object	Use	Key Fields
Account (Person Account)	Patient record	CMRN (External ID), Source_Facility__c, Record_Status__c (Active/Inactive)
Patient_Identifier__c	Cross-reference MRN table	Account lookup, Facility__c, Facility_MRN__c, Identifier_Type__c
HealthCloudGA__EhrPatientMedication__c	Medication list	Standard Health Cloud medication object
HealthCloudGA__EhrPatientAllergy__c	Allergy records	Standard Health Cloud allergy object
Encounter__c	Visit record	CMRN lookup, Facility__c, Encounter_Status__c, Transmission_Status__c
Insurance_Policy__c	Coverage	Account lookup, Facility__c, Policy_Number__c, Payer__c
Lab_Result__c	Lab result attachment	Encounter lookup, Patient lookup, Result_Status__c, File_Drop_Time__c
Integration_Log__c	Transmission audit	Channel__c, Message_ID__c, Status__c, Retry_Count__c, Error_Detail__c
Integration_Error_Queue__c	Unmatched/failed messages	Channel__c, Raw_Payload__c, Unmatched_Since__c, Escalated__c
Facility__c	Facility master	Facility_Code__c, Facility_Name__c, ClearBill_Partition__c

CMRN / MPI Design

Each unique patient has exactly one Person Account with a CMRN stored as an External ID. Facility MRNs (AthenaPrime MRN for Main, AthenaPrime MRN for West, NorthCare MRN) are stored as child Patient_Identifier__c records. All integration inbound processing runs a SOQL lookup against Patient_Identifier__c to resolve the CMRN Account before writing.

Person Account (CMRN: CW-000001)
  └─ Patient_Identifier__c: AthenaPrime-Main → AP-12345
  └─ Patient_Identifier__c: AthenaPrime-West → AP-98765
  └─ Patient_Identifier__c: NorthCare → NC-7711

This structure scales to additional acquisitions by inserting a new identifier row with the new facility’s type code.

Inactive Patient Handling (Requirement 6)

A Record_Status__c picklist field on Person Account holds values Active and Inactive. A scheduled nightly Flow marks patients inactive if their most recent encounter is more than 5 years prior. All standard list views and provider-facing search components filter on Record_Status__c = Active. Compliance and clinical users have a saved search view that includes inactive records. This does not delete or archive the record.

---

Integration Architecture

Channel 1: AthenaPrime HL7 Inbound (Requirements 16, 17, 22)

Trigger: AthenaPrime posts HL7 v2.x messages (ADT-A01/A08, ORM-O01, ORU-R01) via HTTPS POST to an Apex REST endpoint secured by an External Client App (ECA) with OAuth 2.0 client credentials.

Processing flow:

1. Inbound message lands in a custom HL7_Inbound_Queue__c object or is handled by a REST endpoint class.
2. An Apex queueable job parses the message segment by segment, extracts the patient identifier (PID-3), and queries Patient_Identifier__c to resolve the CMRN.
3. If resolved: write or upsert the appropriate Health Cloud record. Log to Integration_Log__c with status Success.
4. If unresolved: write message raw payload to Integration_Error_Queue__c with status Unmatched and timestamp. Create a task for the integration team.
5. A scheduled Flow runs every 30 minutes and escalates any Integration_Error_Queue__c record whose Unmatched_Since__c is more than 4 hours ago to the IT Director (Requirement 17).
6. Idempotency is enforced by storing the HL7 Message_Control_ID (MSH-10) in Integration_Log__c and checking for duplicates before processing. Duplicate message IDs are acknowledged and discarded without writing.

Retry: AthenaPrime has no server-side retry. The endpoint returns HTTP 202 Accepted for all syntactically valid inbound messages. Semantic failures go to the error queue rather than returning HTTP 4xx, which would cause AthenaPrime to stop sending.

Volume: ~2,000 messages/day combined. Well within async Apex processing limits.

---

Channel 2: ClearBill Billing REST (Requirements 18, 19, 22)

Trigger: An Encounter record’s Encounter_Status__c field transitions to Finalized. A record-triggered Flow fires and calls an Apex action that submits to ClearBill API v3.

Processing flow:

1. Flow collects required fields: date of service, procedure codes, diagnosis codes, rendering provider NPI, insurance ID, facility code.
2. Apex callout authenticates using OAuth 2.0 client credentials (stored in Named Credentials, one credential per facility partition). Submits the claim payload to the facility-appropriate ClearBill endpoint.
3. ClearBill acknowledges within ~90 seconds. Apex updates the Encounter’s Transmission_Status__c (Accepted / Rejected / Pended) and Transmission_Timestamp__c.
4. If Rejected or Pended: Flow creates a Task assigned to the facility’s billing queue.
5. A scheduled report runs at end-of-business (17:00 local) flagging any encounter finalized that day without a Transmission_Status__c value. This satisfies the “no encounter ends the day without a recorded transmission status” requirement.

Timeout handling: If the callout times out (>120s), the Encounter is flagged Transmission_Status__c = Pending_Retry and a scheduled Apex job retries within 15 minutes, up to 3 attempts. After 3 failures, status becomes Transmission_Error and a task is generated.

Facility scoping: Named Credentials are facility-specific. The Apex class selects the credential based on Encounter__c.Facility__c. Adding a new facility means adding one Named Credential and one ClearBill partition mapping record. No code change.

---

Channel 3: LabConnect SFTP Batch (Requirements 20, 21, 22)

Trigger: Scheduled Apex jobs at 06:00, 12:00, and 18:00 NC local time connect to the LabConnect SFTP server via a callout to a lightweight AWS Lambda function (lowest-cost serverless option for scheduled SFTP retrieval). The Lambda function places the fixed-width file content into a Salesforce custom object Lab_File_Batch__c via REST, then Apex processes each record row.

SFTP Constraint

Salesforce Apex cannot natively connect to SFTP. A minimal external component (AWS Lambda or equivalent cloud function) handles the SFTP retrieval and hands off file content to Salesforce via REST API. This is the only component outside Salesforce in the integration design and is justified by the budget and simplicity constraints. Organizations with existing Heroku contracts can use a Heroku dyno instead, though Heroku Enterprise is in sustaining engineering mode and is not accepting new enterprise subscriptions.

Processing flow:

1. For each result row, determine identifier type from the file’s facility source code field (NorthCare MRN vs. AthenaPrime MRN).
2. Query Patient_Identifier__c to resolve the CMRN. If resolved: create Lab_Result__c linked to the Patient Account and to the matching open Encounter.
3. If unresolved: write to Integration_Error_Queue__c with Channel__c = LabConnect, timestamp of file drop, source file row.
4. A scheduled Flow checks at T+2h: any unresolved LabConnect rows trigger a notification to the ordering provider’s care team (Task + email).
5. At T+8h: still unresolved rows trigger escalation tasks to the IT Director and CMO’s office (Requirement 21).

Error path: NorthCare MRN format normalization (zero-padding differences between NorthCare and AthenaPrime MRN formats) is handled in the CMRN lookup logic, not in the file parser, so the normalization applies to all channels.

---

Security and Sharing Model

BAA First (Requirement 7)

BAA must be executed with Salesforce before any PHI enters any environment. Pre-migration testing uses synthetic data generated to mirror production complexity (correct MRN format distribution, duplication rate, missing-field rate) but with no real patient identifiers. Full sandboxes refreshed from production after BAA execution require a secondary data masking step or must be treated as production-class environments under the BAA scope.

HIPAA Technical Safeguards

Safeguard Category	Salesforce Control
Access Control	Profile + Permission Set Groups + Role Hierarchy + Sharing model
Audit Controls	Shield Event Monitoring (access telemetry via EventLogFile: URI events, Login events, Report events) + Field Audit Trail (field-level change tracking)
Integrity	Shield Platform Encryption + field validation + API FLS enforcement
Transmission Security	All traffic over TLS 1.2+; Named Credentials for outbound; HTTPS-only inbound

Role Hierarchy

ClearView System Admin
  └─ CISO / Compliance
  └─ CMO (cross-facility read)
  └─ VP Revenue Cycle (cross-facility billing read)
      └─ Billing Manager (Main)
      └─ Billing Manager (West)
      └─ Billing Manager (North)
  └─ Facility Director (Main)
      └─ Clinical Staff (Main)
      └─ Admin / Front Desk (Main)
  └─ Facility Director (West)
      └─ Clinical Staff (West)
      └─ Admin / Front Desk (West)
  └─ Facility Director (North)
      └─ Clinical Staff (North)
      └─ Admin / Front Desk (North)

OWD and Sharing Rules

Object	OWD	Sharing mechanism
Account (Patient)	Private	Records are owned by a User (or Queue), never by a Role. Patient Account records are owned by the creating integration user or the assigned care coordinator user at the home facility. A role-based sharing rule grants clinical users visibility to all patients owned by users in their facility role branch. Cross-facility access: temporary Apex Managed Sharing on encounter check-in.
Encounter__c	Private	Owner = creating user. Billing users: sharing rule scoped to own-facility encounters via Facility__c criterion.
Lab_Result__c	Private	Lab_Result__c has a Lookup to Encounter (not Master-Detail) and does not automatically inherit Encounter sharing. Sharing is granted explicitly: either convert the relationship to Master-Detail so sharing cascades from Encounter, or add explicit Apex Managed Sharing logic for Lab_Result__c records on encounter check-in alongside the Account sharing grant.
Insurance_Policy__c	Private	Sharing rule grants billing users read on own-facility records.
Integration_Log__c	Public Read Only	IT and CISO read access; write via integration user only.

Profile and Permission Set Design

User Group	Profile	Permission Set Group
Clinical Staff	Health Cloud: Clinical User (standard)	PSG_Clinical_Base: read/write Encounter, read Lab_Result, no FLS on billing fields
Billing Staff	Minimum Access	PSG_Billing_{Facility}: read Encounter (billing fields only via FLS), create/edit claims tasks. Explicit FLS deny on: Clinical_Notes__c, Allergy__c, Medication__c, Assessment__c
Front Desk / Scheduling	Minimum Access	PSG_FrontDesk: read/write Demographics, Insurance, Appointment. FLS deny on: Clinical_Notes__c, Diagnosis_Code__c, Billing_Amount__c, Lab_Result__c
CISO / Compliance	Custom Read-All	Full read, Event Monitoring access, no PHI bulk export without DLP policy
Integration User	API-Only	Dedicated profile, no UI login, specific object and field permissions only

FLS at the API Layer

Object-level access does not prevent API access to restricted fields. FLS must be set to read = false on clinical fields for billing profiles. Code accessing PHI fields must call Schema.SObjectField.getDescribe().isAccessible() checks. Use WITH USER_MODE in SOQL for user-context queries where appropriate.

Cross-Facility Access (Requirements 8 and 9)

At encounter check-in (Encounter status = Checked_In):

1. A Platform Event Encounter_Checked_In__e fires, carrying the Patient Account ID and the Accessing Provider’s User ID.
2. A triggered Flow on the Platform Event calls an Apex invocable action that creates a manual sharing record granting the provider Read access to the Patient Account for the duration of the encounter.
3. This access event is logged to a custom Cross_Facility_Access_Log__c object with: User, Patient Record ID, Timestamp, Accessing Facility, Encounter ID.

At encounter close (Encounter status = Closed):

1. A second Platform Event or a record-triggered Flow on status change calls Apex to delete the manual sharing record.
2. If the encounter-close event fails, a scheduled nightly cleanup job removes sharing records older than 24 hours for encounters in Closed status.

Between encounters: Providers see only own-facility patients via the role-based sharing rule. No cross-facility browsing is possible.

Shield Encryption (Requirement 13)

Fields encrypted at rest using Shield Platform Encryption with a tenant-managed key:

• SSN__c (Social Security Number)
• Birthdate (standard Person Account field; encrypt via Encryption Policy)
• Bank_Account__c / Financial_Account__c (custom financial fields)

Deterministic encryption is used for SSN and Financial Account: it preserves equality filtering in SOQL WHERE clauses, reports, and list views, which the billing system requires for exact-match lookups. Probabilistic encryption is used for date of birth; probabilistic encryption does not support filtering, so DOB cannot be used in SOQL WHERE clauses or report filters. The CISO audit report uses Event Monitoring + Field Audit Trail rather than direct field queries on encrypted columns.

Automated Access Revocation (Requirements 14 and 15)

Termination (Requirement 14): HRIS sends a termination event to a Salesforce REST endpoint. The External Client App (ECA) provides OAuth 2.0 authentication for the Apex REST endpoint. An Apex trigger deactivates the User record immediately. The 4-hour SLA is met because the process is automated: the bottleneck is the HRIS sending the notification, not IT action. The integration user that receives termination events has a dedicated restricted profile.

Time-limited contractors (Requirement 15): Contractors are assigned a Permission Set with an expiration date using the Permission Set Assignment Expiration feature (available in Salesforce since Summer ‘22). When the expiration date passes, the permission set assignment is automatically removed without IT action. Contractor access to PHI-bearing objects is gated through this timed permission set.

---

Migration Strategy

Phase Sequence

Phase	Activity	Timeline
0	BAA execution. No PHI anywhere until signed.	Week 1
1	Synthetic data environment setup. Dedup tooling validation with synthetic records.	Weeks 2-4
2	NorthCare within-system dedup (~960 records). Survivorship rules applied.	Weeks 5-7
3	MPI construction: AthenaPrime extract + deduped NorthCare extract. Match on Name + DOB + Insurance. Assign CMRN to every unique patient.	Weeks 8-10
4	Migrate AthenaPrime (Main + West) patient records, demographics, insurance, allergies, medications, PCP assignments, 5-year encounter summaries.	Weeks 11-14
5	Migrate NorthCare records using CMRN cross-reference. Overlapping patients merged under existing CMRN. Source-of-origin tag applied to all NorthCare records.	Weeks 15-17
6	Clinical reviewer queue: 9,000 merged patient flags presented for confirmation within 30 days of go-live. Dashboard tracking completion rate.	Post-go-live month 1
7	Data quality remediation: ~1,680 records missing insurance (7% of 24,000) surfaced on go-live readiness dashboard for front desk.	Pre-go-live + post-go-live ongoing
8	NorthCare decommission after migration verification sign-off.	Month 14

Survivorship Rules (Requirements 3, 4)

For the ~9,000 overlapping patients:

1. Preferred demographic record: whichever has the higher completeness score (fewer null fields across name, DOB, address, insurance, PCP).
2. In a tie: AthenaPrime record wins over NorthCare (AthenaPrime is the active clinical system).
3. All encounter history from both facilities is consolidated under the winning CMRN.
4. The losing record is marked Merged_Into_CMRN__c and retains the raw data in read-only form for audit.
5. All merged records are flagged Pending_Clinical_Review__c = true and appear in the clinical reviewer queue.

NorthCare Data Quality

• 4% internal duplicates (~960 records): Resolved before MPI using the same survivorship algorithm above.
• 7% missing insurance (~1,680 records): Tagged Insurance_Status__c = Missing on migration. Surfaced on the go-live readiness dashboard. Front desk remediates post-migration.
• Free-text BLOB notes: Migrated as read-only Migrated_Note__c long-text area fields. No editing permitted. Flagged with Source_System__c = NorthCare.
• Source-of-origin tag (Requirement 5): Origin_Facility__c picklist populated on every migrated record. Retention policy enforced via Field Audit Trail 7-year history setting.

BAA-Compliant Test Strategy

• Full sandbox refreshes prior to BAA execution use synthetic data only.
• Synthetic data is generated to match production statistical properties: same MRN format lengths, same duplication rate (~4%), same missing-field rate (~7%), same approximate patient volume.
• After BAA is signed, sandboxes refreshed from production are treated as PHI environments. Access to post-BAA sandboxes is restricted to staff listed in the BAA addendum.
• The November production freeze creates a hard constraint: migration must either complete by October 31 or pause until January 15. Target go-live is October for the main migration wave.

---

Reporting Approach

Requirement	Approach
Facility operational dashboard (Req 23)	CRM Analytics or standard Salesforce Reports dashboard. Filter: Facility__c = {current user's facility} enforced via sharing model (facility billing managers see only their data). Includes scheduled encounters, completions, no-shows, open data quality items, pending lab results.
CMO cross-facility summary (Req 24)	Custom report type on Encounter, cross-facility. CMO role grants read access to all facilities via role hierarchy. Monthly scheduled report snapshot. Includes encounter volumes by facility and specialty, top 15 diagnosis codes (ICD-10 field), patients with no encounter in past 12 months.
CISO audit report (Req 25)	Recent window (0-30 days native, up to 1 year with Shield Event Log File Storage): Event Monitoring via the EventLogFile object. Older window (up to 6 years): queryable archive in S3 fronted by a CRM Analytics external connector or Athena / Tableau connection. Combined with Field Audit Trail for field-level change history. CISO-facing Salesforce report or CRM Analytics dashboard with date-range filter. Exportable to CSV. No IT involvement for standard queries.
Weekly claims performance (Req 26)	Report type on Encounter + ClearBill transmission status. Scoped by Facility__c. VP Revenue Cycle role sees all facilities via hierarchy; billing managers see only own facility. Pended/rejected aging calculated from Transmission_Timestamp__c.
Integration health dashboard (Req 27)	Report on Integration_Log__c and Integration_Error_Queue__c. Visible to IT team and CISO. Shows message volumes, error counts, retry rates, unmatched record queues per channel. No developer query required.

---

Requirements Addressed

#	Requirement	How addressed
1	Migrate all active patient records, demographics, insurance, allergy, medications, PCP, 5-year encounter history with notes	Migration Phases 4-5; NorthCare BLOB notes migrated as read-only Migrated_Note__c
2	MPI with CMRN, facility MRNs as cross-reference identifiers	Patient_Identifier__c child object with Facility_MRN__c; CMRN as External ID on Person Account
3	9,000 overlapping patients: survivorship, consolidated history, 30-day reviewer flag	Survivorship rules; Pending_Clinical_Review__c flag; clinical reviewer queue dashboard
4	NorthCare internal dedup (~960 records) and missing insurance (~1,680 records) remediation	Pre-MPI dedup phase; Insurance_Status__c tagging; go-live readiness dashboard
5	Source-of-origin tag on NorthCare records, 7-year retention	Origin_Facility__c field; Field Audit Trail 7-year policy
6	Inactive patients (5+ years) accessible but not in standard search	Record_Status__c field; nightly Flow; standard views filter Active only
7	BAA before PHI, all four HIPAA technical safeguard categories	BAA Phase 0; Shield suite; HIPAA safeguard table above
8	Providers see full clinical record for patients presenting at their site	Platform Event-triggered Apex Managed Sharing on check-in; Cross_Facility_Access_Log__c
9	Outside encounter, providers limited to own-facility patients	Role-based sharing rule; sharing grant removed on encounter close
10	Billing staff limited to billing fields, no clinical notes/allergy/medications	PSG_Billing_{Facility} with explicit FLS deny on clinical fields; enforced at UI and API
11	Front desk: demographics/insurance/appointments only, no clinical/billing/lab	PSG_FrontDesk with FLS deny on restricted fields
12	Full access audit log, 6-year retention, CISO queryable without IT	Shield Event Monitoring for recent window, nightly export of EventLogFile content to a customer-managed S3 archive for 6-year retention, and Field Audit Trail for field-level change history; CISO has direct access to EventLogFile and an external connector view of the archive
13	PHI encrypted at rest and in transit; SSN, DOB, financial fields FLS-encrypted	Shield Platform Encryption; Encryption Policy on named fields; TLS for all transit
14	Staff termination triggers Salesforce revocation within 4 hours	HRIS REST event to connected app; Apex immediately deactivates User record
15	Time-limited contractor access expires automatically	Permission Set Assignment Expiration feature; no IT action required
16	HL7 inbound idempotent, CMRN resolution before write, no duplicate records	Message_Control_ID dedup check; Patient_Identifier__c CMRN lookup before upsert
17	Unrecognised HL7 identifiers to error queue; 4-hour escalation to IT Director	Integration_Error_Queue__c; scheduled Flow escalation at T+4h
18	Encounter finalisation submits to ClearBill within 20 minutes, correct facility partition	Record-triggered Flow + Apex callout on Encounter_Status__c = Finalized; Named Credential per facility
19	ClearBill acknowledgement writes back; rejected/pended generate billing tasks; no encounter ends day without status	Callout response updates Transmission_Status__c; Flow creates tasks; scheduled EOD report
20	SFTP lab files processed at each drop window, identifiers resolved, results attached	Scheduled Apex + SFTP worker at 06:00/12:00/18:00; Patient_Identifier__c lookup; Lab_Result__c creation
21	Unmatched lab results: care team alert at T+2h, IT Director + CMO escalation at T+8h	Scheduled Flow checks at T+2h and T+8h on Integration_Error_Queue__c LabConnect rows
22	Transmission log accessible to IT and CISO; design accommodates 2 future acquisitions	Integration_Log__c; CMRN cross-reference extensible by adding identifier rows; Named Credential per facility
23	Daily operational dashboard per facility manager	Salesforce Reports dashboard; scoped by sharing model
24	Monthly cross-facility CMO summary	Custom report type; CMO role grants cross-facility read
25	On-demand CISO audit report, exportable CSV	Event Monitoring + Field Audit Trail; CISO direct access
26	Weekly claims performance per facility; VP Revenue Cycle cross-facility, billing managers scoped	Report scoped by Facility__c; role hierarchy enforces visibility
27	Integration health dashboard, no developer query	Report on Integration_Log__c + Integration_Error_Queue__c

---

Risk Assessment

Risk 1: CMRN resolution failures at go-live If the MPI construction phase has gaps, incoming HL7 messages and SFTP lab files hit the error queue in volume. Mitigation: dry-run the full 62,000-patient extract through the CMRN resolution logic using synthetic identifiers before cutover. Set an acceptance threshold: fewer than 0.5% unresolved messages in the 48-hour post-go-live window before calling go-live stable.

Risk 2: Production freeze window conflict If migration is delayed, the November 1 freeze hits before decommission criteria are met. NorthCare must then run in parallel until January 15, extending the overlap window and increasing the risk of data divergence. Mitigation: build the October 15 go-live as a hard project milestone with a go/no-go gate at October 1. Plan an explicit freeze-aware rollback scenario if October 1 gate is missed.

Risk 3: Encounter-close sharing revocation failure If the encounter-close trigger fails silently, manual sharing grants accumulate and providers retain cross-facility access indefinitely. Mitigation: nightly cleanup job purges grants for Closed encounters older than 24 hours. Alert if cleanup job processes more than a configurable threshold of records (indicating upstream trigger failure).

Risk 4: Shield encryption and existing integrations Encrypting Birthdate and SSN affects any Apex or Flow that filters or sorts on those fields (encrypted fields cannot use wildcard SOQL). Mitigation: audit all SOQL queries involving DOB and SSN before enabling encryption. Switch to exact-match (deterministic encryption) for fields requiring query support. Schedule a build-verify pass after encryption is enabled in each environment.

---

Domain Scoring Notes

Security domain probes the board will focus on:

• How exactly does cross-facility access work during an encounter vs. outside one? Name the mechanism (Apex Managed Sharing via Platform Event). What prevents a provider from staying checked in indefinitely?
• FLS enforcement at the API layer: why is object-level access insufficient? What code pattern enforces it?
• How does the CISO pull an audit log for a specific patient without calling IT? Walk through the EventLogFile object query.
• What happens to an encrypted field in a SOQL WHERE clause?

Data domain probes the board will focus on:

• Walk through the exact survivorship decision for a patient who appears in both AthenaPrime and NorthCare with different names (typo in one system). Which record wins and why?
• How does the CMRN cross-reference handle the LabConnect SFTP files that use NorthCare MRN format for acquired-clinic patients?
• How do you test the dedup algorithm at production-comparable scale without PHI in sandbox?
• What happens on Day 1 of go-live if an HL7 message arrives for a patient who was in NorthCare only and their CMRN was not migrated due to a migration gap?

---

What Would Fail

Anti-pattern 1: Static sharing rules for cross-facility access. A criterion-based sharing rule (e.g., “Clinical users see all patients”) would satisfy Requirement 8 but violate Requirement 9. There is no static rule that opens access during an encounter and closes it after. A board that hears “sharing rule” as the answer to cross-facility access will probe immediately.

Anti-pattern 2: Relying on object-level permissions to restrict billing staff from clinical fields. Billing users can query clinical fields via SOQL from the API if only object access is set. FLS must be explicitly denied on clinical fields in the billing profiles. Any solution that does not mention FLS enforcement at the API layer will fail the Security domain.

Anti-pattern 3: Building the integration with hard-coded MRN formats. If the HL7 parser or SFTP processor maps identifiers based on known MRN prefix patterns (e.g., “AP-” for AthenaPrime), the design breaks when two more acquisitions add new MRN formats. The Patient_Identifier__c cross-reference table with Identifier_Type__c is extensible; hard-coded parsing logic is not.

---

Scoring Rubric

Criterion	Weight	What a passing answer looks like
Security and Sharing Model	30%	Role hierarchy defined; cross-facility mechanism named (Apex Managed Sharing + Platform Event); FLS enforcement at UI and API; Shield suite justified; BAA sequencing correct
Integration Architecture	25%	All three channels addressed with trigger, payload, error handling, retry, logging; CMRN lookup embedded in each channel; SFTP SFTP constraint acknowledged with thin external component
Data Model and MPI	20%	CMRN as load-bearing key; Patient_Identifier__c cross-reference design; survivorship rules for overlap population; inactive patient handling
Migration Strategy	15%	Dedup sequencing before MPI; synthetic data for pre-BAA testing; NorthCare decommission criteria; October freeze deadline acknowledged
Reporting and Completeness	10%	All 5 reporting requirements addressed; facility scoping enforced through sharing; CISO audit path without IT; integration health dashboard

---

Self-Assessment Checklist

• Can you name the exact mechanism for cross-facility access (Platform Event, Apex Managed Sharing) and explain what happens at encounter close?
• Can you describe how each of the three integration channels resolves a patient identifier to the CMRN before writing?
• Can you articulate why Shield is required (which specific requirements demand each Shield component)?
• Can you walk through the survivorship rule decision for a specific overlapping patient example?
• Can you explain why FLS at the API layer matters for billing staff, not just profile/OWD?
• Can you describe the sandbox data strategy that satisfies the BAA constraint during dedup testing?
• Can you trace what happens when a LabConnect file arrives with an unrecognised MRN, step by step through to the T+8h escalation?
• Can you explain how the design accommodates two future acquisitions without re-architecture on the integration side and the sharing side?

---

Q&A Prep

Q: Requirements 8 and 9 are in direct tension. Walk me through exactly how you resolve that. A: Standard sharing rules are static and cannot open or close based on encounter state. The solution uses a Platform Event fired when an encounter moves to Checked_In status. A triggered Flow calls Apex that creates a manual sharing record granting the provider Read on the patient’s Account. When the encounter closes, a second trigger removes that sharing record. Outside an encounter, the provider’s role-based sharing rule limits visibility to their home facility. A nightly cleanup job catches any stale sharing records in case the close trigger fails.

Q: What prevents a provider from keeping an encounter open indefinitely to maintain access to a patient they are no longer treating? A: The encounter-close trigger removes the sharing grant. If an encounter remains open beyond a configurable threshold (e.g., 24 hours with no clinical activity), a compliance alert fires to the Facility Director. This is a process control rather than a technical lock. A provider can abuse it, but it will be visible in the audit log and escalated.

Q: An HL7 ADT message arrives for a patient with an unrecognised identifier. What happens? A: The message payload is written to Integration_Error_Queue__c with status Unmatched and the arrival timestamp. A task is created for the integration team. A scheduled Flow runs every 30 minutes. If the record has been unmatched for more than 4 hours, it escalates to the IT Director. The message is not discarded. The raw payload is preserved for manual resolution or re-processing once the CMRN is created.

Q: Why can’t you just use object-level access to prevent billing staff from seeing clinical fields? A: Object-level access controls whether a user can see the object at all. Field-level security controls access to individual fields. A billing user with read access to Encounter__c can query all fields on that object via the API unless FLS is explicitly set to read=false on clinical fields. For any user with API access, a SOQL query bypasses the page layout. FLS must be denied at the field level for the billing profile, and any Apex code querying PHI fields must enforce WITH USER_MODE or field-describe checks.

Q: How do you test the dedup algorithm at production-comparable scale without loading real PHI into sandbox? A: Generate synthetic patient data that mirrors the statistical properties of the real dataset: same MRN format lengths and prefixes, same approximate duplication rate (~4%), same missing-field rate (~7%), same name/DOB pattern distributions. Run the survivorship algorithm against this synthetic set and validate that the merge counts and completeness scores behave as expected. The BAA is not yet signed at this stage, so no real data can be present.

Q: The LabConnect SFTP file uses different MRN formats for NorthCare vs. AthenaPrime patients. How does the integration know which lookup to run? A: Each row in the fixed-width file includes a source-facility code. The Apex parser reads this code and maps it to an Identifier_Type__c value (e.g., NorthCare or AthenaPrimeMRN). The Patient_Identifier__c SOQL lookup filters on both Facility_MRN__c and Identifier_Type__c. This design works for the two future acquisitions by adding a new identifier type code without changing the parser logic.

Q: ClearBill has no-change requirement. How do you handle a scenario where ClearBill changes its OAuth token endpoint? A: Named Credentials store the OAuth endpoint URL. Updating the Named Credential record is a configuration change, not a code change. No Apex needs to be redeployed. This is one reason Named Credentials are used rather than hard-coding the auth endpoint in Apex.

Q: How does the CISO pull an audit report for a specific patient without calling IT? A: Two sources depending on the window. EventLogFile is a Salesforce standard object: Event Monitoring stores access events in daily log files queryable via SOQL on EventLogFile where EventType = ‘ApexExecution’, ‘API’, ‘LightningPageView’, etc. Native retention is 30 days and can be extended to a maximum of 1 year with Shield Event Log File Storage, which covers the recent audit window. For anything older, a nightly Apex job exports EventLogFile content to a customer-managed S3 archive with a 6-year lifecycle policy; the CISO queries the archive through a CRM Analytics external connector or Athena / Tableau connection. Field Audit Trail stores field-level change history on the FieldHistoryArchive object. The CISO profile has Read access to all three sources. A single dashboard with a patient record ID filter lets the CISO generate the access history for any record over a user-specified date range and export to CSV, all without IT for standard queries.

Q: How do you scope the claims performance report so billing managers see only their facility but the VP Revenue Cycle sees all three? A: The report type filters on Facility__c. The VP Revenue Cycle sits above the three Billing Manager roles in the role hierarchy, so the standard role-based sharing rule grants the VP read access to all facility encounter records. Each Billing Manager’s role only grants visibility to their own facility’s encounters. The same report, same dashboard. Visibility is enforced by the sharing model, not by report parameters.

Q: Walk through what happens if the encounter-close trigger fails and the sharing grant is never removed. A: The nightly cleanup Apex job queries for manual sharing records on Patient Accounts where the linked encounter has been in Closed status for more than 24 hours. It deletes those records. The job logs how many records it cleaned up. If that count exceeds a threshold (indicating the trigger is failing regularly), an alert fires to the IT Director. This is a compensating control, not a primary control.

Q: The program budget is $1.4M. Where does that put MuleSoft in the conversation? A: MuleSoft Anypoint Platform licensing starts at a level that would consume a material portion of a $1.4M budget covering licenses, implementation, migration, and year-1 support for 450 users. The integration volumes here (2,000 HL7 messages/day, 780 lab results/day, one synchronous REST channel) are within Salesforce platform capabilities. The constraint pushes toward Salesforce-native integration with one lightweight external component for SFTP retrieval only.

Q: How does the design handle two additional facility acquisitions without re-architecture? A: Integration: each new facility adds a new Identifier_Type__c value to Patient_Identifier__c and a new Named Credential for ClearBill. No Apex changes. Sharing: each new facility adds a new Facility Director role branch under the root. The sharing rule template applies to the new role automatically if structured as a role-based criterion rather than a named role. The Platform Event / Apex Managed Sharing logic for cross-facility access is facility-agnostic: it grants access based on the encounter record, not a hard-coded facility list.

Q: What is the go/no-go criterion for NorthCare decommission? A: All active patient records migrated and verified (record count match, field completeness audit). CMRN cross-reference validated: every known NorthCare MRN resolves to a Health Cloud CMRN. All three integrations live on Health Cloud. Clinical reviewer queue for merged records open and actively worked. Data quality dashboard showing missing-insurance remediation in progress. A final production parallel-run period (typically 2-4 weeks) where both systems receive the same transactions and results are compared.

---

Presentation Notes

Lead with the two hardest decisions: cross-facility access tension (Requirements 8 and 9) and the CMRN as load-bearing key. The board will spend the most time probing these. Open with “here is the security model tension and how I resolve it” before touching integration or reporting.

Diagram the security model, not just the system landscape. Draw the role hierarchy with facility branches. Show where the sharing grant appears and disappears. The board needs to see you have thought through the state transitions, not just the static structure.

Name the Shield components explicitly. Saying “encryption” is not enough. Say “Shield Platform Encryption with tenant-managed keys and deterministic encryption for query-able fields.” Saying “audit logs” is not enough. Say “Event Monitoring with EventLogFile object, supplemented by Field Audit Trail on PHI fields for 7-year history.”

On integration, address SFTP honestly. Salesforce cannot natively connect to SFTP. Acknowledging the constraint and naming the thin external component (AWS Lambda or equivalent cloud function) shows technical honesty. Trying to pretend Salesforce handles SFTP natively will be challenged immediately.

Time check at 20 minutes: if you are still on security model, accelerate through integration by summarising each channel in two sentences (trigger, error path) and moving quickly to migration. The board will probe integration in Q&A if they want depth.

Reporting is table stakes. Spend no more than 2 minutes on it in the presentation. The board knows you can build reports. Spend those minutes on the CISO audit path and the VP cross-facility vs. billing manager scoped visibility. Those are the places where the sharing model shows up in reporting.

---

Always verify against official Salesforce documentation

This content is study material for CTA exam preparation. Content compiled and presented with AI assistance. Not affiliated with Salesforce.