Difference between revisions of "Six Core Architecture Features"

From HL7 TSC
Jump to navigation Jump to search
Line 4: Line 4:
 
# '''Reuse models,''' following consistent patterns
 
# '''Reuse models,''' following consistent patterns
 
# Address '''multiple implementation paradigms''' (document, messaging, services)
 
# Address '''multiple implementation paradigms''' (document, messaging, services)
 +
#* Platform independence
 
# Are developed using '''shared, documented methodology'''
 
# Are developed using '''shared, documented methodology'''
 
# Rely on generic '''computation and data standards''' wherever possible
 
# Rely on generic '''computation and data standards''' wherever possible
# Platform independence
 
'''Need an over arching schema''' (such as B. Blobel proposes) to bind these together in a functional fashion that will inform and guide
 
  
Notes:
+
==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
  
 +
==Notes==
 +
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 dicussion on the 1/16/2007 call. [[User:WoodyBeeler|WoodyBeeler]]
 +
===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).
  
I would add the reflection of the model driven architectural approach
+
In some weeks, I can distribute a more extended paper.
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
+
Extending the RUP can provide a good classification basis for our work.
well as the separation of computation-independent, platform-independent
 
and platform-specific aspects.
 
  
Also the Unified Process
+
===Second & third notes from Bernd Blobel===
 +
... Therefore, I'd like to make some comments regarding Woody's Core Architecture Features.
  
Even while security and privacy represent a special domain like others
+
I would add the reflection of the model driven architectural approach using the Zachman model as well as MDA or the RM-ODP classification.
(the term has been extended to the domain term used in HL7), the
+
 
importance of security and privacy services in the architectural
+
Interpretation of this approach can be found in the paper [http://www.hl7.org/documentcenter/public/wg/t3f/general/Blobel-schattauer_9_2006_4_343.pdf 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.
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===
 +
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 healthcare 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)?

Revision as of 19:07, 16 January 2007

HL7 will develop health care interoperability standards that:

  1. Derive from single Reference Information Model (RIM)
  2. Use common, defined terminologies
  3. Reuse models, following consistent patterns
  4. Address multiple implementation paradigms (document, messaging, services)
    • Platform independence
  5. Are developed using shared, documented methodology
  6. Rely on generic computation and data standards wherever possible

Actions from 20070116 Conference Call

  1. 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)
  2. Need an over arching schema (such as B. Blobel proposes) to bind these together in a functional fashion that will inform and guide

Notes

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 dicussion on the 1/16/2007 call. WoodyBeeler

First note From Bernd Blobel

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

... 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

On architecture - everything you wrote, I liked. Thought of other things that perhaps need to be folded in in some way - not sure.

  1. 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 : )
  2. Don't just say RIM, maybe also say RIM and Data Types.
  3. Standard terminologies. Do we really tell people what terminologies to use? This still seems fuzzy to me.
  4. Based on generic standards. Also done in collaboration and taking full advantage of companion standards in other areas.
  5. Do we need to say - designed to meet the needs of its membership, of the healthcare community - somehow say its user/needs driven or relevant?
  6. Do we need to say something about how its membership developed, consensus developed, balloted?
  7. 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)?