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

Difference between revisions of "RIMBAA in the HL7 Roadmap"

From HL7Wiki
Jump to navigation Jump to search
(New page: The HL7 Roadmap defines a number of priorities. The RIMBAA WG efforts fit within STRATEGY 3 – Enhance communication and outreach: make HL7 more useable, useful and understandabl...)
 
Line 13: Line 13:
 
  successful implementation(s) of HL7 standards and translate those benefits into  
 
  successful implementation(s) of HL7 standards and translate those benefits into  
 
  tangible, quantifiable values.
 
  tangible, quantifiable values.
 +
 +
==SMART (TSC)==
 +
In 2010 the TSC has added some details to strategy 3:
 +
 +
Facilitate HL7 standards adoption and implementation. Description: Contribute (often in collaboration with other groups) solutions that make HL7 implementation easier.
 +
*Practicalize the HDF to Develop an example tool-based methodology for implementing one example V3 message or CDA template
 +
*Teach it as a complete course on this methodology over “n?” sessions to a class with “modest” HL7/HIT experience
 +
*Create a workbook of these message/CDA template definitions and then publishing them
 +
*Lead “connectathons” to demonstrate the implementability and usefulness of HL7 standards
 +
**Rene: assumes that people have already build things..
 +
*Provide conformance testing criteria and services
 +
**Rene: most implementers don't like anything that smells of certification, a freebie texting server, hosted somewhere online, or better yet: testing software one can download, will certainly be welcomed.
 +
