Elixir
Request a Demo
  • Electronic Health Record (EHR)Products
  • Revenue Cycle ManagementProducts
  • Eligibility VerificationProducts › Revenue Cycle Management
  • Electronic Prior AuthorizationProducts › Revenue Cycle Management
  • Denial ManagementProducts › Revenue Cycle Management
  • Professional and Institutional Claim PreparationProducts › Revenue Cycle Management
  • Electronic Visit VerificationProducts
  • Caregiver Mobile AppProducts › Electronic Visit Verification

Compliance & Security · Platform

The Salesforce Security LayerBeneath Elixir

Elixir is a managed package running inside your own Salesforce organization. A substantial set of security controls is therefore inherited from the platform rather than built by us — and a substantial set remains yours to configure. This page sets out which is which, so a security review can be answered precisely.

  • Foundational

    Protections built into the infrastructure and the platform, operating continuously. Nothing to enable, and nothing either of us configures.

  • Configurable

    Multi-factor authentication, single sign-on, permission sets, login IP restrictions, login history and the Security Health Check. Available at no additional cost, and governed by your policy.

  • Add-on

    Shield, Security Center, Privacy Center, Data Mask and Seed, Archive, and Backup and Recover. Licensed separately by your organization from Salesforce. Not included with Elixir.

  • Inherited, not rebuilt

    Infrastructure security, platform patching and availability come from the platform rather than from a vendor’s own data center.

  • Your identity, your policy

    Single sign-on, multi-factor authentication and session policy are configured in your organization and governed by your rules.

  • Four layers of access

    Organization, object, field and record. Access is granted rather than assumed, and is additive by design.

  • Audit you configure

    Elixir tracks changes to the fields you choose, on the objects you choose — without depending on the platform’s field history cap or an add-on license.

The model

What the Platform Provides, What You Configure, and What You Add

Salesforce describes its own security controls in three tiers. The distinction matters in a security review, because the second and third tiers are decisions your organization makes rather than features that arrive switched on.

Platform security controls by tier, and who acts on each.
TierWhat it coversWho actsCost
FoundationalProtections built into the infrastructure and platform, operating continuously in the background — physical security, platform patching, availability and the controls behind the platform’s own attestationsSalesforceIncluded
ConfigurableMulti-factor authentication, single sign-on, permission sets and least-privilege design, login IP restrictions enforced on profiles, login history reporting, and the Security Health Check dashboardYour organizationNo additional cost
Add-onShield, Security Center, Privacy Center, Data Mask and Seed, Archive, and Backup and RecoverYour organizationLicensed separately

The second tier is where most real exposure sits. It is also the tier most often assumed to be someone else’s responsibility. Multi-factor authentication is a platform capability, but whether it is enforced is your policy decision. Permission sets are a platform feature, but who holds which one is your configuration. Login history is produced automatically; whether anyone reviews it is an operational question no vendor can answer for you.

The third tier is not included with Elixir. Shield and the other add-on products are licensed by your organization directly from Salesforce. Elixir operates on the platform’s standard security model. If your organization licenses Shield, Elixir works alongside it — but it should be planned during implementation rather than added afterwards, because encrypting a field changes how some platform features behave.

What Elixir is responsible for is the application layer between the two: our managed package, its data model, the default permission and sharing design we ship, and our own organization’s controls. The full allocation of HIPAA safeguards across platform, vendor and covered entity is set out on the HIPAA Compliance Center.

A correction worth having

  • Encryption is not an access control. Shield Platform Encryption protects data at rest; it does not decide who may see a field. A user whose field-level security grants access reads the value in plaintext regardless.
  • Keeping information from a user is a job for profiles, permission sets, field-level security and the sharing model — not for encryption.
  • Any vendor answering “is it encrypted?” as though it settled “who can see it?” has answered a different question.

Two encryption answers that are certified

  • In transit. Elixir is certified for trusted connection, which tests that transport-level security is established in accordance with the standards the certification criteria name.
  • On the device. Elixir is certified for end-user device encryption under the alternative that applies to products which do not write health information to the device — electronic health information is not stored locally on the end-user machine. For a security reviewer worried about a lost laptop, that is a better answer than disk encryption.
  • At rest on the platform, Elixir operates on the standard Salesforce security model, as set out above.

Access

How Access Is Controlled: Four Layers, Granted Rather Than Assumed

