Mike Davis - Project Lead
Weekly calls Wednesdays 1PM ET
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!
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, 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.
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.
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
Table 4 — Composite policy types
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
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 Updates||Mike and Ioana - Walk through of migrated DAM diagrams to EA and updates per earlier discussions.|
|@Adam Wong firstname.lastname@example.org||HHS|
|Amol Vyas email@example.com||Cambia Health|
|Celine Lefebvre Celine.Lefebvre@ama-assn.org||AMA|
|Clara Y. Ren firstname.lastname@example.org||Federal Electronic Health Records Modernization (FEHRM) Office|
Chris Shawn, Co-Chair
|@David Staggs email@example.com||SRS|
|Debra Simmons debrasimmons@|
|Diana Proud Madruga|
|Heather McComas firstname.lastname@example.org||AMA|
|Federal Electronic Health Records Modernization (FEHRM) Office|
John Davis (Mike)
John Moehrke Co-Chair
|Julie Chan email@example.com||CWGlobal|
Kathleen Connor Co-Chair
|VA (Book Zurman)|
|Laura Bright firstname.lastname@example.org|
|Laura Hoffman email@example.com||AMA|
|Matthew Reid firstname.lastname@example.org||AMA|
|VA (Book Zurman)|
|Patient Centric Solutions|
@Ricky Sahu, @1up.health
Robert Dieterle email@example.com
|Russ Ott firstname.lastname@example.org||Deloitte|
|Saul Kravitz email@example.com||MITRE|
|Stephen MacVicar firstname.lastname@example.org||MITRE|
|VA (Book Zurman)|
Terrence Cunningham 'Terry'
Patricia A.H. Williams aka Trish
|Vicki Giatzikis email@example.com||NYP|