*Review implementation experiences as part of each DESD [Rene: that's the Domain Experts Steering Devision] Face to Face meeting, identify obstacles and develop approaches to overcome implementation obstacles by Sept 2010.
 +
**Rene: interesting - curious as to why the DESD is seen as the most appropriate party to do this. I'd hope we as RIMBAA could also contribute to this, see my blogpost at [http://www.ringholm.de/column/how_to_lower_the_hurdle_for_HL7_v3_implementers.htm]
 +
*Participate in OHT with HL7 IP and information artifacts and examples
 +
**Rene: examples!
 +
*Description and example of building a V3 message profile/template.
 +
*Develop v2 to v3 maps for domains well supported by v2
 +
**Rene: Robert Worden's activity..
 +
*Determine other methods for publishing/delivering our standards – e.g. publish on KINDLE or DITA
 +
**Rene: I hardly think the publication method is of interest - it's the content that needs to be different to suit the implementers
 +
*V2/V3 strategy to help v2 users understand and help them migrate to V3 where they have requirements for V3 functionality.
 +
**Rene: sounds like a business-level argument
 +
*Require implementation guidance be part of all DESD [Rene: that's the Domain Experts Steering Devision] standards projects
 +
**Rene: I'd like to see an example of the type of implementation guidance they're looking to create
 +
*Develop means of creating an example for each specification
 +
**Rene: examples!
 +
*Look at establishing cross tutorial review teams, to improve tutorial quality.
 +
**Rene: always a good idea, but in order to facilitate the adoption of standards one may need different tutorials, ones not primarily oriented at the methodology.
 +
*(new, see [http://www.ringholm.de/column/how_to_lower_the_hurdle_for_HL7_v3_implementers.htm]) A "HL7 v3 for implementers book": I frequently get asked if there's a v3 book for implementers. If it were to describe an implementers view of the standard, combined with best practices and implementation guidance, and pointers to additional implementation oriented information and tools, it would be an invaluable resource. The current books related to HL7 v3 are all geared towards the standards developers. The creation of such a book would require an up-front investment by whomever is going to write it.
 +
*(new, see [http://www.ringholm.de/column/how_to_lower_the_hurdle_for_HL7_v3_implementers.htm]) Examples, examples, examples: Examples (HL7 v3 XML Instances) are of key importance in understanding the standard, for testing, but also for software development (quite often development is driven by the available examples). The published HL7 v3 standard contains a few examples - which don't validate, and are old. here has been an initiative a couple of years ago to 'force' the standards developers to publish examples along with their domain content - but apparently that initiative has failed, for there are next to none examples,
 +
*(new, see [http://www.ringholm.de/column/how_to_lower_the_hurdle_for_HL7_v3_implementers.htm]) Tools for implementers: Availability of off-the-shelf APIs and other open source tooling, guidance as how one could use cross-industry generic approaches and tools to implement HL7 version 3. It is encouraging that a number of tools has become available to aid the implementation of HL7 v3, notably MARC-HI Everest, a MIF based code generator. with v3
 +
*(new, see [http://www.ringholm.de/column/how_to_lower_the_hurdle_for_HL7_v3_implementers.htm]) Stable software processable HL7 v3 specifications: Implementers either base their implementations on the XML Schema, or (better yet) on the MIFs. Neither the Schema, nor the MIF are normative/stable. Backwards compatibility of either format isn't assured by the standards development process. MIF have to become normative, and be subject to backwards compatibility rules, to really offer implementers the chance to build their software based on a software processable version of the HL7 v3 specifications.
 +
*(new, see [http://www.ringholm.de/column/how_to_lower_the_hurdle_for_HL7_v3_implementers.htm]) Hotline e-mail address: If as an implementer one has a question, you get lost in the 50+ e-mail lists that are available on the hl7.org website. It should be relatively easy to create a support@hl7.org e-mail address, publish it far and wide as part of the marketing efforts, and triage/route the e-mails to the appropriate e-mail list.

Revision as of 10:24, 15 March 2010

The HL7 Roadmap defines a number of priorities. The RIMBAA WG efforts fit within

STRATEGY 3 – Enhance communication and outreach:  make HL7 more useable, 
useful and understandable and share the ideas worldwide

..and more precisely with the items below (listed as part of strategy 3)

1. Produce easy to understand and use implementation tool manuals, 
implementation guides and product overviews (including positioning) for 
our suite of standards. 
5. Capture, categorize and effectively communicate improvements resulting from 
successful implementation(s) of HL7 standards and translate those benefits into 
tangible, quantifiable values.

SMART (TSC)

In 2010 the TSC has added some details to strategy 3:

Facilitate HL7 standards adoption and implementation. Description: Contribute (often in collaboration with other groups) solutions that make HL7 implementation easier.

  • Practicalize the HDF to Develop an example tool-based methodology for implementing one example V3 message or CDA template
  • Teach it as a complete course on this methodology over “n?” sessions to a class with “modest” HL7/HIT experience
  • Create a workbook of these message/CDA template definitions and then publishing them
  • Lead “connectathons” to demonstrate the implementability and usefulness of HL7 standards
    • Rene: assumes that people have already build things..
  • Provide conformance testing criteria and services
    • Rene: most implementers don't like anything that smells of certification, a freebie texting server, hosted somewhere online, or better yet: testing software one can download, will certainly be welcomed.
  • Review implementation experiences as part of each DESD [Rene: that's the Domain Experts Steering Devision] Face to Face meeting, identify obstacles and develop approaches to overcome implementation obstacles by Sept 2010.
    • Rene: interesting - curious as to why the DESD is seen as the most appropriate party to do this. I'd hope we as RIMBAA could also contribute to this, see my blogpost at [1]
  • Participate in OHT with HL7 IP and information artifacts and examples
    • Rene: examples!
  • Description and example of building a V3 message profile/template.
  • Develop v2 to v3 maps for domains well supported by v2
    • Rene: Robert Worden's activity..
  • Determine other methods for publishing/delivering our standards – e.g. publish on KINDLE or DITA
    • Rene: I hardly think the publication method is of interest - it's the content that needs to be different to suit the implementers
  • V2/V3 strategy to help v2 users understand and help them migrate to V3 where they have requirements for V3 functionality.
    • Rene: sounds like a business-level argument
  • Require implementation guidance be part of all DESD [Rene: that's the Domain Experts Steering Devision] standards projects
    • Rene: I'd like to see an example of the type of implementation guidance they're looking to create
  • Develop means of creating an example for each specification
    • Rene: examples!
  • Look at establishing cross tutorial review teams, to improve tutorial quality.
    • Rene: always a good idea, but in order to facilitate the adoption of standards one may need different tutorials, ones not primarily oriented at the methodology.
  • (new, see [2]) A "HL7 v3 for implementers book": I frequently get asked if there's a v3 book for implementers. If it were to describe an implementers view of the standard, combined with best practices and implementation guidance, and pointers to additional implementation oriented information and tools, it would be an invaluable resource. The current books related to HL7 v3 are all geared towards the standards developers. The creation of such a book would require an up-front investment by whomever is going to write it.
  • (new, see [3]) Examples, examples, examples: Examples (HL7 v3 XML Instances) are of key importance in understanding the standard, for testing, but also for software development (quite often development is driven by the available examples). The published HL7 v3 standard contains a few examples - which don't validate, and are old. here has been an initiative a couple of years ago to 'force' the standards developers to publish examples along with their domain content - but apparently that initiative has failed, for there are next to none examples,
  • (new, see [4]) Tools for implementers: Availability of off-the-shelf APIs and other open source tooling, guidance as how one could use cross-industry generic approaches and tools to implement HL7 version 3. It is encouraging that a number of tools has become available to aid the implementation of HL7 v3, notably MARC-HI Everest, a MIF based code generator. with v3
  • (new, see [5]) Stable software processable HL7 v3 specifications: Implementers either base their implementations on the XML Schema, or (better yet) on the MIFs. Neither the Schema, nor the MIF are normative/stable. Backwards compatibility of either format isn't assured by the standards development process. MIF have to become normative, and be subject to backwards compatibility rules, to really offer implementers the chance to build their software based on a software processable version of the HL7 v3 specifications.
  • (new, see [6]) Hotline e-mail address: If as an implementer one has a question, you get lost in the 50+ e-mail lists that are available on the hl7.org website. It should be relatively easy to create a support@hl7.org e-mail address, publish it far and wide as part of the marketing efforts, and triage/route the e-mails to the appropriate e-mail list.