Documentation and Testing Meeting 2010-07-07

Notes from Documentation and Testing Workgroup
Date: July 7, 2010
Time: 2pm-3pm
Attendees: Didi Davis, Tom Silvious, Janet Campbell, John Moehrke, Nageshwara Bashyam, Don Jorgenson, Parag More, Bill Majurski, Arien Malec, Uvinie Hettiaratchy, Douglas Pratt, Hans Buitendijk, Andy Oram

Actions for this Week

#	Date	Action	Status	Owner	Due Date
1	7/7/10	Add audience and training to charter	Open	Arien Malec	7/7/10
2	7/7/10	Reach out to security agent specification team for an update	Open	Arien Malec	7/7/10
3	7/7/10	Create preliminary list of artifacts	Open	Arien/Janet Campbell	7/7/10

Agenda
· Kick Off Meeting

Notes
Arien Malec
· This is a group I’m very excited about.
· The agenda for this meeting is to
o 1) review/amend the overall purpose and goals.
o 2) to create a list of document artifacts and prioritize them
o 3) Select a workgroup lead.
o 4) If we have any spec docs available, I know that Microsoft and Cerner were working on a security agent spec doc, would like to do a first pass review of them.
· Current charter is: Create effective documentation and testing guidance for implementers including:
o Specification documentation
o Implementation guides
o Conformance testing guides
o In addition, the Documentation and Testing Workgroup will create overviews for general consumption and work with the Reference Implementation Workgroup to create a testing service corresponding to the conformance testing guides.
Round on feedback on charter

Didi Davis	· No comment
Janet Campbell	· We might start by looking at specific audiences first. Then look at what things the audience wants to know.
Nageshwara Bashyam	· One thing to add as clarification – in the proposal we were required to interact with other vendors, IHE possibly, are there other organizations developing standards? · Arien Malec – Great comment. Let’s table that for now.
Don Jorgenson	· Fine.
Parag More	· Looks fine. One quick question – Is this group going to be responsible for different artifacts we will come up with? · Arien Malec - This group has authority.
Bill Majurski	· I sit on ITI. I have background in specs and build tools for IHE. Would like to be involved in testing which I thought might be early. · Arien Malec - In the purpose and goals section, the testing documentation and working with reference implementation is dead on where your interests are.
Douglas Pratt	· Looks good. Is this group going to be writing the actual specs or providing general overview items to contractors? · Arien Malec - We will likely be relying on volunteers. There is some grant work available inside ONC and I’ll try to see what I can tap. I’m not promising that we’re going to have funding for it.
Andy Oram	· Notice there is no reference to training in this. Maybe training has different requirements? · Arien Malec - suggestion to add training guide. Let’s hold that as an item for a future round.

Arien Malec
· Sounds like agreement on overall purpose.
· Suggestion to add audience and suggestion to add training or development of training material to purpose and goals.
· Thought there was broad agreement on adding the audience. Let’s jump to holding training on scope of work.
Feedback on adding training to purpose and goals.

Didi Davis	· I think training is important. The training aspect also has more marketing outreach. It may be something that this group may do, but think it’s a deliverable for after specification is done. I like it, but deliverable towards end of phase.
Janet Campbell	· Perhaps our goal is to identify audiences and artifacts and prioritize them appropriately and then fulfill needs to create artifact. We’re going to come up with list, prioritize it, and then write it.
John Moehrke	· I don’t disagree with discussion. I think it’s important to think about training in relation to audience. I think we should also have one step removed specifications about how systems will communicate, not how users will interact. When you get to someone implementing application, it’s up to the application to provide appropriate training.
Tom Silvious	· John hit nail on the head. I would like to focus on implementation guides and less on training until there is something user observable.
Nageshwara Bashyam	· When talking about training materials, you’ll have to do technical materials as well as training materials for adoption and use. I was thinking it might fit better with pilot activities because you learn about what works and doesn’t work when you implement. Hold off until pilots.
Don Jorgenson	· I think the training materials are probably good for later. At this stage, I could provide training information for initial target audience.
Parag More	· I think it’s important, but agree that the implementation guide would be starting point and then expand based on audience.
Bill Majurski	· Nothing to add.
Douglas Pratt	· No comment
Hans Buitendijk	· No comment
Andy Oram	· Thanks for considering it, I think we should delay.
Arien Malec	· I’m going to Janet’s comment and sorting by audience and prioritize by audience. Then we can consider training needs.

Arien Malec
There are 2 more high priority things:
1) Enumerating items for documentation – redirect that to prioritizing audience.
§ Like to do a round on key audiences.
§ Base on the audiences, offline create table of potential documents for implementation guides.
2) Second piece for people to comment is suggestion for a workgroup lead or volunteers.
Round on audiences for consideration for additional documentation and interest in being a workgroup lead.

