This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Overcoming the Learning Curve"

From HL7Wiki
Jump to navigation Jump to search
m
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
HL7 v3 is generally seen as having a steep learningcurve.
+
==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?
  
 +
==Recommendations==
 
The following is some advice from those that have implemented v3 on how to overcome the learning curve:
 
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.  
 
*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)
 
*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 [https://www.hl7.org/library/bookstore/ HL7 Bookstore]
+
*Read ''Understanding Version 3'' (the primer) - Go to the [http://www.hl7.org/ HL7 Bookstore].  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 familiarization 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 Edition|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 Edition|Normative/]][[Development Edition]]s are useful at a later stage.
+
*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 Edition|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. Study the examples as provided in (or: with) the implementation guide.
*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.
+
**The [[Normative Edition|Normative/]][[Development Edition]]s are useful at a later stage. The HL7 ballot is also an important resource, although it may not be 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. Within the package, start with reading the V3 guide. Then read the sections on data types (the XML ITS Datatypes specification, not the Abstract Datatypes section), the RIM, messaging infrastructure, and the domain sections that cover the application or applications of interest. Read the data types section with great care.
*Attend HL7 training outside of normal peer-based learning
+
*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.  
*Use the contents of the HL7 Wiki, especially for areas such as [[:Category:Lore|Lore]]. It presents a consensus of ideas in plain english (as opposed to standards-speak).
+
*Attend HL7 training (provided by HL7 International, an HL7 affiliate, or by commercial parties) 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 [[:Category:Lore|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.
 
*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.
+
*HL7 is an open community, which allows for Peer Knowledge Transfer, between countries/organizations. Avoid re-inventing the wheel: ask questions; the community is fairly responses when it comes to "newbie" questions.

Latest revision as of 19:59, 15 May 2010

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?

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. 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 familiarization 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. Study the examples as provided in (or: with) the implementation guide.
    • The Normative/Development Editions are useful at a later stage. The HL7 ballot is also an important resource, although it may not be 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. Within the package, start with reading the V3 guide. Then read the sections on data types (the XML ITS Datatypes specification, not the Abstract Datatypes section), the RIM, messaging infrastructure, and the domain sections that cover the application or applications of interest. Read the data types section with great care.
  • 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 (provided by HL7 International, an HL7 affiliate, or by commercial parties) 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: ask questions; the community is fairly responses when it comes to "newbie" questions.