This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "June 25, 2013 Security WG Conference Call"

From HL7Wiki
Jump to navigation Jump to search
Line 35: Line 35:
  
 
''' Item 1'''  
 
''' Item 1'''  
 +
''e-mail from Tony Weida''
 +
* Discussion
 +
** Comment 55 (related to Comment 13) re conformance
 +
*** Comment 58 re naming of ontology classes in relation to corresponding HL7 vocabulary concepts
 +
* Announcements
 +
** Intention to call for votes during the next call
 +
*** Block vote on the draft resolutions of the negative minors (after any discussion requested by WG members). 
 +
*** Block vote on the draft resolutions of the affirmatives (after any discussion requested by WG members).
 +
** (Assuming progress on Comments 55 and 58) Intention to discuss Comment 60 (related to Comment 18) re the operation hierarchy
  
  
Line 41: Line 50:
  
 
'''Item3'''  
 
'''Item3'''  
 +
 +
'''e-mail received from Bernd''' - regarding reconciliation ''[tabled to future meeting where Bernd is able to attend]''
 +
Being on Tuesday on a trip to Estonia to give the Keynote as well as several scientific presentation to the pHealth 2013 Conference, I regret for not being able to make the call.
 +
The comments I've been providing are truly serious ones. In the following, I'm trying to give some more explanations for my position, which I would have given when having been able to physically participate in the reconciliation discussion.
 +
 +
 +
Here a short explanation (criticism of the offered reconciliation) to Comment 1:
 +
If we try to describe real world domains, thereby enabling communication and cooperation with non-ICT domain experts (real world domain experts such as physicians, nurses, lawyers, usual patients, etc.), we have to use real world ontologies. If we are living in an ICT space and communicating with ICT experts, we will use ICT ontologies. In both cases, we should never try starting from scratch, but should reuse existing related ontologies such as SNOMED CT, BFO-based OBO approaches in the first case, or SOA ontology in the latter one.
 +
This is a crucial decision, which must be discussed and declared in 1.2 and 1.4.
 +
By the way, the privacy and Security DAM has been designed as real world domain related. So we established communication paths to administrators, lawyers, etc. For this purpose, we have also intentionally avoided to refer to the HL7 RIM, which is a special ICT ontology for a very dedicated (some see it also a limited) set of use cases.
 +
 +
 +
Having this said, I'm not happy with the disposition of comments offered to my first note.
 +
 +
 +
Explanation (criticism of the offered reconciliation) to Comment 3:
 +
The basic intention of this comment is the introduction of an hierarchy of classes and derived Instances. A Business System Architecture drives the Information Architecture, which itself prescribes the Information System Architecture, which identifies the Data Architecture, which is implemented in a Delivery System Architecture (NIST Enterprise Architecture Model). The HL7 Security and Privacy DAM represents a specialization of a Business System Architecture, thereby building the top level of the aforementioned hierarchy from a security and privacy perspective. The examples mentioned in the Background Chapter 3 refer to the lower levels, which should be clearly mentioned and extended by first shortly introducing the S&PDAM in Chapter 3.
 +
 +
 +
Regarding the concept representations using different ontology levels, General Ontologies provide the meta-meta model for concepts representing real world objects. Top Level Ontologies provide the bridging level meta-model for cross-domain concept representations. Domain Ontologies specialize those principles for certain business domains where security and privacy are simply two special ones. The aforementioned set of principles is implemented using Application Ontologies. Here, RBAC, etc., come in.
 +
 +
 +
Finally, there is another hierarchy defining the way things should be described in our document: Community, Process and Behavior determine the requirements on a business system and are constrained by policies for meeting those requirements. Using Rules, Policies specified in contracts constrain Roles. The Rules are specialized according to the Policy Ontology (ISO 22600), which is also the basis for the HL7 S&PDAM. This system of concepts corresponds to the UML 2.1 Policy Concepts.
 +
 +
 +
Explanation (criticism of the offered reconciliation) to Comment 4:
 +
Comment 4 tackles the same hierarchies addressed in Comment 3. A corresponding clarification should provided in an analogous and consistent way.
 +
 +
 +
Explanation (criticism of the offered reconciliation) to Comment 5 and Comment 6:
 +
The additional definition should be introduced.
 +
 +
 +
Explanation (criticism of the offered reconciliation) to Comment 7:
 +
This comment addressed a basic principle for ontology developments: Reusing existing ontologies as much as possible, or at least providing relationship statement for transformation.
 +
 +
 +
Explanation (criticism of the offered reconciliation) to Comment 8:
 +
See the points addressed in Comment 1, Comment 3 and Comment 4.
 +
 +
 +
Again, I'm not against the current document, but I'd like to have some clarifications by extensions or reformulations. Otherwise, we might come into conflict with future work or in the context of true interoperability.
 +
 +
For a better understanding, I attach two short presentations I gave last year in Helsinki in the context of an international project on the matter discussed, not saying that those presentation exactly fit all the aspects. There is also an extended lecture series on system modeling and architecture as a better but currently too extended offer, which would help a lot in better understanding the issues. However, this PPT needs very detailed explanations and would not fit the needs at the moment. I'd be ready to give a special "tutorial" based on that extended lecture to selected experts during the next Working Group Meeting in Cambridge.
 +
 +