Didi Davis	· We need to make sure we address audiences of HISP, vendors, implementers as well as State HIEs. Also, if there has to be something separate in way of how HISP relates to multiple states. · Arien Malec - Developer category needs to be developer from a client perspective, so we need one from a HISP perspective. We need define what it means for an organization such as State HIE and regional HIO.
Tom Silvious	· In terms of audience, we do have an audience of testers and their documentation needs are slightly different. There’s the implementation guide that serves the developer but for test planning, we’d have to decide on scope planning.
Janet Campbell	· Developers and those active in pilots. Implementer/Developer area. Other group is the decision makers. For a given pilot, an explanation of what the pilot means to them. We’ve had a lot of interactions with policy makers because I know concern with where NHIN Direct is going. · Would like to volunteer for workgroup lead.
John Moehrke	· Audience of standards organizations. Potentially sending proposals to IHE for consideration. · Arien Malec - I also want to throw in the list security professionals.
Nageshwara Bashyam	· Mentioned most so nothing to add. Think Janet will be fine lead.
Don Jorgenson	· I thought the decision maker was a good audience. Especially business ones. Business architect, business analyst, and process analyst who has overview.
Parag More	· 2 levels for audience – what is the specification tell me if I’m a PHR/EHR vendor or HIO? Second level, if I’m a developer or responsible for certification and operations. Are we talking about these two levels? Are we going to write a separate document for all of them? How are we mixing these audiences? · Arien Malec - I think we should separate the audiences to extent possible. That doesn’t mean we have to write specific documents for each audience. As we prioritize documentation needs and audience needs we can look at each artifact. We need to decide on which audience is our initial audience.
Bill Majurski	· Nothing to add.
Douglas Pratt	· Sounds like we have a good array. Is part of our charter to develop certification tests? Like NIST or testing for internal prototype? · Arien Malec - Need to decide that. First in scope would be in creating the example tests for self certification as early need.
Andy Oram	· Nothing to add.

Arien Malec
· We have one volunteer to be workgroup lead. Based on working with her in the past, she’ll make a great lead. Any objections?
· Hearing none, Janet gets the privilege of being workgroup lead.
· I know that Microsoft and Cerner were working on specification documentation for algorithm for security agent. Does anybody know where that work is?
· I can take the action of pinging that team to see where they are. I’d like to have it available for review.
· To review, we have a charter, we have a couple actions to revise charter, and we have a draft set of audiences.
· Janet and I will take on action of creating preliminary list of artifacts. Arien to start and then send to Janet to review. Any additional topics we need to consider?
Dragon 'Bashyam
· From reference implementation team, are they proceeding with actual implementation? What’s the dependency?
Arien Malec
· We’ve created a list of key deliverables for reference implementation team. They’ve agreed on their charter. We agreed first deliverable would be implementation of S/MIME agent algorithm. They are not waiting on documentation.
· I’m going to be serving on both workgroups and will be in a glue role to make sure we’re in sync. I did find that documentation works best if it’s done in conjunction with implementation. You learn a lot about whether document is good when you try to implement from it.
Don Jorgenson
· You mentioned earlier that you wanted to work with other SDOs?
Arien Malec
· We’re going to have to make a decision about moving this to an SDO for long term keeping. There are a number of good choices for that work. The template that I created for IHE specification documentation is based on an IETF document. My understanding is that IHE is not an SDO but a profiling organization. I think it would be a good topic at some point to talk about where this needs to go.
· Spec factory is a spec writer. An SDO has more stewardship and process of oversight role. IETF does not write specifications, it serves as the process manager and steward for specification. The spec factory can help to write them, but does not solve SDO problem.
Round on feedback for an SDO

Didi Davis	· You mentioned IHE as profiling organization. IHE USA – not sure of status. In IHE world, national deployment would likely fall under IHE USA. It relates to some profiles, not all of them. I don’t know where else we’ll get info from. We’re going to want something that’s not just one SDO. Happy to reach out to counterpart to see if that would be of interest.
Tom Silvious	· Nothing to add.
Janet Campbell	· Nothing to add.
John Moehrke	· I think all options should be on the table. I don’t think we know what we’re producing at this point. The profiling organization will profile existing standards. If we’re profiling how to use email and XDM to produce a result, that’s what a profiling organization does, which makes IHE ideal? If we have to invent standards, then need SDO.
Nageshwara Bashyam	· Nothing to add
Don Jorgenson	· Best place if SDO or profiling organization will depend on specification. Several of us have leadership roles on HL7 and IHE so we should be able to make some decisions.
Parag More	· Nothing to add
Bill Majurski	· Nothing to add
Douglas Pratt	· Nothing to add
Hans Buitendijk	· Echo John. IHE has a good role to play there. Depending on new standards, right SDO needs to be engaged. From profile perspective, IHE is a good choice.
Andy Oram	· Nothing to add

Arien Malec
· Resolution is to find a long term home. We should base long term home on what it is we eventually draft. Key actions that I will work on.