pmrm — archive

[Michael Willett]

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)S ystems 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