OASIS PMRM TC: how to describe and display the PMRM Service invocations in a Use Case?

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

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 ·         3rd 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