Skip to end of metadata
Go to start of metadata



Go to start of metadata

Mike Davis - Project Lead

Weekly calls Wednesdays 1PM ET

Zoom Client Download 

https://zoom.us/j/6754075337

Meeting ID: 675 407 5337

Phone Number: +1 929-436-2866
Participant Passcode: 675 407 5337

ATTENDEES - PLEASE TYPE YOUR NAME IN THE CHAT OR  IF YOU ARE ON THE CONFLUENCE SITE, PLEASE SCROLL DOWN TO THE BOTTOM AND CHECK YOURSELF IN TO BE COUNTED FOR ATTENDANCE - THANK YOU!

Agenda Topics

Agenda Overview

Alex Mense

The ISO-22600 describes a policy ontology which means every specific model (like the DAM) should be an "instance" (I know in the OO world "instance" is not the correct term, but currently do not have a better one). Therefore the classes in the DAM are instances of the PMAC classes and therefore we can also add new attributes for functional purposes.

The PMAC policy model can be used twofold:

a) adminstration view: describing rulesets (set of policies) to be applied for specific entities, data, roles, attributes in a specific context ("only a GP in the role of a privileged healthcare professional is allowed to access ...", "... must refrain ...", ...). This ruleset is evaluated based on the current attributes in the contect when an action occurs.

b) actual policy view: decribes the policy actually applied when all the administrative policies, that apply to a specific context, are evaluated.

Composite policies are part of the management view, thus defining a set of related "basic policies" (ord subclasses) to which - for instance - a set of constraints can apply. In such a ruleset some policies may result in a "permit access", some in "deny" - the combining algorithm defined how to dealswith such situations. An example for the is XACML - found this useful: https://www.axiomatics.com/blog/understanding-xacml-combining-algorithms/

The use of "role" in the 22600 ontology does not mean that the ontology is only applicable to RBAC - you can also model ABAC without modification.


Bernd Blobel

Bernd, who is the author of the 22600 (as well as the overarching 23903 and the 21298) will provide insights on CompositePolicy.

ISO 22600-2:2014 6.4 Policy model

A security policy is the complex of legal, ethical, social, organizational, psychological, functional, and

technical rules for ensuring trustworthiness of health information systems.

A policy is the formulation of the concept of requirements and conditions for trustworthy creation, collection, storage, processing, disclosure, retention, transmission, and use of sensitive information.

A policy can be expressed

— verbally unstructured,

— structured using schemata or templates, or

— formally modelled.

For interoperability reasons, a policy shall be formulated and encoded in a way that enables its correct

interpretation and practice. Therefore, policies have to be constrained regarding syntax, semantics,

vocabulary, and operation of policy documents, also called policy statements or policy agreements

(agreements between the partners involved).

To reliably refer to a specific policy, the policy instance shall be uniquely named and identified via a

unique policy ID. The same is true for all the policy elements such as domain, targets, operations, and

their policies, which have to be named and uniquely identified too. In summary, a policy is characterized

by a policy identifier, a policy name, a policy authority, a domain identifier, a domain name, a target list,

target identifier, target name, target object, operations allowed, and related policies.

For readability reasons, domain-related attributes have been included in Table 2 even if policy inherits

from domain. The provided data type definition resembles the HL7 version 3 data type definition.[5]

Where allowed by the laws of the jurisdiction, health information systems such as the EHR should at

minimum have a policy for patients to control access to their health information, a policy with common

access rules by the organization, policies defined by laws and regulations, and one policy per structural

role as well as one policy per functional role.

Every creation, collection, access or modification, use, disclosure, retention, and destruction of an EHR

component shall be covered by one or more policies. The reference model of the EHR Extract includes a

policy ID attribute within the record component class to permit references to such policies to be made

at any level of granularity within the EHR hierarchy. The policies that apply specifically to an EHR can

be included within the EHR Extract, eventually including any bridged policies.

As any other component, also policy components can be composed or decomposed according to the

generic component model. Using HL7 version 3 data type definitions, the policy class can be specialized

into basic policy, meta policy, and composite policy (see Figure 4), which have been verbally explained

