AWS for Industries

The value of a system of record for healthcare payors

Leaders in the healthcare industry are increasingly recognizing how a data-driven approach can help them improve member satisfaction. Many of them have begun their transformative journey to adopt a member-first approach and unify disparate data silos. They recognize that the journey toward a unified system is strategic and will pay enormous dividends when completed.

However, the complexity of legacy healthcare applications and a lack of experience in designing, implementing, and managing next-gen solutions are forcing them to reconsider their approach. They are constantly asked to deliver such strategic initiatives in a limited amount of time, budget, and resources. Due to this, customers are driven towards a tactical point-to-point approach to exchange member information across healthcare systems.

This non-strategic approach can cause applications to gradually evolve into a complex system that is tightly integrated and extremely difficult to manage. This results in several challenges including higher maintenance cost, compromised application security, and decentralized governance around sensitive member information. These architectural trade-offs can impact the company’s broader digital transformation initiatives.

Using such a tactical approach to repeatedly solve today’s problem can cause you to overlook the foundation of tomorrow’s requirements.

Overview of a System of Record

Healthcare organizations use a variety of applications to manage information about their members’ demographics, claims, wellness, plan affiliation, primary and critical care, call center, and self-service interactions. The problem with these individual systems is that they are mostly disconnected and make decisions based on outdated information.

A system of record brings together all aspects of a member’s attributes into a centralized repository (hub) from the disparate data silos (spokes). This hub-and-spoke model builds a system of record for both upstream and downstream systems. Using a system of record as the backbone, organizations can bring together quality member attributes to gain a 360-view of a member’s data called Member360. This Member360 enables members to have a seamless experience across various systems for healthcare payors.

Building 360' view around member information

Building 360° view around member information

Leading healthcare organizations have learned that a system of record is a strategic next-gen architecture. To get there, there are three practical steps to follow:

  1. Clarify your business objectives and the advantages of this architecture
  2. Realize that achieving a system of record can only be accomplished through a series of iterations
  3. Choose the right technology platform that supports seamless digital transformation and modernization without complexity

Functional Objectives and Advantages

One of the myths of building a system of record is the thought that there is no immediate business value and that value can only be measured long-term. It is important to design business deliverables that immediately show value, rather than at the final end day. It can be difficult to define the entire business objectives for large initiatives, such as a system of record.

The key is to isolate smaller problems and iterate, ensuring that the underlining architecture and platform evolve accordingly, without having to wait on long-term results. It works best if a true business value is delivered quickly (between 3-6 months) to defend the project.

Take an agile approach to delivering incremental business value. This way you can adjust as you continue to iterate. In this way, you can build a long-term initiative on the back of short-term efforts. This iterative approach can be utilized for any business use-case. Specifically, with the top three industry trends which are:

  1. Real-time Integration
  2. Operational Reporting
  3. Enterprise Analytics

Real-time Integration

Customer Relationship Management (CRM) systems, Claims Management Systems (CMS), and Member Portals are examples of applications that can have a significant impact on members’ digital experiences for payors. Members digitally interact with healthcare core systems through call centers, chatbots, and self-service options. A near real-time service level agreement across these channels will improve the customer experience. These systems can connect directly to the system of record to consume Member360 data with low latency. This results in a faster claims adjudication process, improved self-service, and a more personalized digital experience.

For example, Jane Doe, 65 years old, is suffering from a pre-existing condition of type 2 diabetes. She calls customer service to find out the current status of her last outpatient claims. Customer service reviews her information and discovers that the address information in the CRM system is out of date. The claims check was issued to the incorrect address. This scenario can easily be avoided if the CRM system integrated data from a system of record as its source of truth.

Operational Reporting

Healthcare internal systems such as audit and compliance, financial oversight, and claims processing rely on quality member information. Operational reporting in various formats like delimited files, fixed width files, and variable width files is a popular way to periodically exchange member data. A system of record can simplify integrations with downstream systems and help them to consume a 360-degree view of member information at a single point of entry.

By enabling version control on the system of record, healthcare organizations can build complex reports (as-is, as-was) for audit, compliance, and third-party needs. Internal Data Science teams can also perform data mining on quality and trusted member information without going across multiple siloed systems.

Enterprise Analytics