The platform enforces access through four distinct layers. The model is grant-based, which means access is additive: a user has what has been granted and nothing else, and each layer narrows what the one above it permits.

  1. Layer 1 · Organization

    Who may log in at all

    User provisioning and deactivation, password policy, session settings, multi-factor authentication, and login IP restrictions. The outermost boundary, and the one that fails when a leaver keeps access.

  2. Layer 2 · Object

    Which kinds of record a user may work with

    Profiles and permission sets determine whether a user can read, create, edit or delete a given type of record at all — a care plan, a claim, a consent.

  3. Layer 3 · Field

    Which fields within those records

    Field-level security controls visibility down to the individual field. This is the layer that keeps a sensitive value out of view for a user who legitimately needs the rest of the record.

  4. Layer 4 · Record

    Which specific records

    The sharing model decides which individual records a user can reach — their own patients, their team’s, their site’s or their program’s. For behavioral health this is the layer that carries the most weight.

Elixir ships a default model across these four layers. Your administrators adapt it, and that adaptation is a clinical and governance decision as much as a technical one — which is why we would rather walk through it during implementation than hand over a default and call it configured. Three capabilities within this model are certified and tested rather than configured by you: authentication and access control, automatic access time-out after a period of inactivity you define, and emergency access for a limited, identified set of users. They are listed on the ONC Certification page with the rest.

Audit and retention

What the Standard Platform Retains, and Where the Limits Are

Audit retention is the question security reviewers ask that vendors most often answer imprecisely. There are three separate layers here — what the platform retains, what Elixir adds on top of it, and what an add-on license extends — and they are worth keeping apart.

On the standard platform

Setup Audit Trail records administrative and configuration changes and is retained for a defined period measured in months rather than years.

Field history tracking is available on a limited number of fields per object, with its own retention period. That cap is the constraint most organizations run into first.

In Elixir, independently of the platform

Elixir provides its own configurable field-level change tracking. You choose which fields on which objects are tracked, and changes are recorded with the action taken — created, updated or deleted.

This matters because it does not depend on the standard field history cap, and it does not require an add-on license. Where a field needs to be auditable for a clinical, consent or billing reason, it can be tracked because you decided it should be.

Alongside this, Elixir is certified for auditable events and tamper resistance, and for audit reports. For each permissible action the audit log records date and time, patient identification, user identification, type of action, and identification of the patient data accessed, together with the audit log status and the encryption status. Audit information is available to users and sortable by user, event time and event type. Those are tested at certification rather than described in a datasheet — see ONC Certification.

With add-on licensing

Shield extends the platform layer materially. Event Monitoring provides event-level visibility with longer retention, and Field Audit Trail extends field history retention well beyond the standard period. Both require your organization to license them from Salesforce.

We would not quote you a retention figure for either. The published figures vary by component and by license, and a vendor repeating a number from a marketing page is not a reliable basis for a retention policy. Confirm the position for your own subscription.

Questions worth putting to Salesforce rather than to us

  • Which services are covered by your Business Associate Agreement, and does your intended use fall inside that list? Some services, including several analytics and artificial intelligence features, sit outside it.
  • What are the data residency commitments for your organization, and do they cover processing and support access as well as storage at rest?
  • Which attestations and certifications apply to your specific services and infrastructure? Scope varies, and a certification held for one deployment model does not automatically apply to another.
  • What encryption is applied by default, and what does your agreement require of you? The obligation and the default are not always the same thing.

Attribution

Platform Attestations Belong to the Platform

A distinction that matters more in procurement than it appears to in marketing.

Salesforce maintains a broad set of attestations and certifications covering the platform, including SOC reports, ISO standards and others. Scope varies by service and by infrastructure, and the reports are obtained by you from Salesforce under your own agreement with them. They are the platform’s, not ours, and we will not present them as evidence about Elixir.

What is ours. Elixir is certified under the ONC Health IT Certification Program, certified by an ONC-Authorized Certification Body on 21 July 2023 under certificate number 15.05.05.3165.MRKT.01.00.1.230721. That record is public and independently verifiable, and the eleven privacy and security criteria it covers are listed in full. Mirketa, which develops and operates Elixir, maintains a SOC 2 Type II report, available to customers and prospects under a non-disclosure agreement. Elixir is distributed through the Salesforce AppExchange and has passed its Security Review.

What the Security Review is, and is not. It is an assessment by Salesforce of a partner application, covering code scanning and testing before distribution. It is a point-in-time review of the application. It is not an assessment of HIPAA compliance, it is not a certification of our organization, and Salesforce does not guarantee the security of partner applications. We mention it because it is real, and we describe its limits because a security reviewer will ask about them.

For your security review

Reviewing the platform beneath the application

We can walk your security team through the access model, the default permission design we ship, and the division of responsibility between the platform, Elixir and your organization.