This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Hl7 Internal Architecture"
Jump to navigation
Jump to search
m (Architecture moved to Hl7 Internal Architecture) |
|||
(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:
- 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>