Healthcare executives can build informed strategic decisions based on analytical insight from historical datasets in a system of record. The trusted member-centric information inside the system of record will help the organization predict healthcare outcomes and build a personalized approach to increase member participation in preventive care. This strategy will help you provide a better outcome for your members. Healthcare organizations can use systems of record to build personalized care gap reports for individual members and use various methods of outreach to improve participation in preventative care.

Back to our example with Jane Doe, her condition requires frequent care to avoid critical illness, but there are situations where she has forgotten to schedule her visit with primary care. Using her member profile, payors can easily identify the gap and proactively reach out to her to schedule overdue visits.

As you learn from each iteration, you can apply it to improve the member experience. Organizations can use AI/machine learning (ML) models on systems of record to build automation in claim workflow, premium forecasting, fraud and abuse detection to define your company’s functional objectives and advantages.

Non-Functional Objectives and Advantages

Non-functional objectives are technical system requirements that ensure your system of record follows the principles of a well-architected framework. These requirements are just as important as functional requirements. Failure to meet non-functional requirements can lead to compromised security, reliability, performance, scalability issues, and can increase costs.

Choosing the right platform and data strategy for your system of record is critical to its success. Key non-functional requirements for designing a reliable system of record are:

  • Schema Agnostic
  • System Scalability and Availability
  • Centralized Security and Governance
  • Data Lineage and Traceability
  • Ease of Integration
  • Cost Effectiveness

Non-functional requirements are the foundation a system of record

Non-functional requirements are the foundation a system of record

Schema Agnostic

A system of record must support structured, semi-structured, and unstructured data. Implementing an iterative approach requires evolving data models so the most structured record today will evolve over time and involve schema change tomorrow. Supporting schema-agnostic platforms for the system of record will provide a high-level of tolerance for all schema changes. This allows businesses to save money by avoiding a costly redesign with an evolving schema.

System Scalability and Availability

A majority of healthcare systems have strict SLAs in place to define minimum uptime and performance. The system of record is an essential component in order to support downstream operations. It should support resource scaling in and out to meet downstream demands for near real-time integrations, operational reporting, and enterprise analytics. It is critical to use underlying services that provide such elasticity and agility to provide on-demand resources. Furthermore, during an outage, the system of record must remain operational to avoid a single point of failure. To ensure redundancy, every point of your architecture should be challenged. This will allow you to continue operating and performing during peak loads and localized disasters.

Centralized Security and Governance

In the healthcare industry, access to Personally Identifiable Information (PII) and Protected Health Information (PHI) is strictly controlled. Using the least privilege principle, fine-grained access control and redaction methodologies on sensitive member attributes inside the system of record can lead to a unified approach to managing enterprise security. It’s vital that all access to member data be tracked, traced, and audited to meet compliancy needs. This can ensure compliance with healthcare regulatory requirements.

Data Lineage and Traceability

Keeping track of the data lineage as it goes through multiple iterations is a critical component of a traceable system of record. Data lineage attributes can consist of source system identifiers, processing timestamps, iteration identifier and point-in-time snapshots for member records. These attributes assist in producing complex history reports (as-is, as-was) for downstream applications. It enables point-in-time reporting for healthcare organizations to recover from a targeted failure or meet compliance requirements. This also helps to build a discoverable system that can help to troubleshoot any data discrepancies.

Ease of Integration

The primary goal of a system of record is to make integration with downstream as simple as possible. CRM systems, claims management, member wellness, primary and critical care systems, and self-service portals should all seamlessly connect and consume quality member data. Ascertain that the system of record supports out-of-the-box integrations that allow for integration across major native protocols. To ensure minimal disruption at downstream applications, a system of record must support no/low-code ETL (extract, transform, load) technologies that support transforming the data into required formats and schemas. This will be beneficial as it helps with an ease of integration, platform interoperability, and prevents a complex redesign effort for downstream.

Cost Effectiveness

A system of record must meet all non-functional requirements under an enterprise budget. The system should not impose significant infrastructure and operational costs. You can use techniques such as tiered storage, on-demand compute, open-source technologies, optimum backup and disaster recovery strategies to reduce your overall infrastructure costs. Using managed services and serverless technologies will help you off-set operational costs for instituting a system of record.

Reference Architecture – An Iterative Approach

Having discussed the functional, non-functions requirement, and an iterative approach, let’s go over the reference architecture of a system of record. Typically, it includes four layers:

  1. Staging Layer
  2. Processing Layer
  3. Canonical Layer
  4. Delivery Layer