Very best regards, Bernd
 +
 +
  
  

Revision as of 17:42, 25 June 2013

Security Working Group Meeting

Back to Security Main Page

Attendees

Back to Security Main Page

Agenda

  1. (05 min) Roll Call, Approve Minutes & Accept Agenda
  2. (15 min) Harmonization Proposal Review (technical corrections) - Kathleen Connor
  3. (15 min) Item2
  4. (15 min) Item3
  5. (05 min) Other Business

Meeting Minutes

Roll Call, Approve Minutes & Accept Agenda


Item 1 e-mail from Tony Weida

  • Discussion
    • Comment 55 (related to Comment 13) re conformance
      • Comment 58 re naming of ontology classes in relation to corresponding HL7 vocabulary concepts
  • Announcements
    • Intention to call for votes during the next call
      • Block vote on the draft resolutions of the negative minors (after any discussion requested by WG members).
      • Block vote on the draft resolutions of the affirmatives (after any discussion requested by WG members).
    • (Assuming progress on Comments 55 and 58) Intention to discuss Comment 60 (related to Comment 18) re the operation hierarchy


Item 2


Item3

e-mail received from Bernd - regarding reconciliation [tabled to future meeting where Bernd is able to attend] Being on Tuesday on a trip to Estonia to give the Keynote as well as several scientific presentation to the pHealth 2013 Conference, I regret for not being able to make the call. The comments I've been providing are truly serious ones. In the following, I'm trying to give some more explanations for my position, which I would have given when having been able to physically participate in the reconciliation discussion.


Here a short explanation (criticism of the offered reconciliation) to Comment 1: If we try to describe real world domains, thereby enabling communication and cooperation with non-ICT domain experts (real world domain experts such as physicians, nurses, lawyers, usual patients, etc.), we have to use real world ontologies. If we are living in an ICT space and communicating with ICT experts, we will use ICT ontologies. In both cases, we should never try starting from scratch, but should reuse existing related ontologies such as SNOMED CT, BFO-based OBO approaches in the first case, or SOA ontology in the latter one. This is a crucial decision, which must be discussed and declared in 1.2 and 1.4. By the way, the privacy and Security DAM has been designed as real world domain related. So we established communication paths to administrators, lawyers, etc. For this purpose, we have also intentionally avoided to refer to the HL7 RIM, which is a special ICT ontology for a very dedicated (some see it also a limited) set of use cases.


Having this said, I'm not happy with the disposition of comments offered to my first note.


Explanation (criticism of the offered reconciliation) to Comment 3: The basic intention of this comment is the introduction of an hierarchy of classes and derived Instances. A Business System Architecture drives the Information Architecture, which itself prescribes the Information System Architecture, which identifies the Data Architecture, which is implemented in a Delivery System Architecture (NIST Enterprise Architecture Model). The HL7 Security and Privacy DAM represents a specialization of a Business System Architecture, thereby building the top level of the aforementioned hierarchy from a security and privacy perspective. The examples mentioned in the Background Chapter 3 refer to the lower levels, which should be clearly mentioned and extended by first shortly introducing the S&PDAM in Chapter 3.


Regarding the concept representations using different ontology levels, General Ontologies provide the meta-meta model for concepts representing real world objects. Top Level Ontologies provide the bridging level meta-model for cross-domain concept representations. Domain Ontologies specialize those principles for certain business domains where security and privacy are simply two special ones. The aforementioned set of principles is implemented using Application Ontologies. Here, RBAC, etc., come in.


Finally, there is another hierarchy defining the way things should be described in our document: Community, Process and Behavior determine the requirements on a business system and are constrained by policies for meeting those requirements. Using Rules, Policies specified in contracts constrain Roles. The Rules are specialized according to the Policy Ontology (ISO 22600), which is also the basis for the HL7 S&PDAM. This system of concepts corresponds to the UML 2.1 Policy Concepts.


Explanation (criticism of the offered reconciliation) to Comment 4: Comment 4 tackles the same hierarchies addressed in Comment 3. A corresponding clarification should provided in an analogous and consistent way.


Explanation (criticism of the offered reconciliation) to Comment 5 and Comment 6: The additional definition should be introduced.


Explanation (criticism of the offered reconciliation) to Comment 7: This comment addressed a basic principle for ontology developments: Reusing existing ontologies as much as possible, or at least providing relationship statement for transformation.


Explanation (criticism of the offered reconciliation) to Comment 8: See the points addressed in Comment 1, Comment 3 and Comment 4.


Again, I'm not against the current document, but I'd like to have some clarifications by extensions or reformulations. Otherwise, we might come into conflict with future work or in the context of true interoperability.

For a better understanding, I attach two short presentations I gave last year in Helsinki in the context of an international project on the matter discussed, not saying that those presentation exactly fit all the aspects. There is also an extended lecture series on system modeling and architecture as a better but currently too extended offer, which would help a lot in better understanding the issues. However, this PPT needs very detailed explanations and would not fit the needs at the moment. I'd be ready to give a special "tutorial" based on that extended lecture to selected experts during the next Working Group Meeting in Cambridge.

Very best regards, Bernd



Other Business

Action Items

Back to Security Main Page