From ac09966ac06fe6cf61a5cde64fe63a2dbc2264fd Mon Sep 17 00:00:00 2001 From: haworku Date: Mon, 17 Jul 2023 10:48:43 -0500 Subject: [PATCH] Add ADR link Update contract-rate-refactor-relationships.md --- .../contract-rate-refactor-relationships.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/technical-design/contract-rate-refactor-relationships.md b/docs/technical-design/contract-rate-refactor-relationships.md index b73b4d1c8c..71f39be3e8 100644 --- a/docs/technical-design/contract-rate-refactor-relationships.md +++ b/docs/technical-design/contract-rate-refactor-relationships.md @@ -1,7 +1,7 @@ # Contract and Rates Refactor: Historical Relationships in Tables ## Overview -This is a big one. From the beginning of this project our application data model has been built around the health plan package. We are shifting now towards a data model built on health plan contracts and health plan rates as distinct entities. See ADR #023. This document outlines our approach to storing contract and rates as separate entities with historical relationships. +This is a big one. From the beginning of this project our application data model has been built around the health plan package. We are shifting now towards a data model built on health plan contracts and health plan rates as distinct entities. See [ADR 023](../architectural-decision-records/023-seperate-contract-rates-tables-postgres.md). This document outlines our approach to storing contract and rates as separate entities with historical relationships. ## Constraints - Need rates to be able to be associated to many contracts (rates across submissions) @@ -147,7 +147,7 @@ B.0, 3.0, 2020-01-02, 2020-01-04, false ``` This will give us a new entry in our rate 1 history, and we can attribute it to the correct submission because we have the isRemoved bit: -```` +``` 2020-01-01: – initial submit of rate 1 1.0 -> A.0 1.0 -> B.0 @@ -160,4 +160,4 @@ This will give us a new entry in our rate 1 history, and we can attribute it to ## Migration plan summary -Existing HealthPlanPackage submissions will be converted into Contract and Rates in the db. Since we will be working on the migration work behind a feature flag, we can write a migrator that runs repeatedly, taking the old protobuf encoded FormData and moving that data into our new Contract[Revision] and Rate[Revision] tables. This way we can test and refine our migration before we actually switch over to using the new data. +Existing `HealthPlanPackage` submissions will be converted into Contract and Rates in the db. Since we will be working on the migration work behind a feature flag, we can write a migrator that runs repeatedly, taking the old protobuf encoded FormData and moving that data into our new `Contract[Revision]` and `Rate[Revision]` tables. This way we can test and refine our migration before we actually switch over to using the new data.