Overcoming the Learning Curve

Introduction

Approaching a new subject area when implementing a complex project can be quite a daunting prospect in any situation, but what if that subject area is an emerging standard such as HL7 V3?

Over the years since its inception, HL7 V3 has developed an aura of mystery and impenetrability which is little helped by the fact that a large proportion of HL7 V3 knowledge and expertise is held in the heads of a relatively small number of specialists.

See the discussion page for research done by Ruth Kidd for a presentation given at the IHIC 2006 in Cologne. (The presentation is available in PDF format here.) It addresses some of the problems caused by the lack of educational accessibility to the standard, as seen through the eyes of someone who has recently faced the HL7 V3 learning curve (or vertical ascent :-) and emerged virtually unharmed on the other side.

Recommendations

The following is some advice from those that have implemented v3 on how to overcome the learning curve:

• Make sure to invest both time and resources in the initial phase. The cost to entry is significant, however once you know the basics it is relatively easy to extend. The HL7 object model introduces complexity for simple messages on the one hand, but provides a unified model for complex clinical messages.
• Use the introductory presentations on the HL7.org website (although these are fragmented at the moment, have inconsistent design/presentation, are confusing when read "out of context", and some are quite old)
• Read Understanding Version 3 (the primer) - Go to the HL7 Bookstore. Those who started working with HL7 before the primer was available agreed that they would have benefited a great deal from such a resource. The primer is a good introduction to the basics, but it doesn't contain enough detail to be very helpful in terms of actual message design and implementation. Such a level of detail is out of scope for that document, but a more practical follow-on artefact would be very useful for message developers. Most agreed that although literature is unlikely ever to be as helpful as hands-on experience and learning from peers, it is very helpful in terms of topic familiarisation and as an aid for learning the basics.
• Use a (Framework-) Implementation Guide (one single domain within the implementation guide) as a starter document for those new to v3, and not a Normative/Development Edition. The implementation guide describes a relatively small and selfcontained subset of the standard and is implementation oriented, which makes it easier on the reader. The Normative/Development Editions are useful at a later stage.
  • The HL7 ballot is also an important resource, although most did not find it terribly useful in the early stages of learning; it is not a 'beginner's guide' and is not intended to be such. However, as newcomers did start to use it more frequently, they did note that the lack of a search function made it quite hard to navigate if you didn't already know what you were looking for.
• Have one or more HL7 v3 experts on your team. They play the role of catalyst and keep the rest of the team on track through peer review and collaborative design. Having people around (or at least easily contactable) who know V3 and can provide advice and guidance to newcomers regarding design decisions, tooling 'features', standards compliance and so forth is more valuable than mountains of literature.
• Attend HL7 training outside of normal peer-based learning
• Hands-on experience is probably the most effective way to learn quickly and to retain the knowledge.
• Use the contents of the HL7 Wiki, especially for areas such as Lore. It presents a consensus of ideas in plain English (as opposed to standards-speak).
• Familiarity with healthcare workflows, as well as messaging in general is a plus.
• HL7 is an open community, which allows for Peer Knowledge Transfer, between countries/organizations. Avoid re-inventing the wheel.