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.

Tuesday, January 27, 2015

Monday at CAT15

Yesterday at the IHE Connectathon I got pulled in to help a developer who had gotten pulled in at the last minute to replace someone else who couldn't make it.  Being unfamiliar with the tools or the process, I showed him how to make a plan to succeed.

The first thing you do for your product is prioritize your work.  Since  profile actors embody the chunks of functionality being tested, they become what you prioritize.  Some profile actors are critical because they are going into shipping product, or could be of use at several customer sites, or will be demonstrated this year at the HIMSS Interoperability showcase. These have to get tested.

Some profile actors are nice to have.  These might be used in future releases, or could be important to a single customer, or you are thinking about demonstrating this profile actor at HIMSS, but haven't committed to that yet.  The nice to have stuff should get tested, but not if it prevents the critical things from getting done.

Finally, there are your stretch goals, or what I call gravy testing.  These are the profile actors that, got added to your plate last week by your product manager to support some hare-brained scheme you just heard about, or some attractive showcase leader walked up to you and asked if you support ___, and you said anything less convincing and firm than no, and as a result found yourself signed up to test a profile you just heard about five minutes ago.  The important thing about these is to remember NOT to let somebody else's priorities become yours simply because you haven't assigned any of your own.

Once you've assigned priorities for actors, now you can prioritize tests.  If you are doing anything requiring Concistent Time (CT), or Audit Trail and Node Authentication (ATNA), do your CT test first.  Then you should look for tests you could have prepared for before you got here (e.g., generating a CDA document to upload for verification).  The monitors expect these first, and it's always good to be nice to the monitors.  Ideally, this is on a stick, and you just upload your samples (you can even do this sometimes before you even get your system being tested unboxed).

Do your tests basically in this order:  No Peer Tests first, Peer to Peer tests second, workflow tests (supporting multiple peers) last.  Don't worry if you take some out of order.

Things not to do: Do not do options testing on a profile actor before nice to have tests are done unless the option is truly critical.  Options fit into the gravy.  The only exception to this is when multiple options are provided in a profile, and at least one must be supported.  Fine, pick your one and call that critical (if the profile actor is critical) or nice to have.

Also in the gravy category are tests with your own products.  These might also fit into the nice have category for you, but the reality is, you shouldn't need IHE to set up a Connectathon for you to test with your own products.  Do it if you can, but only after you are safely passed the critical and nice to have stuff.

After you've made your plan, you have one more job to do.  Go through the tests which are critical and find out who your potential partners can be.  Get their table numbers.  Now, go walk the floor (after you've completed your CT test and uploaded your samples), and introduce yourself to them. Let them know you'll be working together this week.

Ok, so that's Monday (a day late).  I'll try to get Tuesday done just a bit earlier.  What can I say, I had a critical issue to address yesterday, my blog is just gravy.


Post a Comment