Implementation Guide

A v3 Implementation Guide (created by HL7 or by any other organization) is a non-machine testable description of various artefacts (be they CDA documents or v3 messages), the description of which may extend well above the detail offered by machine processable definitions such as Templates or message profiles.

The implementation committee aims to finalize the description of an implementation guide by May 2007, styleguide, and requirements for tooling in this area. We'll need to distinguish between v3, CDA and other implementation guides.

The table of contents for a v3 messaging or CDA implementation guide should include: (based on best practices from CDC/NLM/IHE/v2 implementation guides):

• background on why the specification exists and how it fits into business context
• background on reading HL7 specifications
• Storyboards and "Transctions" (business rules)
  • various Interactions and Trigger Events
• static models & walkthroughs
  • background on datatypes and vocabulary/vocabulary binding
• "implementation considerations", both relating to code as well as relating to workflow, regulatory environment and other stakeholder considerations
• test scenarios
• Examples (and plenty of them - these tend to be crucial for implementers)

The "profile" portion of most implementation guides will probably be implemented using existing tooling to document static model and dynamic model constraints.

Especially for HL7-authored implementation guides, but in principle also for others: Implementation guides may be MIF-driven and use the same publication process we use for balloting. However, at this point in time (October 2006) the tooling to support this is still a way off.

Related

A Message Profile is a machine testable specification of all kinds of conformance issues related to one single message.

Examples

Links to example implementation guides:

• IHE ITI MPI. IHE profile for v3 messages.
• IHE Lab profile, volume 1, IHE Lab profile, volume 2. Typical IHE v2 message based profile.

Discussion

• (Virginia) I like the definition on the wiki. Its important to me that Implementation Guides have a standard format if possible and best practices. I have seen so many V2 specs with different look and feel and often missing important explanations. Each one leaves out something and often not the same thing. I think message profiles will take care of alot of that (for example, MWB for V2 prompts users to fill in information. But it would be nice if the entire publication related to implementation had standards applied to it.
• (Virginia) Are we considering how IHE does implementation guides?
• (Patrick Lloyd, 20061107 Implementation TelCon) Use the NLM content description as a guideline/checklist. GordonPoint Informatics creating impl guides. Similar to HL7 ballot infrastructure. Based on extsion on R-MIM designer, to capture additional information, used to generate HTML files. Spreadsheet which takes over some of the function of the biz level transaction, multiple interactions, presented in document. MS Word driven, set of macro. Link in Exec summary, links to external documents e.g. external vocab document. Mostly HL7 driven, driven from HL7 models. RMIM documentation inherited (for consistency) from D-MIM documentation, hard to do though. NLM has a February deadline for its implementation guide project.
  • NLM Implementation Guide Tool. exec summary, introduction (overview, purpose, audience, scope, assumptions, conventions), biz models, transactions (biz level, comprised of multiple interactions), message models.
  • RMIM designer: properties of object/attributes: enter business names, implementation notes, etc. Used by harvester and pulls it into generated HTML by implementation guide tool.
  • Dynamic spreadsheet: ability to group dynamic interactions into transactions, to illustrate what you're doing in your use-case. Pubs DB not usable here, use spreadsheet to captute information which is needed in implementation guide. Linking of transactions and interactions.
  • Macro's in background which produce HTML shown at beginning of demo.
• (Allie) Need to keep in mind conformance/compliance in creation of Implementation Profiles, to clearly identify where deviations are ...