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

Fresh Look

From HL7Wiki
Revision as of 22:59, 16 May 2012 by Llaakso (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Note: Please keep the content on this page polite, and insightful. Content here is public, and also community moderated.


Please add your points as a bullet under here. Links to other pages welcome.

Wishlist items

  • Grahame: Keep it simple as can be - implementers first
  • Ann's list of 4:
    • PIIM
    • Implementer's Guides
      • What exactly does this mean? Implementer vs Implementation guide .. Rene spronk
    • greenCDA
    • simplified wire format (end-to-end greening)
  • William/Michael
  • Rene: implementers either need PIIM for MDA implementations, OR simplified wire format - with normative associated schema.
    • This is AND/OR, not XOR, correct? (Gerald)
    • Yes, AND/OR, although most implementers will choose to use one XOR the other (e.g. if the scope of the project is limited to a very few models, use a simplified wire format. If the project uses tons of models, use MDA). HL7 needs to provide implementers with both options. (Rene)
  • Gerald
    • Clear understanding and separation of interaction models
      • Documents - to stand on their own with context included within artifact
      • Messages
      • Services - context determined by service contract (and perhaps federation agreement)

Grahame's Desiderata for a good specification

A good specification should have the following properties:

  • It has multiple views that address different concerns
    • different users can easily find the concerns that address them
  • Implementers can find a concise view that tells them what they must do to conform
    • first of all described in clear direct terms that takes < 1 hour to get going
    • supported by artifacts that can be used to generate software that can conform
      • Rene: a good specification contains processable artefacts (e.g. used to generate software using ubiquitiously available software tooling) that allow (to the highest degree possible) the testing of conformance. It will probably never be 100% because of e.g. terminology or business rules, but is should be a close as one can get.
    • can be implemented using ubiquitiously available software tooling
  • Business Analysts/Clinicians can easily find the mappings between the artifacts in the standard and business & clinical practice
  • Terminologists/Logicians can find a solid computable base upon which the definitions stand
    • this provides computable artifacts that are used internally to ensure that the simple definitions for the implementers are solid and reliable
    • the computable definitions enable semantic interoperability based on the simple exchange formats
  • The standard and particularly computable artifacts are free for use
  • there is a simple, understandable, implementable and predictable version strategy

Concrete next Steps

For actual things that should be done

  • ahh.... ?
  • Some ideas (Gerald)
    • Decide which approach to develop as part of this activity
      • My favorite: start with RIM as design model; develop process for creating an implementation model; describe requirements for tracing back to RIM (and/or other semantic models such as Archtypes).
    • Decide on the process for working this - HL7 project? Open participation? Collaboration with other SDO?
    • Setup a conference call/meeting and prepare time line
    • Evaluate existing (partial?) solutions

Meeting Minutes

20120514 Minutes