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

Difference between revisions of "Fresh Look"

From HL7Wiki
Jump to navigation Jump to search
 
(8 intermediate revisions by 3 users not shown)
Line 27: Line 27:
 
*** US National Cancer Institute: https://cdebrowser.nci.nih.gov/CDEBrowser/
 
*** US National Cancer Institute: https://cdebrowser.nci.nih.gov/CDEBrowser/
 
*** Tolven
 
*** Tolven
 +
*** [[List of template registries]]
 
** Proper rules for transformations from different model artifacts to other artifacts, and validation of these.
 
** Proper rules for transformations from different model artifacts to other artifacts, and validation of these.
 
** Clear migration strategy, which is tested to work, before changing HL7 v3 proper to not frustrate the ongoing implementations which are now just starting to be moving ahead (Alexander)
 
** Clear migration strategy, which is tested to work, before changing HL7 v3 proper to not frustrate the ongoing implementations which are now just starting to be moving ahead (Alexander)
Line 37: Line 38:
 
*** Messages
 
*** Messages
 
*** Services - context determined by service contract (and perhaps federation agreement)
 
*** 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 ===
 
=== Concrete next Steps ===
Line 48: Line 66:
 
** Setup a conference call/meeting and prepare time line
 
** Setup a conference call/meeting and prepare time line
 
** Evaluate existing (partial?) solutions
 
** Evaluate existing (partial?) solutions
 +
 +
===Meeting Minutes ===
 +
[[Media:FRESH_LOOK_minutes20120514.docx|20120514 Minutes]]

Latest revision as of 22:59, 16 May 2012

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

Triage

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