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

Difference between revisions of "Hl7 Internal Architecture"

From HL7Wiki
Jump to navigation Jump to search
 
(One intermediate revision by the same user not shown)
Line 9: Line 9:
 
*CM,JC,NO,CL - to review & revise
 
*CM,JC,NO,CL - to review & revise
  
 +
*** <JC> ok, first I think we need to define what a coherent standards architecture is. Coherence is a property of a whole system in which each element has its proper fit in the system and is logically consistent with other elements within system as a whole and that there are neither any gaps or overlaps among the elements. I think that a coherent specification architecture means that we know:
 +
# what are all the types of components that contribute to our specifications?
 +
# what is the expected life cycle of each type of component? What processes are used for each step and what tools are used in each process?
 +
# how do the components fit together to make up different types of specifications?
 +
# what is the relationships between different types of specifications?
 +
# what is the relationship between HL7 and other SDOs in relation to specifications?
 +
# what the expected users of each type of specification?
 +
# what do we expect the users of each type of specification to do to make use of the specification?
  
 +
*** I think if we can answer all these questions we will have derived not only a coherent internal HL7 architecture but also how HL7 relates to various types of external architectures, both business and technical. <JC>
  
 
==Links==
 
==Links==

Latest revision as of 17:38, 31 October 2012

Architecture for HL7 work products

  • HL7 has an internal architecture- the things that HL7 produces and the process that produce those products. There also an external architecture that describes how those products are used in external environments.
  • CM - what questions does the Architecture answer? - both for what exists today and what we want it to do
  • NO - to pull together a framework to produce a coherent business architecture
  • JC - to use the process for documenting existing tool requirements to
  • CM,JC,NO,CL - to review & revise
      • <JC> ok, first I think we need to define what a coherent standards architecture is. Coherence is a property of a whole system in which each element has its proper fit in the system and is logically consistent with other elements within system as a whole and that there are neither any gaps or overlaps among the elements. I think that a coherent specification architecture means that we know:
  1. what are all the types of components that contribute to our specifications?
  2. what is the expected life cycle of each type of component? What processes are used for each step and what tools are used in each process?
  3. how do the components fit together to make up different types of specifications?
  4. what is the relationships between different types of specifications?
  5. what is the relationship between HL7 and other SDOs in relation to specifications?
  6. what the expected users of each type of specification?
  7. what do we expect the users of each type of specification to do to make use of the specification?
      • I think if we can answer all these questions we will have derived not only a coherent internal HL7 architecture but also how HL7 relates to various types of external architectures, both business and technical. <JC>

Links

Tony Julian