This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Talk:EA IP"

From HL7Wiki
Jump to navigation Jump to search
(Replacing page with 'Moved content to Talk:EA_IP_Phase1_(alpha_project_approach)')
(notes from pre-WGM discussions leading up to re-definition of the Implementation Program)
Line 1: Line 1:
 
Moved content to [[Talk:EA_IP_Phase1_%28alpha_project_approach%29]]
 
Moved content to [[Talk:EA_IP_Phase1_%28alpha_project_approach%29]]
 +
 +
 +
*Define interrelationship between terms using SKMT glossary?  Include SAIF Glossary in HL7 Glossary, and format V3 Glossary for use by SKMT?
 +
*Define suite of artifacts using the OHT Shared Artifact Repository give us some leverage in retrieving items from “the bag”?  Tooling Solution vision to be presented 2010Oct WGM proposes leveraging OHT Static Model Designer, Terminology Manager, Behavioral Model Designer, Shared Artifact Repository, and Specification Publication Manager.  HL7 to participate in the enhancements in a project with OMG and IHTSDO, not yet developed.
 +
*Question: What role does the Templates Registry play?
 +
**Artifact types currently identified: Content Domains, Infrastructure Domains, CMETs, Payload Message Types, Interactions, Trigger Events, Application Roles, Story Boards, and more interdependent artifacts each year.  How to define DAM, DIM, SIM, etc. by CIM/PIM/PSM terms?
 +
 +
*from Lloyd McKenzie: we have not enough guidance or structure in place for projects to go very far.  When v3 first got off the ground, there was a bit of high level thinking about what kinds of artifacts we needed, the content of those artifacts got fleshed out, we built some tools to author those artifacts, and projects started using the tools.  Based on feedback from the users of the tools as well as seeing what we liked and didn't like about the artifacts, the tools and methodology evolved.  I think we need to do something similar here.  We need to nail down things like "what are the specific artifacts in a behavioral model?  What attributes do they have?  How do they inter-relate?  How are they best maintained?  What does an interface contract look like?"  and "What elements are allowed in a DAM?  What's required?  What sort of mapping is required between a DAM and a committee's DIMs or SIMs and how is that maintained?" and "What changes do we make in capturing requirements?  How are they validated?  How do we maintain traceability of those requirements?".  None of these questions are answered in the current drafts of the frameworks and they're not the sort of questions that are easily tackled by a project (or group of projects) whose primary focus is producing a given standard under a tight timeline.
 +
 +
*Lloyd writes: what's really needed is a project to produce a first attempt at a detailed methodology and set of tools that can then be exercised by a small number of test projects so they can be refactored and evolved to something ready to meet scrutiny by the wider membership.
 +
 +
 +
