Dear PMRMers – The work to date from the Face/Face and follow-up telecons on the Emergency Responder Use Case have brought us to this point: - focus on each individual Actor in the life cycle flow of PI - detail the IN and OUT flows of PI to/from that Actor - identify the privacy requirements affecting each IN/OUT flow per Actor (difficult! often implied) - map those requirements to particular PMRM Services (high level) The next step needed is: (F) - identify (describe and display) the specific Function invocations under each Service Beyond that step (according to the revised Methodology), the final steps involve identifying the Mechanisms (and Controls) needed, the privacy architecture, and the system design. Consider Table 3.1 below, from the Emergency Responder Use Case, which identifies the PI flows from all Sources INTO the Actor = Emergency Communications System (ECS): Table 3.1. Data Flows TO a Single Actor with PMRM Service Invocations. ACTOR: ECS PI-In [detailed PI required] Actor Source Requirements [Examples – Qualify with Context] SVCs [Context Narrative] Comment Incident Report External sources · ECS Privacy and Security Policy · jurisdictional regulations · OnStar · Security · Control · Audit · Interaction · Validation · Usage Incident involving Californians with all health info within the City of Sacramento Data elements require definition Situational Awareness Report External Sources · ECS Privacy and Security Policy · jurisdictional regulations · OnStar · Security · Control · Audit · Interaction · Validation · Usage Patient EHR Information Service Provider and other Healthcare systems · HIPAA security and privacy rules · HITECH · 3 rd party inherited policy agreements · Security · Control · Audit · Interaction · Validation · Certification · Usage If Individual access or enforcement are necessary to the ECS, then Access and enforcement services required Situation Assessment On-site Care/Incident Commander · General scene information · None There are four PI instances identified, from various Actors. See the first two columns. In each instance, we had to largely extrapolate the appropriate privacy requirements, since such requirements, especially contextual or jurisdictional requirements, were not explicitly identified in the original expression of the Use Case. Identifying the privacy requirements is an essential step in our Methodology. Now: how to describe and display the PMRM Service invocations, in detail? Consider one ‘row’ in the table: ECS Incident Report External sources · ECS Privacy and Security Policy · jurisdictional regulations · OnStar · Security · Control · Audit · Interaction · Validation · Usage The Incident Report, presumably including PI of the ‘victim’, flows from External Sources TO the ECS. The invoked Services are shown (our first pass at identifying the particular Services). Let me make the point again: In a robust scenario, it is possible that ALL PMRM Services are invoked. But, the PARTICULAR way (Functions) that each Service is invoked depends on the context, parameters, requirements, etc. My analogy was: All computer programming constructs can appear in a computer program, but the particular program is made specific by the operational parameters and the invocation sequence of the programming constructs. All the world’s many English novels are made up of only 26 letters of the alphabet (and punctuation). The 10 PMRM Services can write the world of privacy management! (Jumping off soap box….). Consider a tabular, time-line flow of Service invocations: External Source connects to the ECS SECURITY: establish confidential communication (encryption), check External Source credentials (CERTIFICATION?) INTERACTION: Provide privacy notice to the External Source, if appropriate Incident Report is transmitted to the ECS VALIDATION: check the PI for reasonableness, veracity, and relevance, possibly against other sources CONTROL and USAGE: Store the PI, together with all appropriate permissions for subsequent PI use AUDIT: record the receipt of the PI and Incident Report We could debate whether certain functions (actions) are invoked; that is WHY we develop Use Cases! To get into the details of what must be done operationally. The Services give us a vocabulary for that discussion. I have used informal language to describe the specific functions invoked under each Service. However, recall that the original PMRM has 7 formal Function categories and provides a formal, programmatic language for Function expression. These formal expressions can be substituted into the columns above. In fact, use of some sort of graphical “modeling” system is suggested (I have NO expertise here!). The high-level Use Case expression (as in multiple ACTOR/IN/OUT tables, like Table 3.1 above) cam be the first level of presentation. Then, each entry (eg, the Services list) can be ‘exploded’ into tables like above. Then, the high-level Service invocation descriptions in that table can be further exploded into formal Function calls. And, so on across the Use Case. The use of a graphical tool would allow the separate IN/OUT flows for each Actor to be graphically synthesized into a full life-cycle flow of PI. Let me stop here. Your comments are most welcome! And, this topic will be covered at the informal PMRM TC telecon this Thursday, 28 July. Watch for a telecom reminder, with Agenda. Michael