Documentation and Testing Meeting 2010-07-28

Notes from Documentation and Testing Workgroup
Date: July 28, 2010
Time: 2pm-3pm
Attendees: Janet Campbell, John Moehrke, Keith Boone, Nageshwara Bashyam, Parag More, Arien Malec, Uvinie Hettiaratchy, David Tao, Douglas Pratt, Amram Ewoo, Andy Oram, Karen Witting, Will Ross
Actions for this Week:

ID	Date	Action	Status	Owner	Due Date
8	7/28/10	Review NHIN Direct Overview Document and conformance guide	Open	WG	7/04/10

Actions from last Week:

ID	Date	Action	Status	Owner	Due Date
6	7/21/10	Update wiki with contact information and progress section for each of the documents	Open	Janet Campbell	7/22/10
7	7/21/10	Review NHIN Direct Overview Document	Open	WG	7/28/10

Agenda:
· NHIN Direct Overview Document Review
Notes:
Dragon Bashyam
· Uploaded overview document to wiki.
· Would like to see if right content is available and if right level of detail.
· Thanks to the NHIN Overview team
· Would like to start with table of contents. Is there anything that sticks out to people?
· NHIN Direct Overview is being written to satisfy a variety of different participants.
· Approach we took initially was to have a section up front. Doesn’t get into a lot of details.
· The first section that goes all the way to Section 1-6 is what is NHIN Direct, how it started, who uses it and the implementers.
· Section 9 goes through the technical architecture. The idea here is to fit every aspect of the NHIN Direct specification we have developed at a high level. It’s not to specify every shell and requirement, but proof of concept.
· After that, we have references to standard.

Round the Room

Janet Campbell	This looks a little too ambitious. Perhaps answering questions that we don’t need to be answered. Most important thing is: what is NHIN Direct, what are the typical use cases, who will use it, and possibly implementers of NHIN Direct. Not sure how easy to keep that updated. Relationship with NHIN Exchange is also important. Once we get into technical document, that might be a different level – perhaps reference out to specs and wiki pages. I think the definition of message container might be too micro level for this kind of document. Generally, I think what we have is good.
Keith Boone	I found the document to be a very easy read. I think it’s very useful. As an overview, it might be a little too ambitious for the part of the overall documentation. I love the content. This really does speak simply and easily to people. It explains what we’re doing very well. It’s almost a marketing document which most SDOs and profiling organizations don’t do very well. Even though might be too ambitious, I would continue with content.
Parag More	I think it’s a great document and has a lot of good content. Let’s keep developing the content and if overlap, we can move to another document. One additional thing if possible some sort of real world initiation. Real world examples of abstract model would be helpful.
David Tao	Great comments so far. I’m close to it, but even amongst us editors, we thought too much information especially towards the end. We didn’t spend as much time on the end, assembling stuff from wiki. Looking for direction to see if Chapter 9 should be fleshed out and refined or focus more on the beginning. One thing we have wrestled with is references to wiki versus putting it in the document. Once out there, it’s not as dynamic as wiki. But if someone comes to wiki, how do they know what’s the latest? Was hoping document would be relatively stable content. Not so much details of code. Any suggestions on what should be on wiki and what should be on document would be helpful.
Doug Pratt	I agree with prior comment. I wasn’t put out by chapter 9 as it helps me understand this a little more.
Andy Oram	Just looked at the document. First of all, really liked it and the flow of it. I thought focus is not on things that people expect – for example, privacy is a huge issue and expect to see more about that. Perhaps we can solve problem for technical material by describing the WHY rather than the HOW. Don’t want a frightening architecture diagram which might drive away the reader. Describe how NHIN solves that in a high level way. Willing to go over document and have other comments
Dragon Bashyam	Please put suggestions on wiki.
Karen Witting	I didn’t read all of it, but think it’s an excellent first start. I agree with a lot of what Janet said, especially in introduction. What it is, who will use it, and relationship of NHIN Direct and Exchange. Not sure it’s important to talk about how it got started and how it’s organized because things are fluid in that regard. About 9, in some ways, the wiki is kind of overwhelming. I agree that it shouldn’t be too detailed. The idea of putting an example is always good.
Arien Malec	The WHY is the key information to have. Agree with most comments. Great work and this is some great content. Useful to flesh out the WHAT information as a guide to important bits to wiki. I think it’s useful to have a document that states the important bits
Will Ross	As a coauthor, I am a little close to forest. Worried a lot of about putting too much information. At early stage it’s good to have stuff to work with. I appreciate everything that everyone said. I think it’s good for focus. I like the idea of branching off from the abstract model and doing a couple of how it works without going down into technical details. I think technical content is very useful. I also like Arien’s idea of the WHY. It’s easy for us inside the project to get distracted about what the NHIN Direct achieves. One of the late editions we figured out we needed was something that situated NHIN Direct appropriately amongst top bodies.
John Moehrke	Emphasize much of what was already said. This could go way too deep, but earlier chapters clearly indicate that the editors do realize that they need to abstract and go up a level. When using acronyms, probably too deep. We do have simplifying assumptions that the sender is going to out of hand deal with any privacy descriptions and authorizations to deal with checking that they have the correct address and that they know what’ s coming. This discussion should come early. It shouldn’t be left too late. Perhaps we need to talk more in those sections about how this will feel to a provider as opposed to the technical details that an engineer needs to know. How would you integrate this if you were using an email client, an EHR, or PHR, how will this look to you? Then we can integrate privacy concepts, email concepts, without bringing acronyms up

