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
 
(18 intermediate revisions by 5 users not shown)
Line 15: Line 15:
 
** simplified wire format (end-to-end greening)
 
** simplified wire format (end-to-end greening)
 
*William/Michael
 
*William/Michael
 +
** Clear separation of infrastructure and clinical content. (or clear separation of definitional knowledge and effective exchange - without breaking the connection)
 
** Registry of templates / models / DCM / archetypes needs to be operational asap
 
** Registry of templates / models / DCM / archetypes needs to be operational asap
 
*** Can we make them available through a website/wiki? Less computable metadata, but quicker availability. (Gerald)
 
*** Can we make them available through a website/wiki? Less computable metadata, but quicker availability. (Gerald)
−
*** OpenEHR has one. What is it that you want this one to achieve? (Grahame)
+
*** OpenEHR has one. What is it that you want this one to achieve? (Grahame) http://www.openehr.org/knowledge/
−
** Clear separation of infrastructure and clinical content. (or clear separation of definitional knowledge and effective exchange - without breaking the connection)
+
*** Netherlands has two:
 +
**** one in DCM format: http://www.eenheidvantaal.nl/
 +
**** two in HL7 v3 R-MIM format http://www.zorginformatiemodel.nl and http://www.sre.nl/web/show/id=132128
 +
*** CDISC work on Share: http://http://www.cdisc.org/cdisc-share
 +
*** Korea EHR project: http://www.clinicalcontentsmodel.org
 +
*** Intermountain Healthcare: http://intermountainhealthcare.org/CEM/Pages/LicenseAgreement.aspx
 +
*** US National Cancer Institute: https://cdebrowser.nci.nih.gov/CDEBrowser/
 +
*** 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)
 
*Rene: implementers either need [[PIIM]] for MDA implementations, OR simplified wire format - with normative associated schema.
 
*Rene: implementers either need [[PIIM]] for MDA implementations, OR simplified wire format - with normative associated schema.
 
** This is AND/OR, not XOR, correct? (Gerald)
 
** 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)
 
** 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 ===
 
=== Concrete next Steps ===
Line 28: Line 60:
 
For actual things that should be done  
 
For actual things that should be done  
 
* ahh.... ?
 
* 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 ===
 +
[[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

Retrieved from "https://wiki.hl7.org/w/index.php?title=Fresh_Look&oldid=61977"