How Does MODPA’s Approach to Sensitive Data Differ from Other State Laws?

For Developers: This Changes How You Handle Data

You’re building an app. You need to collect user data to make it work. Health data for a fitness tracker. Location data for a delivery app. Preference data for personalization.

Every state has rules about this. But Maryland’s MODPA takes a fundamentally different approach to sensitive data. As developers, we need to understand this.

The Standard Approach: Opt-Out Model

Most U.S. privacy laws follow California’s lead. Here’s how CCPA handles sensitive data:

California’s approach:

1. Collect the data you need
2. Inform users about collection
3. Give them an option to opt out
4. Honor opt-out requests within 15 days

This is an “opt-out” model. Collection happens first. User control comes second.

Example in code terms:

// Typical CCPA approach
if (!user.hasOptedOut) {
  collectSensitiveData(user);
}

MODPA’s Approach: Strict Necessity Standard

Maryland flips this logic. Under MODPA, you can’t collect sensitive data unless it’s strictly necessary for your service.

Maryland’s approach:

1. Determine if data is essential to your core service
2. If yes, collect it with proper consent
3. If no, don’t collect it at all

This is a “necessity-first” model. Necessity determines collection, not user opt-outs.

Example in code terms:

// MODPA approach
if (isStrictlyNecessary(dataType, service)) {
  if (user.hasGivenConsent) {
    collectSensitiveData(user);
  }
}

What “Strictly Necessary” Actually Means

MODPA defines this narrowly. Data is strictly necessary when you literally cannot provide your service without it.

Strictly necessary examples:

• A fitness app collecting heart rate data to track workouts
• A telehealth platform collecting diagnosis information to connect patients with doctors
• A medication reminder app processing health conditions to send relevant alerts

NOT strictly necessary:

• An e-commerce site collecting health data to “recommend better products”
• A social media app processing sexual orientation for “improved ad targeting”
• A news website tracking religious beliefs for “personalized content”

If you can deliver the core functionality without the data, it’s not strictly necessary under MODPA.

Technical Implementation Differences

This affects how you architect data collection:

Traditional approach (CCPA-style):

- Collect all beneficial data by default
- Provide opt-out mechanism
- Check opt-out status before processing
- Delete data on request

MODPA approach:

- Evaluate necessity before collection
- Request affirmative consent upfront
- Collect only if both necessary AND consented
- Never sell sensitive data

What Counts as Sensitive Data in MODPA

As a developer, you need to flag these data types:

Health and biometric:

• Mental or physical health diagnoses
• Health treatment or therapy information
• Genetic or biometric data
• Precise geolocation (within 1,750 feet)

Personal characteristics:

• Racial or ethnic origin
• Religious beliefs
• Sexual orientation
• Transgender or nonbinary status
• Citizenship or immigration status

Special categories:

• Personal data of anyone under 18
• Consumer health data

If your database stores any of these, MODPA’s strict rules apply.

The “No Selling” Hard Line

Here’s another key difference. Maryland completely prohibits selling sensitive data. No exceptions.

Other states let you sell sensitive data if users don’t opt out. Maryland says you can’t sell it even if users want to allow it.

For developers, this means:

• Remove sensitive data from any data pipelines going to third parties
• Never include sensitive data in advertising pixels or analytics that share with other companies
• Segregate sensitive data in your database architecture

Practical Example: Building a Fitness App

Let’s say you’re building a fitness app that operates nationwide.

Data you need to collect:

• Email (for login)
• Age (for personalized workouts)
• Weight and height (for calculations)
• Heart rate during workouts (for tracking)
• Location (for nearby gym recommendations)

Under CCPA:

• Collect all of it
• Provide opt-out option
• Process as permitted until user opts out

Under MODPA (for Maryland users):

• Email: Not sensitive, standard consent
• Age: Check if user is under 18 (extra protections)
• Weight/height: Sensitive health data, must be strictly necessary
• Heart rate: Sensitive health data, strictly necessary for core function
• Location: Sensitive if precise, evaluate if recommendations are core to service

How to Handle This in Code

You need geo-aware logic:

if (userLocation === 'Maryland') {
  // MODPA rules
  if (dataType === 'sensitive') {
    if (!isStrictlyNecessary(dataType)) {
      throw new Error('Cannot collect non-necessary sensitive data from MD users');
    }
    if (!user.hasGivenAffirmativeConsent(dataType)) {
      requestConsent(user, dataType);
    }
  }
} else if (userLocation === 'California') {
  // CCPA rules
  if (!user.hasOptedOut(dataType)) {
    collectData(user, dataType);
  }
}

The Automation Solution

Building this logic manually is complex. You need:

• Accurate geo-detection
• State-specific consent flows
• Regular updates when laws change
• Audit trails for compliance

Seers.ai handles this automatically. It detects user location, applies the correct consent logic, and updates when laws change.

For developers on WordPress or Shopify:

Deep dive on MODPA requirements: Maryland Online Data Privacy Act Technical Guide

What This Means for Your Next Build

When architecting data collection:

1. Identify sensitive data early in design
2. Evaluate strict necessity for your service
3. Build location-aware consent flows
4. Never sell sensitive data to third parties
5. Document your necessity justifications

Maryland’s approach is stricter. But it might become the model other states follow. Build with MODPA in mind and you’ll be ahead of the curve.