Example: The SAIF references the MDA (OMG's Model Driven Architecture) model suite consisting of CIM, PIM (Platform Independent Model) and PSM (Platform Specific Model). Within HL7 the term CIM as ‘Constrained Information Model’ has been deprecated and replaced by SIM (Serializable Information Model). So it's DAM-DIM-SIM nowadays in the HDF. A SIM conceptually is a PIM.
 +
 +
 +
Examples External to HL7: NCI SAIF Implementation Guide at https://wiki.nci.nih.gov/display/CBIITtech/caGrid+2.0+Roadmap+Documents
 +
 +
 +
Assumptions from EA IP:
 +
*The responsibility to develop a full HL7 EAS rests with the HL7 Architecture Board (ArB); the ArB will use the SAIF as a baseline.
 +
*Interdependencies between the development of the SAIF and the work to develop / refine the EAS will need to be assessed and applicable processes devised to ensure, among other things,
 +
*Conceptual alignment (e.g. Consistent use of concepts / terms, artifacts, etc.);
 +
*Appropriate flow of requirements for tooling and processes and other knowledge from SAIF to EAS work.
 +
*EAS development will require collaboration with real integration projects (“Alpha Projects”) that are willing and able to tackle the development of artifacts covering multiple EAS layers / facets:
 +
*Alpha Projects are ready to engage in short order;
 +
**The sponsoring agencies are thought to be interested in taking the full range of artifacts through a balloting process;
 +
**The HL7 SAIF IP will be accountable as the primary coordination point between “Alpha Projects” and HL7 - primarily addressing issue management.

Revision as of 20:21, 11 October 2010

Moved content to Talk:EA_IP_Phase1_(alpha_project_approach)


  • Define interrelationship between terms using SKMT glossary? Include SAIF Glossary in HL7 Glossary, and format V3 Glossary for use by SKMT?
  • Define suite of artifacts using the OHT Shared Artifact Repository give us some leverage in retrieving items from “the bag”? Tooling Solution vision to be presented 2010Oct WGM proposes leveraging OHT Static Model Designer, Terminology Manager, Behavioral Model Designer, Shared Artifact Repository, and Specification Publication Manager. HL7 to participate in the enhancements in a project with OMG and IHTSDO, not yet developed.
  • Question: What role does the Templates Registry play?
    • Artifact types currently identified: Content Domains, Infrastructure Domains, CMETs, Payload Message Types, Interactions, Trigger Events, Application Roles, Story Boards, and more interdependent artifacts each year. How to define DAM, DIM, SIM, etc. by CIM/PIM/PSM terms?
  • from Lloyd McKenzie: we have not enough guidance or structure in place for projects to go very far. When v3 first got off the ground, there was a bit of high level thinking about what kinds of artifacts we needed, the content of those artifacts got fleshed out, we built some tools to author those artifacts, and projects started using the tools. Based on feedback from the users of the tools as well as seeing what we liked and didn't like about the artifacts, the tools and methodology evolved. I think we need to do something similar here. We need to nail down things like "what are the specific artifacts in a behavioral model? What attributes do they have? How do they inter-relate? How are they best maintained? What does an interface contract look like?" and "What elements are allowed in a DAM? What's required? What sort of mapping is required between a DAM and a committee's DIMs or SIMs and how is that maintained?" and "What changes do we make in capturing requirements? How are they validated? How do we maintain traceability of those requirements?". None of these questions are answered in the current drafts of the frameworks and they're not the sort of questions that are easily tackled by a project (or group of projects) whose primary focus is producing a given standard under a tight timeline.
  • Lloyd writes: what's really needed is a project to produce a first attempt at a detailed methodology and set of tools that can then be exercised by a small number of test projects so they can be refactored and evolved to something ready to meet scrutiny by the wider membership.


Example: The SAIF references the MDA (OMG's Model Driven Architecture) model suite consisting of CIM, PIM (Platform Independent Model) and PSM (Platform Specific Model). Within HL7 the term CIM as ‘Constrained Information Model’ has been deprecated and replaced by SIM (Serializable Information Model). So it's DAM-DIM-SIM nowadays in the HDF. A SIM conceptually is a PIM.


Examples External to HL7: NCI SAIF Implementation Guide at https://wiki.nci.nih.gov/display/CBIITtech/caGrid+2.0+Roadmap+Documents


Assumptions from EA IP:

  • The responsibility to develop a full HL7 EAS rests with the HL7 Architecture Board (ArB); the ArB will use the SAIF as a baseline.
  • Interdependencies between the development of the SAIF and the work to develop / refine the EAS will need to be assessed and applicable processes devised to ensure, among other things,
  • Conceptual alignment (e.g. Consistent use of concepts / terms, artifacts, etc.);
  • Appropriate flow of requirements for tooling and processes and other knowledge from SAIF to EAS work.
  • EAS development will require collaboration with real integration projects (“Alpha Projects”) that are willing and able to tackle the development of artifacts covering multiple EAS layers / facets:
  • Alpha Projects are ready to engage in short order;
    • The sponsoring agencies are thought to be interested in taking the full range of artifacts through a balloting process;
    • The HL7 SAIF IP will be accountable as the primary coordination point between “Alpha Projects” and HL7 - primarily addressing issue management.