Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Thursday, January 29, 2015

Wednesday at CAT15

By Wednesday you should have talked to a Connectathon monitor at least a few times.  Let me tell you about these folks, many of whom are close friends.

Almost all of the people who act as Connectathon monitors are volunteers. Most of them aren't getting paid this week to be here.  I know a guy who takes his vacation time to do this every year because he has fun with it.  A lot of my consultant friends show up here instead of billing hours this week. There are only a few whose day job qualifies them to be monitors who also get paid by their employers to show up (that has do with IHE rules about vendor neutrality).  And all of them I know would do it for the love of the work anyway, and are still giving up time from friends and family to be here.

The monitors are here to help you pass.  If you succeed, they succeed.  If they fail one of the tests you submitted, it is almost certainly because you or one of your testing partners missed something in the specifications. If you start with that assumption, you will be right most of the time. I'd bet that 95% of the problems discovered on the Connectathon floor could be readily fixed if everyone implemented one process: RTFM. Read everything that you can, the specifications, the test plan, and the daily announcements. Check the FAQ pages on the IHE Wiki.

And if you have read what you can, and the spec still isn't clear, or the test, start by asking others questions. Talk to others who may know more than you do.  There are plenty of people on the test floor who've been around for a few years. If you and your test partners cannot agree on how the spec reads, read it again, and ask around. If you still can't resolve it, it's time to ask a monitor for their interpretation.

Be prepared to wait, they may have a queue of people in front of you, but they will follow up, and they will offer good advice.  I find it is better to ask questions, rather than complaining.  It gets you a lot further.  For example, ask where you are in the validation queue, rather than complaining about the fact that your tests aren't being validated. Ask who could help, rather than assuming they have the time to walk you through it (because they don't).  Ask who might be good to test with, they usually have good advice here (they know who does good work).

When there is a question about interpretation, start with explaining that you are confused about what something in the spec means, and be prepared to show them the line in question. Show that you've done your homework; they will appreciate it. You might also ask them for advice about who to talk to for information on the profile that you are having challenges with if you cannot find someone yourself. Many of the profile editors are on the Connectathon floor including some monitors.

Connectathon is the ultimate stress environment, we are often called upon here to do in hours what we are usually given days or weeks to accomplish. It's the perfect environment to practice how you'd work with a customer in a stressful situation. A guaranteed way to fail at Connectathon is to be disagreeable to the monitors.  It's not that they'll fail you just because you are being a pain (because they won't), it's that by being agreeable, you might be able to get that extra minute of their time or guidance that will help you pass.

If this is your first Connectathon, I guarantee, by the time you are done, you will have made friends with several of the monitors. When you make your plans to come back next year, remember your friends, they'll be here again too. 


  1. Your sentiment is good, but I suspect you're confounding two issues:

    - A Connectathon bandwidth issues, where monitor's time cannot be wasted teaching contributors
    - The issue of developing a competence

    Reading 1000 pages is a poor way to develop a competence. An early mistake is as likely to snowball into a disaster... as it is to be resolved by page 999. Writing something demonstrates your gaps immediately. You can be directed to the dozen pages (of the 1000) that really matter and know there's something important on those pages.

    I don't know if this works for a Connectathon, but I suspect so. Have everyone spend 25% of their time mentoring a less experienced contributor. Each master can review the work of the mentor. The master learn by teaching, the student benefits from specific attention to their deficiencies, code is reviewed several times before reaching a monitor, and the monitor need only spend any time teaching the most-senior masters.

    The math works pretty well. 5 monitors with 5 masters each and 5 students each is 155 participants. Nor is symmetry the goal as some can spend more time teaching (with more students), extra layers can be introduced for especially junior contributors, etc.

  2. Mentoring happens here, the point I made is that monitors can guide you to people who can help you. With regard to the specs, you aren't here to learn them ... you are here to show that you HAVE learned them.