October 29, 2013 Security WG Conference Call
Attendees
| Member Name | Present | Member Name | Present | Member Name | Present | ||
|---|---|---|---|---|---|---|---|
| Mike Davis Security Co-chair | x | John Moehrke Security Co-chair | x | Trish Williams Security Co-chair | . | ||
| Bernd Blobel, Security Co-chair | . | . | |||||
| Johnathan Coleman | x | Kathleen Connor | x | Duane DeCouteau | x | ||
| Reed Gelzer | Suzanne Gonzales-Webb CBCC Co-chair | x | Brian Handspicker | x | |||
| Muhammed Jafari | x | Don Jorgenson | Diana Proud-Madruga | x | |||
| Harry Rhodes | Ioana Singureanu | x | David Staggs | ||||
| Richard Thoreson CBCC Co-chair | Tony Weida | x | Scott Weinstein | ||||
| . | . |
Agenda
- (05 min) Roll Call, Approve Minutes & Accept Agenda
- (15 min) November_2013_Harmonization_Proposals Discuss initial November Harmonization
- (10min) NIB for SOA SLS
- and Privacy Ontology - Nov 2013.pptx Security and Privacy Ontology ppt - Tony Weida
- (15 min) Ballot Reconciliation HCS - DS4P
- (10 min) Other Business LOINC Clinical Document Ontology security related comments; IHE CPP
Meeting Minutes - DRAFT
Meeting Minutes from October 15 - Approved
November_2013_Harmonization_Proposals Discuss initial November Harmonization - Kathleen Initial proposal accepted except for concern with definition for confidentiality
NIB for SOA SLS we will be submitted the NIB for SOA SLS (due on Sunday, October 29 2013)
NIB for recirculation ballot for DS4P (unknown)
- Ioana will confirm with Don Lloyd to confirm if needed
- Ioana will submit if needed prior to Sunday, October 29, 2013)
Ballot Reconciliation DS4P Updated ballot reconciliation sheets in preparation for a last vote: http://gforge.hl7.org/gf/project/security/frs/?action=FrsReleaseBrowse&frs_package_id=229
HL7_IG_DS4P_R1_N1_2013SEP_amalgamated.xls
Remaining comments / John Moehrke (additional text also from e-mail string
- comment 40 – (Ioana) I'm not sure what additional editing you were thinking of on item#40 but I added a note in the disposition comment and I can use your input about further addressing this Affirmative-Suggestion but does not require retaking a vote.
- (John) I thought that we had agreed to do a summary of the requirements that the transport needs to support in an abstract way. This summary is at the top of both transports so that the reader understands. If so, then this is all that #40 is asking for.
- comment 40 – (John) I thought that you were going to do something like this? That is defining the needs of segmentation in abstract terms first, and then shows technology specific implementation (aka SAIF).
- comment 9 – (John) Note I wanted “Content Profile” changed to “Transport Profile”. Your disposition as you also dropping the word “Exchange”. I think that the word exchange is still appropriate to the XDR transport as distinct from the direct transport. So don’t remove the ‘Exchange’
- (John) my comment was on using the term ‘content profile’ to describe the ‘transport profiles’. Yet your disposition is “Not persuasive” with the rational describing something to do with XDS metadata. I think you have marked the wrong item with the wrong disposition and rational.
- comment 8 – (John) I thought that you were going to include the ‘introduction’ in all three text? This is my suggestion in #8, yet you indicate ‘not persuasive’. (Note you did accept #27, and agreed to #33)
- comment 12 & #28 – (John) Please review again. IHE ITI has released the updated Volume 3, and the title of the section has been changed as I indicated. This is now the ONLY version of Volume 3 that is published, and thus the DS4P text should be referring to the proper IHE normative text. This change is simple and non-controversial. Please reconsider.
- comment 19 – (John) I believe you still need to do some editing. I understand your “Disposition Comment”, but the text I read did say that DS4P was “extending” the metadata for author telecom. I have no problem with it emphasizing the use. Just don’t call it ‘extending’. This minor change is all I asked for.
– (John) I agree with the disposition of all my other comments (inclusive of negatives)
(Ioana)
- John, I added explicit references to the transactions that are using the XDS Metadata and would be subject to the constraints specified in the Exchange profile (item#7/row10 of the ballot spreadsheet). Please review the text below and let me know if this explicit as to the intended use of the privacy annotations and constraints proposed for the XDS Metadata as specified in the DS4P Exchange Profile:
- Item #7/ Row 10: XDR is not the only Exchange-related transport is scope. The DS4P requires other integration profiles. Furthermore this is a US-realm IG. ** The proposed rewording is "Exchange Transport Profile" and the intro will clarify the "profiling refers to constraints applied to the XDS Metadata used by any Exchange transaction based on IHE XDS, IHE XDR, etc."
- The XDS metadata constraints applies to ITI-18 (Registry Stored Query), ITI-42 (Register Document Set - b), ITI-41 (Provide and Register Document Set - b), and ITI-43 (Retrieve Document Set). These transactions support the "push" and "pull" document exchange modes required by the DS4P use cases.
- Push (IHE IT XDR) : ITI-41 (Provide and Register Document Set - b) - Pull (IHE IT XDS, XCA): ITI-18 (Registry Stored Query), ITI-42 (Register Document Set - b), ITI-43 (Retrieve Document Set)
We will add that this document does not describe a specific end-to-end solution but relies on the correct implementation of the underlying IHE IT infrastructure transactions and document exchange metadata in addition to other policy needed to establish a trust framework.
John disagrees that the DS4P document published has end-to-end ... asynchronous transport, where time elapse, policy will change <<34:00>> Response: this is not in scope / not a deployment issue. This is applying constraints data--that is up to the customer; this is how implementers who want to implement correctly, ....
John expressed concern is that for direct and XDR, we have provided in the form of an IG, on how do the DS4P (end-to-end) by including the XDS infrastructure we have not provided sufficient end-to-end structure for DS4P. There are end-to-end issues as in who is the recipient, recipient customization, that they understand the classification that they understand the security tagging--it is not sufficiently covered. Concern is that there is a perception that for direct and XDR as well as XDS which is not true. The fact that ONC and HIT committee will perceived what we produce that they will proceed assuming that we have completed the work sufficiently.
Ioana responded: we are not saying that this is the very thing you need to validate an implementation. If you implement XDS you have to validate the registry (you have to do this) the only added is how you would deal with 42CFS and hi-tech... If the metadata is unclear-there is problem in the specification. I do not understand what the xx is
Duane responded: did anyone watch the video from the HIMSS demonstration. I don't expect the IG to boil the ocean for me. There are certain things that we did and document and provided to the security WG in regard to this implementation. It did rely on DS4P and IHE implementation and I don't think that XDS requirements should be in the DS4P IG. I think it should just point to them. As an implementer I just need to know where to look
Ioana: john's point is that in DS4P--we can only implement published subscribed set documents. There is not sufficient detail to implement a PULL scenario
Duane: I disagree. In the PUSH scenario, you know how to set the security tags for sensitivity, for compartment, for POU because you know who the recipient is and where they practice. In XDS, you do not yet know who will ultimately do the query and retrieve. This is an assumption you are making. you're assuming that we want a static document from the XDS repository—in our implementation, it was annotated in the real time based on the individual requesting it, its POU, organization policy and whatever sensitivity permissions they had. I uphold that other organizations that do this type, can also do this. This was not a document pre-staged for my need. John: That is my point—this has not been said.
Ioana: that is specific to document management.
Johnathan: it is John's concern, that other people may have a misunderstanding what this standard is delivering. let us put that explanatory for those that do not know--then it will explain. Then John's concern for 3rd party reviewers not understanding the document--then it will be addressed. Let's specifically say what is in scope/out of scope. It’s not intended to be a complete end-to-end solution...if that's what they think then we need to address the concern
John: if there is a way to explain, for what is being provided vs. other issues on what is not being provided then ... I guess
Ioana: there is not a one-size fits all for deployment for XDS repositories and registries
Duane: I agree with that. Our implementation at HIMSS was one approach to address the problem.
Ioana: this document does not solve a single end-to-end problem. in all other respects, you have to abide the underlying standards
John: what I'm asking for is to explain the known things that are specifically asked for by the regulations we are dealing with, such as: there is a requirements that the ... we are not necessarily agreeing ... <<52: >> Customized in the PUSH, the recipient does not get customized data ... we have to modify the XDS in order to customize the metadata.
Ioana: the idea of customizing metadata, the decision of what the metadata should say is from the document source. to according to the privacy policy and consent, if the consent says the POU is for treatment, it is not set for the recipient, but for the sender. you may provide a document for payment for another organization--it is sent by the source. It is not for the receiver to send... if the receiver says... conveys what the send has to do (not the receiver) >> 54:>> you are assuming the sender is publishing something for all time, In addition to
John: you are including deployment requirements
We will add clarification of how XDS, XDR are deployed
MOTION MADE: (Ioana) to accept remainder items as discussed
Discussion: None, John will not withdraw negative on #7. Affirmative on all others
Adjust motion: proposed amendments: take vote persuasive with mod on #7 with additional clarification
Modified Motion: we will add that this document does not address an end-to-end implementation solution for XDS, XDA but relies on the correct ... or other policies needed to establish an appropriate trust framework--we make assumption that the trust framework remains the same
Second: Diana Objections: Abstentions: John (1) Still on call: john, Ioana, Kathleen, Diana, tony, Johnathan, Duane, Brian motion passed
Motion made for remainder outstanding: Discussion? None Second: John M Objections: none, / abstentions: none / motion passes
Appreciation made for discussion for making items clear, and patience for making this to completion.
Meeting adjourned: 3:09 PST
