Difference between revisions of "Six Core Architecture Features"

From HL7 TSC
Jump to navigation Jump to search
 
Line 3: Line 3:
 
#'''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 - 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 to say something about how its membership developed, consensus developed, balloted?
#'''Here''' we need Something about quality, readability, usability, completeness?
+
#'''Here''' we need Something about quality, usability, scalability, portability, and towards completeness?
  
 
=Features of HL7 Technical Architecture=
 
=Features of HL7 Technical Architecture=

Latest revision as of 17:20, 24 January 2007

Underlying Principles of HL7 Technical Architecture

HL7 develops health care interoperability standards that, according to its mission, are:

  1. 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?
  2. Here we need to say something about how its membership developed, consensus developed, balloted?
  3. 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:

  1. Derive from single Reference Information Model and Data Types Specification (RIM)
  2. Explicitly bind coded data to defined concept domains and terminologies
  3. Reuse static and dynamic models, following consistent patterns
  4. Address multiple implementation paradigms (document, messaging, services) designed to be independent of the implementation platform
  5. Are developed using shared, documented methodology
  6. 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

  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

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.

  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 health care 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)? 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.