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 | |||
| Reed Gelzer | Suzanne Gonzales-Webb CBCC Co-chair | 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 | ||||
| Duane DeCouteau | . | . |
Agenda
- (05 min) Roll Call, Approve Minutes & Accept Agenda
- (15 min) November_2013_Harmonization_Proposals Discuss initial November Harmonization
- (10min) NIB for SOA SLS
- (15 min) Ballot Reconciliation HCS - DS4P
- (10 min) Other Business LOINC Clinical Document Ontology security related comments; IHE CPP
Meeting Minutes
Meeting Minutes from October 15
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 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 define the needs of segmentation in abstract terms first, then show technology specific implementation (ala 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)
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 concernt 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 is end-to-end issues as inwho is the receipeint, receipient customization, that they understand the classification that they understand the security tagging--it is not sufficiently covered. concern is that ther eis a perception that for direct and XDR as well as XDS whi ch is not true. the fact that ONC and HIT committee wil 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 verything you need to validate an implementation. if you implement XDS you have to alidate the registry (you have to do this) the only added is how you would deal with 42CFS and hitech... if the metadata is unclear-there is apoblem 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 an dproivded to the security WG in regard to these implementation. it did realy on DS4P and IHE implementation and I don't think that XDS requirements should be in the DS4P IG ... I think it should ol point to them.
Ioana: john's point is that in DS4P--we can only implement published set documents. ther eis not sufficient detail to implement to pull scenario
Duane: I disagree. in th epush scenario, you know how to set the security tags for sensitivity for compartment, for pPOU beause you know who the receipeint is is and hwere they practice. in XDS, you do not yet know hwo will do the query and retrieve.
duane: this is where you're wrong: you're assuming that we want a static document from the <<48:00>>
Johnathan: it is John's concern, let us put that explanatory for those that do not know--then it will explain. then john's concern for 3rd party reviewers--then it will be expressed. Let's specifically say what is in scope/out of scope. its not intended to be a complete end-toend solution...if that's what they thenk then we need to address the concern
John: if ther eis a way to explain, for what is being provided vs what is not being provided then ... I guess
Ioana: there is not a one-size fits all for deployment for XDS repositories and registreries
Duane: I agree with that. our implementation at HIMSS was one approache to address the problem.
Ioana: this document does not solve a single end-toend problem. in all other respoects, you have to abide the underlying standards
John: what I'm asking for is to explan the known things that are specifically asked for by the regualtions we are dealing with, such as: there is a requirements that the ... we are not necessarily agreeing ... <<52: >> customized in the PUSH, the receipeint dodoes nto get customeized data ... we have to modify the XDS in order to customize the meta data.
Ioana: the idea of customizing metadata, the decision of what the meta data should say is from the document source. to according to th eprivacy policy and consent, if the consent says the POU is for treatment, it is not set for the reciepient, but for the sender. you may provide a document for payument 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 requeiments
we will add clairification 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 implenetionsolution for XDS, XDA but relies on the correct ... or other policies needed to establish an appropoirate trust framework--we make assumption that the trust framework remains the same
seconed: Diana Objections: Abstnentions: 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 completition.
Meeting adjourned: 3:09 PST
