This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Fresh Look"
Jump to navigation
Jump to search
Line 38: | 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 | ||
+ | ** 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 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 === |
Revision as of 08:13, 14 June 2011
Note: Please keep the content on this page polite, and insightful. Content here is public, and also community moderated.
Contents
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
- 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
- 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) http://www.openehr.org/knowledge/
- 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.
- 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.
- 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)
- Clear understanding and separation of interaction models
= 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
- 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 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
- Decide which approach to develop as part of this activity