This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Hl7 Internal Architecture"
Jump to navigation
Jump to search
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | {{Arb work in progress}} | ||
==Architecture for HL7 work products== | ==Architecture for HL7 work products== | ||
| Line 8: | 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== | ||
*[http://www.rm-odp.net http://www.rm-odp.net] | *[http://www.rm-odp.net http://www.rm-odp.net] | ||
| + | [[Category:ARB_work_in_progress]] | ||
| + | [[User:ajulian | Tony Julian]] | ||
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>