David Tao
· I was looking for that. Do we have that down in one place? If we did, I’d like to pull from that. If Arien could direct us to a presentation that has those down.
Arien Malec
· Buried into various blog posts.
Janet Campbell
· I also created a document with questions that you have to answer to yourself.
David Tao
· Anyone who could send links would be helpful.
John Moehrke
· One pointer out to NHIN Direct wiki is enough. We should make this document stand on its own. The reader should be able to read this top to bottom without having to go to wiki. They should feel that they understand this for the position they are in. I now know where to point my engineers and implementers.
Janet Campbell
· Segways into discussion about format. Format for how this document will be distributed. I was thinking of putting different pages on wiki. Not something that will be shaved off into a document format. But I could tell from other people’s comments, that there’s a need to have a standalone document.

John Moehrke	I think the wiki could certainly use a better front door, so we could probably reverse some of this once done. But too early right now.
Keith Boone	Nothing to add.
Parag More	Nothing to add
Dragon Bashyam	Once we complete, we can put it on wiki. I’m not tied to document format, it’s easier to coordinate this way.
David Tao	We talked about this a little with you as well . I would like to have a document version available – hopefully fairly short. I think it’s easier to get around. It could also end up being presented in PowerPoints in different variations and provide the source of content for that.
Andy Oram	Nothing else to add.
Karen Witting	What we’re doing is a document and then some of that content will be pulled into appropriate format. I think that’s a good idea.
Will Ross	I am really happy with Janet’s suggestion about the homepage. What we’re talking about is a temporary transitional document that has a specific use at each time. Appropriate to not only create a standalone document and the wiki, but also taking a look at the homepage. Think about how it’s inviting and indexing access to project.
Arien Malec	I’m a fan of the wiki. I do think there are people who are not wiki friendly who would appreciate a word document. I think we should use this as opportunity to look at the wiki and the homepage and see how we’re organizing it.

Janet Campbell
· I think that makes sense. We should start envisioning where this should end up. If I were looking to print something, then I would say Section 9 would probably be too detailed. We’ve had an extremely wide audience. The next thing I wanted to talk about is what we want to do with this going forward.
· What’s best way to revise this document? If people have edits and suggestions?
Dragon Bashyam
· We set up that wiki page.
Janet Campbell
· Should we post a new copy of the document with changes or should we just note individual changes where they would be?
Dragon Bashyam
· Post suggestions to Discussion tab of wiki.
David Tao
· Only tricky thing is to formalize who has the document at any point in time. Maybe offline, we can work out our own process for version management system.
John Moehrke
· I would like to use Word markup. I understand I can add a comment. Not sure how to add a markup document.
Dragon Bashyam
· Open to suggestions.
· Can accept marked up documents.
Janet Campbell
· Will put instructions on that page.
· We do now have the owners and editors column on the documentation priorities list.
· Thank you if you signed up for something.
· We can also use this for call for help area that needs volunteers.
· Any additional volunteers?
John Moehrke
· Will sign up to over-read and help correct information.
David Tao
· Will get back to you on XDD document. Karen posted some comments on that as well.
Arien Malec
· Been reviewing all the code that has been committed. Been looking for a client to host the API document.
· This week I will focus on build processes so we can build API documents automatically.
Janet Campbell
· Most of the other documents are in the technical realm. For people working with Overview documentation, have you found things you need to go into detail about technical requirements because there isn’t a document out there?
David Tao
· It is a perspective that I want to make sure gets covered.
· State HIE folks asked for document describing how NHIN Direct works.
· May need to reach out to people beyond this team to input questions that we could incorporate. If those questions came up, we can write something for them.
Janet Campbell
· How about a question drop box for questions they’ve been hearing to get an outsider’s perspective?
· Perhaps collect some FAQs which will lead us into more of what we should write.
Will Ross
· We owe it to the HIEs that are still confused about NHIN Direct a way to make sure we’re addressing those concerns. I think this is the appropriate document to answer those concerns.
Janet Campbell
· I think that makes sense. We should try to find the questions that we don’t know about too.
· Uvinie, did you want to talk about what you’re putting together?
Uvinie Hettiaratchy
· Am working to put together a high level presentation that could be used at a conference or as a high level overview for executive level decision makers to understand NHIN Direct. Should also address the different perspectives of key stakeholders, such as the State HIE.
· Would like to put together consistent messaging for this presentation, the document and internally within ONC.
· Will reach out to people to help with that in the next call or two.
John Moehrke
· Some of the topics that we haven’t addressed are the technology that should work with off the shelf clients.
Janet Campbell
· While we may not need to do every implementation, messaging that you can do it and pointing to how you would do it would be the level of depth we’d want to get to.
John Moehrke
· I agree we shouldn’t say to Google it. So far my experience is that sometimes it becomes a maintenance nightmare. Would be useful to say here’s a registration of client applications that can support the specification, for services that can as well. Make a registration and encourage those vendors to come forward.