Difference between revisions of "Implementing versioning"

From PegaWiki
Jump to navigation Jump to search
(1\28 update)
Tag: Visual edit
(updated application name and industry)
Tag: Visual edit
 
(18 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{New request
+
{{Design pattern|Title=Implementing versioning|Description=Design inputs while implementing versioning in PCS|Version=8.5|Applications=Pega Product Composer for Healthcare|Capability Area=Healthcare and Life Sciences|Owner=shahp@pegasystems.com}}
|Request to Publish=
+
In Pega Product Composer for Healthcare, entities such as a benefit or plan can undergo changes in their life cycles. Workflows of these entities generally progress at different times in discrete phases. During a phase, you might need to allocate a different set of data or enforce different business rules. In these situations, you can represent the changes to an entity in time blocks. Each time block of an entity is a version. The effective and end dates in PCS are used as the time blocks and they drive versioning for all entities in PCS.
|Curator Assigned=shahp@pegasystems.com
 
|Description=Implement versioning
 
|Applications=Pega Product Composer for Healthcare
 
|Capability Area=Healthcare
 
|Version=
 
}}
 
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓  '''<big>Please Read Below</big>'''  ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
 
  
Enter your content below. Use the basic wiki template that is provided to organize your content.  After making your edits, add a summary comment that briefly describes your work, and then click "SAVE". To edit your content later, select the page from your "Watchlist" summary. If you can not find your article, search the design pattern title.
+
For more information about how versioning works in PCS, see [https://community.pega.com/knowledgebase/articles/pega-product-composer-healthcare-implementation-guide/85/versioning Versioning].  
  
When your content is ready for publishing, next to the '''"Request to Publish"''' field above, type '''"Yes"'''. A Curator then reviews and publishes the content, which might take up to 48 hours.  
+
In the Enter details step of all entity creation, the following two core properties drive the versioning logic in PCS:
 +
* '''Effective date'''
 +
* '''End date'''
 +
Whenever you change one or both of these dates, the PCS application automatically creates a new major version for the new entity. If these dates are not changed and any other property is changed on the entity, the application creates a minor version. For example: 
  
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ '''<big>The above text will be removed prior to being published</big>''' ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
+
# User A creates a new e-visit benefit. Version 01-01 is assigned by the application.
 +
# User A moves the benefit to the ''Dev-Approved'' status. The benefit is now in the ''Dev Approved'' work queue and is available in the application’s search list with the ''Dev-Approved'' work status.
 +
# Later, User A opens the entity in the application, and clicks '''Save as new version'''.
 +
#* If User A clicks '''Next''' without changing the effective date or end date or both, the next minor version, 01-02, is assigned to the e-visit benefit. Now there are two versions in the application, 01-01 and 01-02, for that entity.
 +
#* If User A clicks '''Next''' after changing the effective date or end date or both, the next major version, 02-01, is assigned if there are no existing versions in the system with the new dates that were entered.  Now there are two versions in the application, 01-01 and 02-01, for that entity.
  
=== Versioning in PCS ===
+
== Extend versioning in PCS ==
In Pega Product Composer for Healthcare, entities such as a benefit or plan can undergo changes in their life cycle. Workflows of these entities generally progress at different times in discrete phases. During a phase, user might need to allocate a different set of data or enforce different business rules. In these situations, user can represent the changes to an entity in time blocks. Each time block of an entity is a version.
+
The centralized ''D_NewVersion'' data page, which is found in the ''PegaHC-USA-PCS:08-01-0'' ruleset, drives the versioning for all entities in PCS. To change the default versioning logic, you can add any other property from the implementation layer or base PCS layer to the ''D_NewVersion'' data page. For more information about using data pages, see [https://community.pega.com/sites/default/files/help_v85/index.htm#oxy_ex-1/platform-helpsystem/rule-/rule-declare-/rule-declare-pages/data-pages-con.htm Data pages].      
  
The time block used in PCS are effective dates and these dates drive versioning for all entities in PCS.
+
There could be many scenarios in which you might want to enhance the versioning logic, such as having open-ended plans, controlling the versions of plans for a particular calendar year, having the versioning for plans for a specific line of business, or adding versioning based on input requests from a sales automation system.  
  
Users can find detailed explanation about how versioning works in PCS at https://community.pega.com/knowledgebase/articles/pega-product-composer-healthcare-implementation-guide/85/versioning
+
== Design inputs ==
 +
When you try to enhance the versioning logic, you need to keep the auditing needs of the organization in mind. The use of a centralized module for versioning means that the changes are applied to all entities. One of the most common inputs to the design for versioning is the process by which the plans change from year-to-year and the compliance requirements changes in reporting. You must also keep in mind the overall stage in which the updates occur and adjust the versioning configuration accordingly. To prevent updates from occurring to the plans in the '''Production''' stage without changing the version, you can update the configuration page by clicking  '''Configure -> Product Composer System -> Configuration''' in Dev Studio. 
  
=== What affects versioning  ===
+
Understanding the configuration options available for the versioning logic is extremely critical. With this knowledge, you can act as informed advisors to the business team throughout the life of the project. Additionally, you can also facilitate and deliver quick results if the business team wants to extend the versioning logic to properties beyond the effective dates without breaking any guardrails and keeping compliant with Pega's best practices.
On the metadata screen of all entities, we have two properties
 
 
 
1) Effective date
 
 
 
2) End date
 
 
 
