Documentation and Testing Meeting 2010-08-04
Date: August 4, 2010
Attendees: Didi Davis, Keith Boone, John Moehrke, Nageshwara Bashyam, Noam Arzt, Parag More, David Tao, Arien Malec, Uvinie Hettiaratchy, Douglas Pratt, Will Ross, Karen Witting
||Fill out IHE work item template
||Create Doodle for prioritizing next set of documents
- Janet was unable to make it, so I will run the meeting today.
- I want to first review priorities and see the progress made.
- We have updates to the overview and the conformance guide and deferred policy question.
- Where are we with each of the priorities, and where do we still need to go.
- Have a number of deliverables not prioritized, good to assess why they are not.
- We have an idea for the Face to Face meeting - a Document-a-thon, along with a Plan-a-thon and Code-a-thon.
- This time will be used to collaborate and do some workshop mode work. Would like to discuss that first.
- Let's go over each of the priority 1 items.
- Let's start with Content Security for Simple Health Transport Specification.
- We don't have editors or owners for this document. I think Umesh is the owner since he wrote most of it. I have done a pass on the document. Useful to get additional reviewers/editors.
- Will formally look at it this week.
- Would welcome Karen's editing too.
- Linked to Documentation table.
- Second artifact is the API documentation. Been writing the documentation for key classes and methods.
- Useful for code review for Umesh.
- We've been looking at tooling for .NET.
- Looks like the only tooling that works well is Windows specific. Set of programs called SandCastle that generates API documentation.
- Would like to get a machine to host the API documentation. Would like to automate construction of HTML that will allow us to build automatically.
- Nothing done on the Java side.
- Dragon asked me to summarize what we did this past week.
- We mainly added user stories. We fleshed out the "why it would be good".
- Also did simplifying assumptions, thanks to John Moehrke.
- We captured the higher level stuff earlier.
- Last chapter was not touched.
- We did get a quick read from David Kibbe. He liked it and thought we should add more real world information as actual feedback from our pilots.
- The only thing lacking is a better explanation of NHIN Direct by NHIN Exchange - what are the differences, how do they align. That would be the only thing I would like to add.
- Would like to have more eyes at this point.
- Would welcome further comments.
- Do you think we should have an open round outside this group?
- Might want to add some external reviewers from ONC.
- On the Exchange that trips people up all the time - would be good to have a section on the difference between NHIN, Connect, Exchange and the Direct project.
- I'm willing to look at it over the next couple of days. I work with State HIE grantees who continue to be very confused at this. Would look at this document to settle some of that confusion.
- We have been working serially. It would be ideal for Noam to take it next.
- Next on the list is the deferred policy questions which I think got rolled into Overview itself and then NHIN Direct Security. Janet's not here right now, so Will and Dragon, do you want to do an overview of the NHIN Direct Security?
- Just posted a version of that, so if people could go in and take a look, that would be useful.
- It would be good to get some eyes on it.
- Looking for comments on the wiki. I'll paste my next version end of this week.
- Tossed around ideas with Keith Bone for conformance guide. It's a very light weight document.
- After the abstract and introduction, we explained structure of document and how it could be used.
- The conformance section is where we list all the criteria and requirements.
- Feedback now would be great on organization of the document and the flow. If additional sections, we can also work on it offline. The second, I would also encourage people to look at the content for SHOULDs and SHALLs.
- Maybe ask if anybody on the call has read it yet?
- I think it's overly influenced by security agent model. When we get to conformance document, we need to be more generic to all of the deployment models. This unfortunately means that we need to either agree with conformance plane and whether using a HISP or not.
- The current path will force everyone to use the security agent which is not our intention.
- Recommendation to be more explicit about different models.
- The over reliance on HISP deployment model is an issue.
- Would like to create abstract model and show that there are a couple of instances where this may apply.
- I agree with direction. Can you work with Keith and Parag to get an outline together?
- Will do. Conformance document breaks down to 3 different deployment models. Would like to focus my attention on that problem.
- Karen had some comments for the XDD/XDS specification. I agree with them. I would like to get status both on what's happening with IHE and where this specification is.
- I think David was working on write up for what those revisions might be. Need details on what kind of changes are needed.
- I think Karen's short list represents this well.
- Define a to/from at the SOAP level header.
- Two clarifications to XD* Metadata.
- One defining what are good dummy values...
- What we really need to do is to have it documented.
- Have not made progress on this yet. I agree with what you're both saying. We need to take Karen's discussion and various other wiki discussions.
- Is it really a change to XDR specification? I thought it would be more self contained so there's a documentation repackaging aspect?
- We're creating a proposal to IHE. We need to be clear about problem, why that's an important problem to solve and then includes recommendation that needs to be solved.
- Would like to be separated without access to PHI. One solution is to create a new profile but looks a whole lot like something else.
- IHE is not working on this problem. Problems are worked on within a context. Most likely it fits within a new work item. Good time to be submitted because it's open for next month. It's a long process though so won't get answer soon.
- First need to understand things you want to change.
- The first thing I listed we don't need IHE for.
- What I'm worried about is that we can put default things in. Either we know what content is or you don't know and you put something else. Perhaps need a table for metadata with different considerations
- I agree with all of that. If it were up to me and not up to Keith, I would just specify that you supply the metadata that you have. It's receiver's responsibility to assume all pieces are not there.
- Issue is that we want to test this and follow IHE process. Hard to do this simultaneous in the timeframe.
- Perhaps write an interim document.
- I agree.
- Due to conflict in IHE calendar and NHIN Direct timeline, this can be interim documentation.
- Change proposals happen faster.
- It's just a new work item.
- We have not agreed on what we want. No real agreement on metadata.
- Hearing two short term items: 1) Document use of SOAP headers to carry to and from information. 2) Short term item is to fill out IHE work item proposal and come up with solution in document form.
- Happy to take first crack at second item - take Karen's work and put some words around it and submit it back to this group.
- In terms of work proposal, that should come from someone not involved in IHE. I can review it and give suggestions.
- Yes, I can do that.
- One of the things I'm concerned about is that the receiver is able to know what they're getting - zero, minimal, or full metadata. The receiver may reject certain things. As long as receiver has this ability, I'm flexible about metadata.
- We have a number of items that currently don't have priorities.
- Lack of item in relevant row indicates that it's priority 3 or we haven't prioritized it.
Round on these items and level of priority. If you have comments on discussion to date, would welcome.
||Don't have the list in front of me. Would like to skip for now.|
||Would suggest to create a Doodle. Take first column which is title of document. Given description on this page, enter your ranking. Small description of ranking of what that means.|
||Might be a good idea to have a Doodle|
||Poll would be easier. We have the priority one correct.|
||Nothing to add.|
||Nothing to add.|
||Nothing to add|
||Nothing to add.|
- Would like to have a Document-a-thon during the Face to Face.
- Would like people to think about what the best use of the Face to Face time. Some things work really well with serial editing and some things work well with discussion.
- Please think about how best to use that time.
||I won't be able to be there. We are going to meet this afternoon to see whose going to be representing there. I'll make sure that's brought up in our dialogue.|
||There are some really good best practices that who GE uses. One is that everyone is given the assignment to read and mark up the pages. Then to bring up if anyone has any discussion items. When document is in review shape, then can do outlining and distribution of tasks. Would suggest that it's useful to take a few hours on the first day, give a homework assignment, then a few hours the next day. When pick up new work item, can do outlining in the same way.|
Arien Malec - I think S/MIME Spec and NHIN Direct Overview would likely be in shape.
||Will think about it.|
||Not going to be at Face to Face. Nothing to add.|
||If we are planning to do this, good to address topics that we talk a lot about such as IHE and XD* metadata.|
||Like John's idea. I would also like to talk about things that we haven't had the focus to do - priority 2 stuff. We could use together time not to polish documentation, but to jump start documents where interaction is important. Agreement on basic concept would be.|
||Agree with what's been said before. Rough outlines would be useful.|
||May not be available in afternoon|
||Nothing to add|
- Sounds like we want two sessions - one polishing documents and another for new documents. We will get a list of near final stuff and give people homework assignments that John suggested. People who are on vacation or remote can submit their suggestions.