Difference between revisions of "Six Core Architecture Features"
Jump to navigation
Jump to search
WoodyBeeler (talk | contribs) |
Charliemccay (talk | contribs) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | HL7 | + | =Underlying Principles of HL7 Technical Architecture= |
| − | # '''Derive from single Reference Information Model''' (RIM) | + | HL7 develops health care interoperability standards that, according to its mission, are: |
| − | # ''' | + | #'''Here''' we need to say - designed to meet the needs of its membership, of the healthcare community - somehow say its user/needs driven or relevant? |
| − | # '''Reuse models,''' following consistent patterns | + | #'''Here''' we need to say something about how its membership developed, consensus developed, balloted? |
| − | # Address '''multiple implementation paradigms''' (document, messaging, services) | + | #'''Here''' we need Something about quality, usability, scalability, portability, and towards completeness? |
| − | + | ||
| + | =Features of HL7 Technical Architecture= | ||
| + | In order to fulfill that mission, HL7 has adopted a technical architecture that embodies the following features: | ||
| + | # '''Derive from single Reference Information Model and Data Types Specification''' (RIM) | ||
| + | # '''Explicitly bind coded data to defined concept domains and terminologies''' | ||
| + | # '''Reuse static and dynamic models,''' following consistent patterns | ||
| + | # Address '''multiple implementation paradigms''' (document, messaging, services) designed to be independent of the implementation platform | ||
# Are developed using '''shared, documented methodology''' | # Are developed using '''shared, documented methodology''' | ||
| − | # Rely on generic '''computation and data standards''' | + | # Rely on generic '''computation and data standards''', and collaborate with other health care standards groups to the greatest degree possible |
| + | =Notes and Discusssion= | ||
| + | In future these notes should be moved to the "Discussion" tab for this topic, but they are listed here because they came up and were the subject of discussion on the 1/16/2007 call. [[User:WoodyBeeler|WoodyBeeler]] | ||
| − | ==Actions from 20070116 Conference Call== | + | ===Actions from 20070116 Conference Call=== |
#Need to directly reference HL7's primary Mission and Product strategy in the opening paragraph of these, and state that these are the Techie elevator points, not the marketing elevator points. (per V. Lorenzi) | #Need to directly reference HL7's primary Mission and Product strategy in the opening paragraph of these, and state that these are the Techie elevator points, not the marketing elevator points. (per V. Lorenzi) | ||
#'''Need an over arching schema''' (such as B. Blobel proposes) to bind these together in a functional fashion that will inform and guide | #'''Need an over arching schema''' (such as B. Blobel proposes) to bind these together in a functional fashion that will inform and guide | ||
| − | + | ===First note From Bernd Blobel (20070115)=== | |
| − | |||
| − | ===First note From Bernd Blobel=== | ||
[http://www.hl7.org/documentcenter/public/wg/t3f/general/ICMCC_2006_Lopez_PHR.pdf Attached I send you an early paper] on deriving a development methodology of systems in close relation to the development of standards (messaging and architecture standards). | [http://www.hl7.org/documentcenter/public/wg/t3f/general/ICMCC_2006_Lopez_PHR.pdf Attached I send you an early paper] on deriving a development methodology of systems in close relation to the development of standards (messaging and architecture standards). | ||
| Line 21: | Line 27: | ||
Extending the RUP can provide a good classification basis for our work. | Extending the RUP can provide a good classification basis for our work. | ||
| − | ===Second & third notes from Bernd Blobel=== | + | ===Second & third notes from Bernd Blobel (20070116)=== |
... Therefore, I'd like to make some comments regarding Woody's Core Architecture Features. | ... Therefore, I'd like to make some comments regarding Woody's Core Architecture Features. | ||
| Line 30: | Line 36: | ||
Even while security and privacy represent a special domain like others (the term has been extended to the domain term used in HL7), the importance of security and privacy services in the architectural approach should be eventually emphasized. | Even while security and privacy represent a special domain like others (the term has been extended to the domain term used in HL7), the importance of security and privacy services in the architectural approach should be eventually emphasized. | ||
| − | ===Note from Virginia Lorenzi=== | + | ===Note from Virginia Lorenzi (20070116)=== |
On architecture - everything you wrote, I liked. Thought of other things that perhaps need to be folded in in some way - not sure. | On architecture - everything you wrote, I liked. Thought of other things that perhaps need to be folded in in some way - not sure. | ||
| Line 37: | Line 43: | ||
#Standard terminologies. Do we really tell people what terminologies to use? This still seems fuzzy to me. | #Standard terminologies. Do we really tell people what terminologies to use? This still seems fuzzy to me. | ||
#Based on generic standards. Also done in collaboration and taking full advantage of companion standards in other areas. | #Based on generic standards. Also done in collaboration and taking full advantage of companion standards in other areas. | ||
| − | #Do we need to say - designed to meet the needs of its membership, of the | + | #Do we need to say - designed to meet the needs of its membership, of the health care community - somehow say its user/needs driven or relevant? |
#Do we need to say something about how its membership developed, consensus developed, balloted? | #Do we need to say something about how its membership developed, consensus developed, balloted? | ||
#Something about quality, readability, usability, completeness? | #Something about quality, readability, usability, completeness? | ||
| − | Do we need to have references (where in HL7 existing documentation we get what we list to give it more credibility and show we not just starting from scratch)? | + | Do we need to have references (where in HL7 existing documentation we get what we list to give it more credibility and show we not just starting from scratch)? ''[[User:WoodyBeeler|WoodyBeeler]] Yes, but I believe there will be a 1-3 sentence paragraph below each of these, and that is where the links should be.'' |
Latest revision as of 17:20, 24 January 2007
Contents
Underlying Principles of HL7 Technical Architecture
HL7 develops health care interoperability standards that, according to its mission, are:
- Here we need to say - designed to meet the needs of its membership, of the healthcare community - somehow say its user/needs driven or relevant?
- Here we need to say something about how its membership developed, consensus developed, balloted?
- Here we need Something about quality, usability, scalability, portability, and towards completeness?
Features of HL7 Technical Architecture
In order to fulfill that mission, HL7 has adopted a technical architecture that embodies the following features:
- Derive from single Reference Information Model and Data Types Specification (RIM)
- Explicitly bind coded data to defined concept domains and terminologies
- Reuse static and dynamic models, following consistent patterns
- Address multiple implementation paradigms (document, messaging, services) designed to be independent of the implementation platform
- Are developed using shared, documented methodology
- Rely on generic computation and data standards, and collaborate with other health care standards groups to the greatest degree possible
Notes and Discusssion
In future these notes should be moved to the "Discussion" tab for this topic, but they are listed here because they came up and were the subject of discussion on the 1/16/2007 call. WoodyBeeler
Actions from 20070116 Conference Call
- Need to directly reference HL7's primary Mission and Product strategy in the opening paragraph of these, and state that these are the Techie elevator points, not the marketing elevator points. (per V. Lorenzi)
- Need an over arching schema (such as B. Blobel proposes) to bind these together in a functional fashion that will inform and guide
First note From Bernd Blobel (20070115)
Attached I send you an early paper on deriving a development methodology of systems in close relation to the development of standards (messaging and architecture standards).
In some weeks, I can distribute a more extended paper.
Extending the RUP can provide a good classification basis for our work.
Second & third notes from Bernd Blobel (20070116)
... Therefore, I'd like to make some comments regarding Woody's Core Architecture Features.
I would add the reflection of the model driven architectural approach using the Zachman model as well as MDA or the RM-ODP classification.
Interpretation of this approach can be found in the paper I've distributed to T3F. I'd like to add the need of ontology-based reference terminologies as well as the separation of computation-independent, platform-independent and platform-specific aspects.
Even while security and privacy represent a special domain like others (the term has been extended to the domain term used in HL7), the importance of security and privacy services in the architectural approach should be eventually emphasized.
Note from Virginia Lorenzi (20070116)
On architecture - everything you wrote, I liked. Thought of other things that perhaps need to be folded in in some way - not sure.
- when talking about reuse, don't just say model - say static and dynamic model. In my experience people assume static and forget all about the dynamic : )
- Don't just say RIM, maybe also say RIM and Data Types.
- Standard terminologies. Do we really tell people what terminologies to use? This still seems fuzzy to me.
- Based on generic standards. Also done in collaboration and taking full advantage of companion standards in other areas.
- Do we need to say - designed to meet the needs of its membership, of the health care community - somehow say its user/needs driven or relevant?
- Do we need to say something about how its membership developed, consensus developed, balloted?
- Something about quality, readability, usability, completeness?
Do we need to have references (where in HL7 existing documentation we get what we list to give it more credibility and show we not just starting from scratch)? WoodyBeeler Yes, but I believe there will be a 1-3 sentence paragraph below each of these, and that is where the links should be.
