• Notes from Documentation and Testing WG
Date: September 29, 2010
Time: 2:00 - 2:50pm EST
Attendees: Noam Arzt, Nageshwara (Dragon) Bashyam, Tony Calice, Janet Campbell, Andy Oram, Parag More, Will Ross, Karen Witting, Arien Malec, Caitlin Ryan

Actions

Actions for This Week


#
Date
Action
Status
Owner
Due Date
64
9/29/10
Edit Deployment Models document.
Open
Janet Campbell, David Tao (absent0, Noam Arzt
10/6/10
65
9/29/10
Grow Content Security for Simple Health Transport Spec.
Open
Arien Malec
10/6/10
66
9/29/10
Add Documentation Priorities list to Doc/Testing WG main page.
Open
Janet Campbell
10/6/10
67
9/29/10
Add Programmer’s Introduction to documentation Priorities list
Closed
Janet Campbell
9/30/10
68
9/29/10
Begin to work on Programmer’s Introduction.
Open
Dragon Bashyam
10/6/10
69
9/29/10
Create outline of a documentation map.
Open
Andy Oram
10/6/10
70
9/29/10
Deploy CSharp API documentation
Open
Arien Malec
10/6/10
71
9/29/10
Assist Sean Nolan and Claudio Sanchez with APIs.
Open
Arien Malec, Tony Calice
10/6/10
72
9/29/10
Change name of XDD Spec to XD* Conversion Specification, as a working title.
Open
WG
10/6/10
73
9/29/10
Meet to discuss changes to the Abstract Model (Thursday (9/30), 3:00pm EST).
Open
Interested WG members
10/6/10
74
9/29/10
Change all “NHIN Direct” references to “Direct Project.”
Open
Janet Campbell
10/6/10
75
9/29/10
Work on some of the other questions raised after the Call for Consensus for the Policy Questions for Implementations document.
Open
Janet Campbell
10/6/10
76
9/29/10
Will incorporate comments in the Direct Security Overview after them receiving them from the Security and Trust WG.
Open
Dragon Bashyam
10/6/10
77
9/29/10
Begin work on Testing Guide, in collaboration with John Moehrke (absent).
Open
Tony Calice
10/6/10
78
9/29/10
Continue work on Conformance Guide.
Open
Parag More
Keith Boone (absent)
10/6/10
79
9/29/10
Begin finding the right people to answer the questions on the FAQ document.
Open
Dragon Bashyam and Will Ross
10/6/10
80
9/29/10
Create “Directopedia” glossary page on wiki.
Open
Caitlin Ryan
10/1/10

Actions from Last Week (2010-09-15 Meeting)

#
Date
Action
Status
Owner
Due Date
46
2010-09-15
Look at Deployment Models document.
Open
WG members
2010-09-22
47
2010-09-15
Sign up for the Google Group so you are not left out of emails.
Open
WG members
2010-09-22
48
2010-09-15
Edit Deployment Models document.
Open
David Tao
2010-09-22
49
2010-09-15
Send document URLS out via the Google groups, at the request of Andy Oram.
Open
Janet Campbell
2010-09-22
50
2010-09-15
Draft “NHIN Direct Specifications” document and schedule document focus meeting.
Open
Arien Malec
2010-09-22
51
2010-09-15
Look over API documents.
Open
Andy Oram
2010-09-22
52
2010-09-15
Point Andy Oram in the right direction for API documents.
Open
Arien Malec
2010-09-22
53
2010-09-15
Reach out to Mr. Palmer about his work on a document similar to the Email Client Configuration Guide.
Open
Dragon Bashyam
2010-09-22
54
2010-09-15
Schedule XD* focus meeting for next Thursday morning.
Open
Arien Malec
2010-09-22
55
2010-09-15
Work on XD* document over the next week.

Arien Malec, David Tao
2010-09-22
56
2010-09-15
Begin drafting a new document with the objective: documenting for how someone can take existing implementation reference and translate it to be able to send/receive NHIN Direct messages.
Open
Karen Witting, David Tao, Janet Campbell
2010-09-22
57
2010-09-15
Rename the XDD document “XD* for Direct.”
Open
WG
2010-09-22
58
2010-09-15
Map out documentation so readers know the pattern in which they should read.
Open
WG, Team
2010-09-22
59
2010-09-15
Ask Paul Tuten for FAQs list to be put on the wiki.
Open
Janet Campbell
2010-09-22
60
2010-09-15
Start tracking the status of documents in the documentation table.
Open
Janet Campbell
2010-09-22
61
2010-09-15
Create a Master Glossary for the wiki, for glossaries within other documents to link to.
Open
WG? Team?
2010-09-22
62
2010-09-15
Draft high-level Testing Guide.
Open
John Moehrke
2010-09-22
63
2010-09-15
Edit high-level Testing Guide.
Open
Arien Malec
2010-09-22

Agenda

Notes


Janet Campbell
  • Apologized for a slow week.
  • Back in the game this week, looking to go through list of documentation for this meeting.
Deployment Models
Janet Campbell
  • John Moehrke will not be at this meeting, but he had mentioned that the Deployment Models text is done; only diagrams need to be updated.
    • Deployment Models document can move into initial review and editing.
    • Janet believes this is one of the most important documents.
    • Andy Oram felt a top-down view of how the HISP and implementations can work together is missing.
    • Deployment Models document could use some editing.
    • David Tao said he could edit at a previous meeting.
    • Asked for anyone else willing to edit.

Noam Arzt
  • Offered to edit.

Janet Campbell
  • Will edit diagrams.

Content Security for Simple Health Transport
Arien Malec
  • Needs to exist, needs to get bigger.
  • Arien’s to-do.
  • Status: content, as it stands, is accurate, but needs to grow.
  • Needs to have content specs and addressing specs rolled into it to be the overall Direct Spec.

Janet Campbell
  • Asked if assistance is needed.

Arien Malec
  • Most efficient if Arien finds the time to do it himself.

API
Janet Campbell
  • API documentation is linked up.
  • Andy Oram had said an overview for programmers was missing.

Andy Oram
  • Feels WG should create something, not architecture, but how things flow and what each part is responsible for.
  • Saw one document on architecture, but hasn’t looked at Deployment Models yet.

Janet Campbell
  • Referred him to Deployment Models, which lays out the different types of architectural setups.

Andy Oram
  • Requested the URL.

Arien Malec
  • Wikis are good for creating lots of documentation quickly, but sometimes organization needs to happen.
  • Let us know if you we need to create more cross links and pointers on the wiki.
  • He always goes to Documentation Priorities as documentation index page, but it might be good to bump that content into the Doc/Test WG homepage.
    • Or create pointers to those documents on the Doc/Testing WG page.

Janet Campbell
  • Agreed.
  • Took status column off, but could add back in for status of draft v. consensus, etc.
  • Was previously thinking about a status row instead of a status column.
  • Could move entire Documentation Priorities to main documentation page.

Andy Oram
  • Has trouble understanding who the audience is supposed to be.
  • Thought documentation would be meant for individual hospitals, technicians, or the people helping them, but some of it seems written for Mirth or another company doing HIE work

Janet Campbell
  • It depends.
  • Can branch off into the more specific key segments.

Andy Oram
  • Didn’t feel that information was on the document he was reading.

Arien Malec
  • Could add a standard “who is this for?” section to the top of each document.
  • John Moehrke had also suggested a “what am I supposed to read before I read this?” section.

Tony Calice
  • Has usually seen an introduction section, listing questions the document will answer.

Janet Campbell
  • Interesting because many but not all of the documents have an “abstract” stating who is supposed to read and what they will get out of it.

Tony Calice
  • Abstract section was great, should at least temporarily keep in the documents to provide focus.
  • He’s used something similar in the past when working with a template.
  • Has found he’s started out answering questions correctly but they aren’t always the questions people want answered.

Janet Campbell
  • Will keep an eye on.
  • Will add list in the table for a Programmers Introduction, which describes the document Andy Oram was feeling a need for.
  • Architecture and key goals, how it all fits together.

Arien Malec
  • So this document will cover, “I’m a programmer, where do I start, do I want to implement my own? Do I want to use the ref imp?” Here’s where to go and here’s how to get started.

Comment
  • Suggested a documentation map or website to show the path through the documents.
  • They wouldn’t all fall on it, but many of them would.

Andy Oram
  • Could create a straw man map, but the first draft might have incorrect information because he is still unfamiliar.
  • Can start with something as a framework, then others can correct.

Low-level API documentation

Arien Malec
  • CSharp API documentation is quite advanced from what is on the website, he needs to deploy it.

SMTP, S/MIME

Arien Malec
  • Sean Nolan is working on a draft of this for the Best Practices WG.
  • Reference Implementation WG highlighted a need for good client API as a strong business need.
  • Implies having good APIs.

Janet Campbell
  • API in sense of programmatic API?

Arien Malec
  • Yes.
  • Saying, I want to roll this into my EHR or EHR module, here’s how I do that.

Tony Calice
  • Located in same office as Claudio Sanchez who is working with Sean Nolan and others.
  • Volunteered to work with them.

Arien Malec
  • Will be working with an API or client spec.
  • Can also assist.

XD* Specification

Janet Campbell
  • Seems a lot will have to do with how the reference implementation comes along.

Arien Malec
  • The spec is coming along nicely.
  • XDD spec wants to get bigger, so will end up with two mega specs: XDR, XDD.
  • Available on the XDD specification page.
  • Will keep working on it.
  • Documentation there is correct as is, just needs more.

Janet Campbell
  • Is there a way to know when we are done?

Arien Malec
  • Good plan are in place for what still needs to be done.
  • Will be done when all feel there is enough.

XDD Developers Guide

Arien Malec
  • Thinking that the Client API will only require one for both.

Janet Campbell
  • How to start at XDR and XDM.

Arien Malec
  • Wants to go into the XDD spec.

Janet Campbell
  • Talked about at last meeting, grew out of the XDD API and Developers Guide, and might grow back into it.
  • Starting out with an EHR module that can speak XDR, how do you take what you have and integrate it?

Arien Malec
  • Spec for step up, step down.

Karen Witting
  • Asked about name change for the XD* spec.

Arien Malec
  • Right now it is still called the XDD spec.

Karen Witting
  • Wrote an outline on the XDD Spec and gave it a new name of XD* Conversion Specification.
  • Doesn’t know what XDD is. Doesn’t describe anything for her.

Janet Campbell
  • Direct has been using XDD as shorthand to communicate minimal metadata.

Karen Witting
  • XDD is about a set or requirements on metadata?

Arien Malec
  • XDD is what is currently described in the spec document, can rename in the spec document.
  • Currently describes how to use profiles in Direct.

Karen Witting
  • Will keep complaining about the term “XDD” because she doesn’t think it means anything.
  • The definition was once there, but is no longer part of documentation.
  • She avoids using “XDD” because of lack of definition.

Comment
  • Do you have an idea of what it is trying to accomplish?


Arien Malec
  • What is a good title for the current document?

Karen Witting
  • On Friday she proposed an outline, named it XD* Conversion Specification.

Arien Malec
  • Will use XD* Conversion Specification as a working title and run with it.

Karen Witting
  • She is not attached to title, it is just a suggestion.
  • Doesn’t’ like “XDD” because doesn’t feel there is an agreed upon definition.

Comment
  • Is it expected the audience would understand XDD?

Arien Malec
  • Calling it XD* Conversion for Direct should be self-explanatory enough.

Janet Campbell
  • There was some talk originally about seeing if they could petition to change the required XDR and XDS metadata.

Karen Witting
  • Decided only on XDR.

Janet Campbell
  • So if that succeeded, it would be the “XDR specification.”
  • This is XDR and having another name in there isn’t useful, right?

Karen Witting
  • Feels it is weird to sound like you have an IT acronym when you don’t.
  • Misleading. Implying something that isn’t valid.
  • Doesn’t know if IT will modify XDR or create something new and call it XDD.
  • Giving it a profile name when it is not a profile, when changing the requirements for metadata, isn’t really a profile in the first place.
  • Would use “XDR minimal metadata.”
  • Should be “XDR for NHIN Direct.”

Janet Campbell
  • To conclude, XDD is shorthand for something not well defined, essentially meaningless.

Karen Witting
  • Either need to come up with new definition or use a different term.
  • Is not clear on why they need multiple documents.
  • Feels the spec needs work, but that the “how to do it” can be in there.
  • Doesn’t need to be separate.
  • This is tricky stuff.
  • Don’t need to make another work item until the first is finished.

Direct Project Overview
Janet Campbell
  • Will fix the text on it later.
  • Biggest to-do is the Abstract Model
  • Ended up with a discussion on what the Abstract Model should be and how much detail they should go into.
  • Changing all “NHIN Direct” references to “Direct Project.”

Policy Questions for Implementations
  • Most of the feedback: what we have is good, but there is more that we could continue to add.
  • Might never finalize and have consensus, but could pass to Communications WG or Best Practices WG for them to create materials from (e.g. a brochure).
  • Will take a crack at some of the other questions raised after the Call for Consensus.

Arien Malec
  • Might be useful to collaborate with Best Practices WG on determining which of the questions are Policy questions (“big p”) at HIT Policy Committee and ONC level, which belong at local implementation level, and which fall in between as “medium p” best practices that are not yet addressed at Policy level but should probably be standardized before they get down to the individual level.
  • Some categorization might be useful.
  • Suggested collaboration between Documentation and Testing WG and Best Practices WG.

Janet Campbell
  • Has been her experience that even the Policy questions, with the interaction of state law, local law, and temperament of lawyers, need to be careful.
  • Should be careful with Policy questions not to overstep, i.e. “the Direct Project said it was ok for you not to collect consent.”

NHIN Direct Security Overview
Dragon Bashyam
  • Sent out to Security and Testing WG, but they are on hiatus.

Janet Campbell
  • Heard they are coming out of hiatus.

Dragon Bashyam
  • Will incorporate comments after they receive them.
  • Will wait until the end of the week, then figure out strategy, and talk to Sean Nolan.

Janet Campbell
  • Asked if they could aim for Call for Consensus on 10/12/2010.

Dragon Bashyam
  • Agreed.

Testing Guide
Janet Campbell
  • Currently has no owner.

Arien Malec
  • For the Integrate-a-thon/Test-a-thon/Code-a-thon in late October, trying to get a lot of people trained on how to deploy, figure, test implementation.
  • Would be useful to have enough material prior to then to give HISPS or wanna-be-HISPs good guidance on when they can consider their work complete and tested.

Janet Campbell
  • Who has the knowledge to start writing this?

Arien Malec
  • Tricky because it should go off of the spec, not the reference implementation.
  • If Java and CSharp reference implementations talk to each other, whatever they did is close to conformance.
  • Sean Nolan suggested S/MIME enable email client.
  • If you can operate with that, probably would work.
  • Sean Nolan volunteered to take the first crack at that, and then John Moehrke was the newest owner.
  • John suggested test case/flows at a high level, i.e. if your implementation can talk to one of the other reference implementations and S/MIME clients, then you’re probably in reasonably good shape.
  • John volunteered to do an outline of a testing guide.

Tony Calice
  • Has written testing guides in the past.
  • Willing to take a crack at it.
  • Will propose a structure for it in the next week.
  • Will utilize connection with Claudio Sanchez.

Arien Malec
  • John Moehrke could probably send Tony Calice an e-mail as a jumpstart.

Comment
  • Thinks the big challenge is that in several ways the cart is before the horse in the testing guides.

Arien Malec
  • Right.
  • It is best if you have a spec and your testing guide is derived from the spec, so it truly can test the spec.
  • Most of what the spec is currently is, “you use S/MIME this way.”
  • John’s point was there are lots of implementations.
  • If your software can do XYZ, you have a good likelihood of doing it right.

Janet Campbell
  • Maybe at the end of October event, some people can listen to what is happening on the ground and record what is actually happening.
  • I.e. “This didn’t work because of this thing, now we know to add it.”

Conformance Guide

Janet Campbell
  • May point to some testing as well.
  • Was Keith Boone and Parag More.

Parag More
  • Was originally created using Abstract Model but now makes sense to use Deployment Models instead.
  • Content might need a complete overhaul.

Janet Campbell
  • Asked if he is still able to do that.

Parag More
  • Yes, will continue to work on.
  • Deployment Models are at a stage of final review so they can organize and put out a format for the Conformance Guide.


FAQs
Janet Campbell
  • Implementation Geographies WG came back with a list of initial FAQs.
  • Someone can look at the list and find the people who can answer them.

  • Dragon Bashyam and Will Ross volunteered.

  • Dragon Bashyam volunteered to work on Programmers Introduction as well.

Janet Campbell
  • Direct dictionary project.
  • Came across for Security.
  • Start by pulling out of Direct Overview, then add to it.