7.1.4 Use Cases 5 and 6: Transfer/Receive Data from Third-Party Source
Topic Version | 1 | Published | 12/09/2016 | |
For Standard | PRODML v2.0 |
Use Case 5: Transmit monthly data to central data exchange
Use Case 6: Receive monthly data from a central data exchange
Standard |
North American Production Reporting Standard |
---|---|
Version |
0.1 |
Author |
Peter Westwood (EnergySys) |
Reviewer(s) |
Barry Barksdale (PDS Energy) / Shaji John (Haliburton) |
Goal |
Ensure that when data is exchanged the sender is able to specify the rules for access to the data, such that the receiver may enforce privacy rules specified by the data owner. |
Business Requirement |
Maintain privacy over sensitive data at all times, notably after onward transmission. Allow configuration of the rules for data access to be transferred between two systems. The responsibility for ensuring all data is clearly marked with access conditions lies with the data owner. |
Business Value |
Contractual conditions typically specify who can see sensitive production numbers at various locations. Unauthorized disclosure of this data to a third party is at best embarrassing and at worse litigious. |
Summary Description |
In several of the use cases two parties agree to exchange information. The Operating Partner typically collects and sends data to the Non-Operating Partner. In some cases the data may be distributed, possibly via a third-party hub. When this occurs, it is important that the data access rights are carried with the data, so that the rules for data security can be asserted by the receiving system. |
Use Case Scope |
TBS |
Primary or Typical Scenario |
Real Examples that this may apply to include: Well Production data should indicate which interested parties are permitted to access the numbers for a given well Where a party receives information concerning the production, apportioned by NRI (or other such split), only the personal net allocation and possibly the total, as defined by the contract, should be viewable by a receiving party. … It is expected that many cases of this type of data permissions need to be supported. |
Alternative Scenarios |
Data where the supplied permission entitles are not found. The receiving system does not support the enforcement of the required permissions. |
Post-conditions |
|
Business Rules |
If no permission are set then the assumption is that the data is accessible to anyone If the any of the identifiers within the permission blocks is set, then the receiver is expected to only allow the identified permissions entity. Entities that may be permissioned include… Permissioned roles will be… Permission classes include Read or Read/Write |
Data Requirements |
|
Notes |
The data transfer can be considered as having an Envelope and a Content Body. The Envelope of the data, when present, will define the required permissioned entities allowed to view the content. Systems could exchange the defined capabilities for enforcement of access permissions. This would allow the refusal to transfer data where the privacy cannot be enforced. It is required that the data permissions be configured such that the rules for any contract can be described and managed from the schema. An optional permissions entity could be added to any business data transferred. While it is outside the scope of the standard to say how this is used, it must be enough to allow the receiver the ability to apply access controls. |
Definitions |
Content Body – any business data being transferred. Permitted Entity – Group identify for whom the access is being defined. Identity Map – mapping between the entities used in one or more systems. |
Issues |
The Parties exchanging data will need a way to identify the Permitted Entities. This means that they will need to have shared identifiers for both the names of items. This will be difficult to manage but is required to allow the secure transfer of permissions between the two parties. |