Reference architecture for a system of record

Reference architecture for a system of record

Staging Layer

Consider this a staging area for data as it moves from sources to the system of record. It is primarily used by the data ingestion process as a landing zone for new data. This layer can store structured, semi-structured, and unstructured member information while preserving the source data format and schema. One advantage of a staging layer is that it keeps a copy of stored data in its original, raw format for an indefinite period of time. You can create an archival strategy and tiered storage to keep the cost of growing the staging layer under control.

Processing Layer

The next layer is called the data processing layer. This layer can involve data standardization, deduplication, and enrichment. The layers include transformation logic to convert data into a common format. For example, changing the member DOB across all data records to YYYY-MM-DD format. The enrichment process includes the process of enhancing existing member information by supplementing missing or incomplete data. For example, ICD 10 codification is based on member claims information. The deduplication includes selective logic to provide preference to a system over others if conflicting information is received. For example, prioritizing systems to provide the latest member demographic details. This layer includes business logic to standardize data into a canonical format.

Canonical Layer

As an output to the processing layer, the data is standardized to construct the canonical layer. This layer represents the data entity and relationships in their simplest form. This target-facing layer has curated attributes and a 360-view of a member’s profile for downstream consumption. This layer is highly denormalized to reduce overhead and improve performance during system integration. Having the canonical layer interface with downstream systems helps to reduce translation during data delivery and centralized business logic maintenance. It’s advisable to build the canonical layer iteratively, as it continuously ingests new data. It’s often easier to store this layer with NoSQL databases. Depending upon the complexity of member information, you can choose key-value pair, document, or graph databases.

Delivery Layer

The final layer of a system of record is data delivery, also known as the egress layer. This layer will act as a single point of entry for all downstream requests to consume member profiles. It will connect to a wide range of enterprise internal and external systems using real-time, near real-time, and batch connectors.

The downstream system requires unparalleled scalability and availability to meet their demand. For example, a member portal or CRM applications may require single digit millisecond latency to retrieve member information in order to provide the best member experience. You can use RESTful or HTTP APIs for near real-time downstream integration and ETL services for operational reporting.

Often, bringing every attribute of a member’s information into a data foundation layer can be challenging for an enterprise application. In this case, use API orchestration techniques to build near real-time connectors across applications and third-party providers. This will continuously provide you a single point of entry and a 360-view of member profiles for downstream applications.

Putting all these together – An AWS Approach

The Amazon Web Services (AWS) approach of building a modern system of record is to deploy Lake House Architecture. This architecture consists of a scalable data lake, purpose-built data services, seamless data movement, unified governance and security with cost-effective implementation. In our subsequent blog, we will go into detail about how to build a system of record for healthcare members on AWS.


Creating a system of record is an important part of a customer’s journey of digital transformation. It helps to better serve members and provides positive outcomes for healthcare organizations. From this blog you should now be able to identify some of the functional requirements and benefits for implementing a system of record. Constructing key non-functional requirements can improve architectural resiliency with an approach to deliver on today’s challenges while still creating building blocks for tomorrow’s strategic architecture.

You can learn more about AWS healthcare solutions and case studies and to find out more about how AWS (or our partners) can help you, please contact your representative.

Abhishek Srivastav

Abhishek Srivastav

Abhishek Srivastav is a Senior Solutions Architect at AWS. He is passionate about enabling customers to accelerate their cloud adoption. He is an IoT enthusiast and holds deep expertise in NoSQL databases, analytics, and AI/ML technologies. He is passionate about finding answers to complex problems by drawing on his in-depth understanding of these technologies. He has held lead positions for NoSQL Center of Excellence roles at various enterprise customers prior to joining AWS

Jason Hunter

Jason Hunter

Jason Hunter is a Principal Solutions Architect specializing in DynamoDB. He’s been working with NoSQL Databases since 2003. He's known for his contributions to Java, open source, and XML.

Qualen 'Q' Bradley

Qualen 'Q' Bradley

Qualen 'Q' Bradley is an Enterprise Account Executive at AWS. He has a deep well of experience with helping Enterprise customers across various verticals accelerate business growth and innovation by leveraging AWS services and architectural best practices. He is particularly passionate about democratizing technology, ethics in technology, and making AI/ML tools available for both technical and business users.