These two dates are the core properties driving the versioning logic in PCS.
 
 
 
There is a centralized
 
 
 
=== Design inputs, how to plan versioning and updates ===
 
=== Extend versioning in PCS ===
 
There is a centralized data page "D_NewVersion" which drives the versioning for all entities in 
 
 
 
== Results ==
 
Understanding the configuration options available for the versioning logic is extremely critical for the implementation team. With this knowledge, the implementation team can act as informed advisor to the business team throughout the life of the project. Not only that, the implementation team can also facilitate and deliver quick results if the business team wants to extend the versioning logic to properties beyond the effective dates, without breaking any guardrails and being in compliance with Pega's best practices.
 

Latest revision as of 20:29, 7 June 2021

Implementing versioning

Description Design inputs while implementing versioning in PCS
Version as of 8.5
Application Pega Product Composer for Healthcare
Capability/Industry Area Healthcare and Life Sciences



In Pega Product Composer for Healthcare, entities such as a benefit or plan can undergo changes in their life cycles. Workflows of these entities generally progress at different times in discrete phases. During a phase, you might need to allocate a different set of data or enforce different business rules. In these situations, you can represent the changes to an entity in time blocks. Each time block of an entity is a version. The effective and end dates in PCS are used as the time blocks and they drive versioning for all entities in PCS.

For more information about how versioning works in PCS, see Versioning.

In the Enter details step of all entity creation, the following two core properties drive the versioning logic in PCS:

  • Effective date
  • End date

Whenever you change one or both of these dates, the PCS application automatically creates a new major version for the new entity. If these dates are not changed and any other property is changed on the entity, the application creates a minor version. For example:

  1. User A creates a new e-visit benefit. Version 01-01 is assigned by the application.
  2. User A moves the benefit to the Dev-Approved status. The benefit is now in the Dev Approved work queue and is available in the application’s search list with the Dev-Approved work status.
  3. Later, User A opens the entity in the application, and clicks Save as new version.
    • If User A clicks Next without changing the effective date or end date or both, the next minor version, 01-02, is assigned to the e-visit benefit. Now there are two versions in the application, 01-01 and 01-02, for that entity.
    • If User A clicks Next after changing the effective date or end date or both, the next major version, 02-01, is assigned if there are no existing versions in the system with the new dates that were entered. Now there are two versions in the application, 01-01 and 02-01, for that entity.

Extend versioning in PCS[edit]

The centralized D_NewVersion data page, which is found in the PegaHC-USA-PCS:08-01-0 ruleset, drives the versioning for all entities in PCS. To change the default versioning logic, you can add any other property from the implementation layer or base PCS layer to the D_NewVersion data page. For more information about using data pages, see Data pages.

There could be many scenarios in which you might want to enhance the versioning logic, such as having open-ended plans, controlling the versions of plans for a particular calendar year, having the versioning for plans for a specific line of business, or adding versioning based on input requests from a sales automation system.

Design inputs[edit]

When you try to enhance the versioning logic, you need to keep the auditing needs of the organization in mind. The use of a centralized module for versioning means that the changes are applied to all entities. One of the most common inputs to the design for versioning is the process by which the plans change from year-to-year and the compliance requirements changes in reporting. You must also keep in mind the overall stage in which the updates occur and adjust the versioning configuration accordingly. To prevent updates from occurring to the plans in the Production stage without changing the version, you can update the configuration page by clicking Configure -> Product Composer System -> Configuration in Dev Studio.

Understanding the configuration options available for the versioning logic is extremely critical. With this knowledge, you can act as informed advisors to the business team throughout the life of the project. Additionally, you can also facilitate and deliver quick results if the business team wants to extend the versioning logic to properties beyond the effective dates without breaking any guardrails and keeping compliant with Pega's best practices.