Healthcare industry data model ERD
The following entity relationship diagram (ERD) represents a standardized data model for the healthcare industry. The ERD is intentionally presented in a de-normalized fashion and with consideration for how data is stored in Adobe Experience Platform.
NOTE
The ERD as described is a recommendation for how you should model your data for this industry use case. To make use of this data model in Platform, you must construct the recommended schemas and their relationships yourself. See the guides on managing schemas and relationships in the UI for more information.
Use the following legend to interpret this ERD:
- Each entity shown in is based on an underlying Experience Data Model (XDM) class.
- Fields indented under a parent field represent a child field, or sub-field, that belongs to the parent’s field group.
- The most important fields for a given entity are highlighted in red.
- All the properties that could be used to identify individual customers are marked as “identity”, with one of these properties marked as a “primary identity”.
- Entity relationships are marked as non-dependent, since cookie-based events often cannot determine the person or individual who did the transaction.
NOTE
Each entity includes an “_ID” field, which represents the unique string identifier (
It is important to distinguish that this field does not represent an identity related to an individual person, but rather the record of data itself. Identity data relating to a person, event, or business entity should be relegated to identity fields provided by compatible field groups instead.
_id) attribute for the record or event in question. This field is used to track the uniqueness of the individual record or event, prevent duplication of data, and look up that data in downstream services. In some cases, _id can be a Universally Unique Identifier (UUID) or Globally Unique Identifier (GUID).It is important to distinguish that this field does not represent an identity related to an individual person, but rather the record of data itself. Identity data relating to a person, event, or business entity should be relegated to identity fields provided by compatible field groups instead.
Healthcare use cases
The following table outlines the recommended classes and schema field groups for several common healthcare use cases.
Use case
Recommended classes and field groups
Improve digital acquisition and experience among consumers shopping for insurance. Examples include:
- When people access a page containing general information (such as plans, plan names/tiers, medicaid, wellness programs, and so on), understand their behavior and what they are looking for in order to send promotional emails or target them on third-party platforms with ads.
- When people search for heart health and vaccine information, send them vaccine-related info on heart health to create brand awareness or ask them to schedule vaccines.
-
- Healthcare Member Details
- Relationship field(s) established between
planIDattributes and schemas that use the Plan class.
-
Plan:
Increase digital acquisition of patients through targeted ads based on past online behavior and health data.
Improve enrollment and account creation in health plans by tracking marketing of insurance through different channels, in order to understand how a customer found out about an insurance company.
Avoid lapses in medical insurance coverage.
Promote drug information to providers using direct-to-customer (DTC) ads.
recommendation-more-help
62e9ffd9-1c74-4cef-8f47-0d00af32fc07