PMRM v09 comments... re: controls/FIPPs/Services

["Michael Willett" <mwillett@nc.rr.com>]

As noted in the PMRM TC telecom, I am drafting wording

that makes more explicit in the V09 draft the resolution steps going from

 

     privacy controls to FIPPs to PMRM Services

 

These are key steps in going from the initial use case analysis

to an operational system design; eventually, to a privacy management implementation.

 

>>>   BACKGROUND  <<<

 

The excellent flow chart shows these steps:

 

   - High level/detailed/PI analysis

 

         o PI exchanged between (sub)SYSTEMS within DOMAINS

 

   - Operational Privacy CONTROLS

 

         o CONTROLS =  measures to avoid, counteract, or minimize risk

 

   - SERVICES needed re: Controls

 

   - Technical/Process MECHANISMS

 

  - Risk Assessment (of selected Services)

 

   - Iterative Process

 

   - operational FIPPs (fair information principles/practices)

 

     …  “operational definitions” are intended to be used in the PMRM to support development of the Detailed Privacy Use Case Analysis” described in Section 4.  Their use is completely optional, but may be helpful in organizing privacy requirements and controls where there are inconsistencies in definitions across policy boundaries or where existing definitions do not adequately express the operational characteristics associated with Fair Information Practices/Principles.

 

Current v09 draft sections matching the flow chart:

 

Section 4.3: CONTROLS

               

Section 4.4: Service DEFINITIONS

 

Section 4.5: Functions/business processes re: Services

 

Section 4.6: Risk Assessment…. of the Services within the use case.

 

Section 4.7: Iteration

 

Section 5: FIPPs

 

>>> MY SUGGESTIONS  <<<

 

   A - The resolution/reduction sequence is:    privacy controls to FIPPs to PMRM Services (to Functions/mechanisms to Risk Assessment to Iterate for detailed refinement)

 

   B  - add the definition of CONTROLS (=measures to avoid, counteract, or minimize risk) to section 4.3

 

   C – move the discussion of FIPPs (section 5) into Section 4.3; move the actual ‘sample’ FIPPs definitions to an Appendix.

           To the verbiage in the (moved) section 5, add:

 

            - Select appropriate FIPPs that satisfy and map to the identified Control requirements   

 

   D – End Section 4.4 with:     

 

For each data flow exchange of PI  – incoming, internally generated, outgoing - between (sub)Systems within privacy Domains,

identify the Services that conform to and satisfy the identified

privacy controls and FIPPs required for that data flow.

 

This detailed conversion into Service operations can then be synthesized into consolidated sets of

Service actions per System involved in the Use Case.

 

   E – add to Section 4.5:

 

           The Services defined in Section 4 encompass detailed Functions and Mechanisms needed to transform

           the privacy controls and FIPPs of section 4.3 into an operational system design for the Use Case.

 

   F – add to section 4.7:

 

             The steps in developing the use case that are described above can be iterated, with

             further granularity and detail added at each iteration. The Functions and business processes

             identified at a high level in Section 4.5 can be refined and further converted to explicit

             Mechanisms and business processes. In this way, the use case can evolve from the requirements stage involving Controls and FIPPs, to

             the Service-based solution, to a detailed system design involving Functions and mechanisms, eventually

             to a comprehensive privacy management implementation. Each stage in this iterative refinement

             will provide further insight into the privacy implications of the use case.

 

   G – For the use case illustration:

 

            - we decided to spread the use case development across the sections  

 

            - So, the ‘spread’ would introduce consecutive parts in the list, per sections of the doc:

 

                 o high level

                 o detailed

                 o PI

                          - These first three parts are as shown in V09

                 o Controls/FIPPs

                 o Services

                          - These parts (above) are on a per I/O flow per System (per Domain)

                          - remember our development of the Emergency Responder use case  

                 o some partial inclusion of Functions/mechanisms

                 o risk assessment discussion (brief)

                 o short “essay” on iteration and refinement  

 

                  For illustration and simplicity, use TABLES in the evolving use case.

                  But, in practice and for substantial use cases, modeling tools are

                  appropriate that support automation (linkages) and facilitate refinement.

 

   H – The flow chart can be lightly modified to match above    

        

Of course, this drafty verbiage can be polished a lot. I am simply

trying to illustrate the point.           

 

 

 

Michael