in detail in Table 3 and Table 4, respectively.[6]

Figure 4 — Policy base-class diagram

The specializations of the composite policy abstract class are interrelated in a complex way, which has

been indicated in outlines as simple association.

Table 3 — Basic policy types[6]

Table 4 — Composite policy types[6]

Another way for policy decomposition has been provided by the OMG’s security services specification

distinguishing between the following policies:

— invocation access policy implementing access control policy for objects;

— invocation audit policy controlling event type and criteria for audit;

— secure invocation policy specifying security policies associated with security associations and

message protection.

Regarding requirements for different object types,

— invocation delegation policy,

— application access policy,

— application audit policy, and

— non-repudiation policy

have been defined.

One common way to express constraints is the specification of user-defined schemata such as XML

schemata. This schema should be standardized for interoperability purposes mentioned above.

Figure 5 presents a simple XML instance for a security policy statement.

Figure 5 — Policy template example

Policies shall be managed and stored in standardized trustworthy policy repositories.







Model UpdatesMike and Ioana - Walk through of migrated DAM diagrams to EA and updates per earlier discussions.
Model Inputs

HL7 Privacy and Security Information Model

HL7 Version 3 Domain Analysis Model: Composite Security and Privacy, Release 1 "HL7 V3 DAM: Security, R1",,V3 DAM





Attendees

  •  
@Adam Wong adam.wong@hhs.govHHS
  •  
ONC
  •  
HL7 Austria
  •  
Amol Vyas amol.vyas@cambiahealth.comCambia Health
  •  
Kaiser
  •  
Bernd Blobelbernd.blobel@klinik.uni-regensburg.de
  •  
Wave One
  •  
Aegis
  •  
Celine Lefebvre Celine.Lefebvre@ama-assn.org AMA
  •  
Clara Y. Ren clara.y.ren.ctr@mail.milFederal Electronic Health Records Modernization (FEHRM) Office
  •  

Chris Shawn, Co-Chair

VA
  •  

Craig.Newman@altarum.org

  •  
Dave SilverElectrosoft
  •  
 Ready Computing
  •  
 @David Staggs drs@securityrs.comSRS 
  •  
Debra Simmons debrasimmons@
  •  
Dheeraj Pal
  •  
Diana Proud Madruga
  •  
Sequoia
  •  
Heather McComas heather.mccomas@ama-assn.org AMA 
  •  

  •  
EPIC
  •  
Jeff Helman
  •  
Jerry Goodnough
  •  
Jim KamperAltarum
  •  
Federal Electronic Health Records Modernization (FEHRM) Office
  •  
SRS
  •  

John Davis (Mike)

VA
  •  

John Moehrke Co-Chair

By-Light
  •  
Aegis
  •  
Julie Chan jchan@cwglobalconsult.comCWGlobal
  •  

Kathleen Connor  Co-Chair

VA (Book Zurman)
  •  
Ken Salyards
  •  
Laura Bright laurabright4@gmail.com
  •  
Laura Hoffman laura.hoffman@ama-assn.orgAMA
  •  
Lloyd McKenzie
  •  
Lorraine Constable
  •  
EMR Direct
  •  
Sequoia
  •  
Matthew Reid matt.reid@ama-assn.orgAMA

Milo
  •  
VA (Book Zurman)
  •  
Patient Centric Solutions
  •  
 PJM Consulting
  •  
Phillips
  •  
Trustworthy EHR 
  •  

@Ricky Sahu, @1up.health  

1up Health
  •  
Rhonna ClarkVA
  •  

Robert Dieterle rdieterle@enablecare.us

Enablecare
  •  
Russ Ott rott@deloitte.comDeloitte
  •  
Saul Kravitz saul@mitre.orgMITRE
  •  
Scott Fradkinsfradkin@flexion.us
  •  
Scott Robinson
  •  

Jopari

  •  
Stanley Nachimson
  •  
Stephen MacVicar smacvicar@mitre.orgMITRE
  •  
VA (Book Zurman)
  •  
 AMA
  •  

  •  
Tom Hicke
  •  
Flinders University
  •  
Vicki Giatzikis vig9034@nyp.orgNYP




  • No labels