20080820 ARB Jump Start
Architecture Board
20080820 August out-of-cycle Day 2
Wednesday 0800 - 1200
Attendance
?? Depicts those expected who have not appeared.
| Name | Role | Affiliation | |
| Curry, Jane | ArB | Health Information Strategies | janecurry@healthinfostrategies.com |
| DeJong, Alex | Guest | Siemens | alex.dejong@siemens.com |
| Julian, Tony | ArB | Mayo Clinic | ajulian@mayo.edu |
| Killian, Greg | Guest | Siemens | greg.killian@siemens.com |
| Koisch, John | ArB | NCI | koisch_john@bah.com |
| Larsen, Ed | Guest | HITSP | erlarsen@ix.netcom.com |
| Lynch, Cecil | ArB | ontoreason LLC | clynch@ontoreason.com |
| Mead, Charlie | ArB | Booz Allen Hamilton | charlie.mead@booz.com |
| Mulrooney, Galen ??? | Guest | VHA | galen.mulrooney@med.va.gov |
| Orvis, Nancy | ArB | DOD | nancy.orvis@tma.osd.mil |
| Parker, Ron | ArB | CA Infoway | rparker@eastlink.ca |
| Quinn, John | ArB | Health Level Seven, Inc. | jquinn@HL7.org |
| Rogers, Rich | Guest | IBM | rrogers@us.ibm.com |
| Shakir, Abdul-Malik | ArB | Shakir Consulting | ShakirConsulting@cs.com |
| Williams, Laurie | Guest | Siemens/td> | laurie.williams@siemens.com |
| Wrightson, Ann | Guest | NHS(IHC) | ann.wrightson@wales.nhs.uk |
| Yongjian, Bao | ArB | GE Healthcare | yongjian.bao@med.ge.com |
0800-1200
Siemens Presentation(30 minutes)
Alex DeJong from Siemens presented their vision for SOA. This presentation included a review of the basics of SOA.
It includes services, messages, and events. Nancy is trying to push standardized methodologies. Question/Action:
- ? Has Siemens considered mapping the care functions to the EHR-S
- We will need to publish the 'how to' for infrastructure contracts. Ed Larsen will provide an example of DIRSA agreement.
- We should produce design heuristics for the level of granularity required.
Alex presented a list of questions:
- What can we do to make it simpler to absorb and productively the standards?
- Message-, document- and/or service based
- Should document have actions associated with them beyond storage? If so, how is this different from a message?
- The place of an "Event" in SOA.
- How is an event a message, how does it differ?
- Rich vs 'light' events
- Examples of SOA vs messages
- exception handling and other cross-cutting concerns such as security, vocabulary/terminology, history, versioning, etc?
- How do the HL7 SOA workgroup and ArB SOA efforst align and/or compliment each other?
Dynamic Framework (45 minutes)
Taxonomy of Services (3 hours)
Why a taxonomy?
- What kinds of things?
- What are the inter-relationships?
- Ontology of relationships
| Category | Atomic | State change | |
| Capability | T | T | |
| Core | T | F | |
| Process | F | F |
Taxonomy:
- simple hierachy, e.g. race/ethnicity
- classification faced on one facet
- not an assembly
thesaurus has relationships
There is an OWL ontology in the Federal Health Architecture for services. (See formal definitions slide "New Data Reference model 2.0)
What facets are usefull?
EARL classification system.
Discussion
Harmonization
Wednesday 1300 - 1700
Pm Discussions
AMS wants the HL7 SOA metamodel to describe all of the artifacts to describe services, described in UML and RM-ODP.
Input from XA, DOD, NCI, UPMS will be used to determine what UML needs to have added, or constrainted? Drive off of UML to have tools to enable the SOA.
We can use a subset of RM-ODP meta-model.
HL7 ARB is not the only interested party. SOA-Pro group submitted an RFP to OMG. The work product will be in 'final submission' stage on August 25, 2008. This is the OMG Software Services Profile and Metamodel RFP, which attempts to describe the serviced metamodel. Created by convergence between SOA-Pro and UPMS.
AMS moved the meta-model into EA. He then asked a number of questions. Jim joined by phone
Agent in the profile will be expanded by an RFP called AMP. The Service Interface extends either Class or Interface.
Property may have isID - which allows us to say this property/collection is sufficient to uniquely identify instances of the container. There is no distinction of the primary identifier.
A signal may be associated with a milestone, signal types the milestone. You could use this runtime to notify the runtime environment when the milestone is reached. Statically the signal information may be looked at for the ability of the service to reach certain milestones. The higher the ordinal number is more significant than a lower number - it is a weight.
Collaboration is strict, and service contract is a type of collaboration.
Collaboration is used to formalize a set of requirements, same as use cases, but with greater formalization, providing finer grain traceability.
ServiceContract: The roles have to be typed by service-interfaces(There are constraints that are not in the diagram). A collaboration is an interesting question of what it means to use a type on a role in a collaberation - what can it do. The connectors between the roles and collaboration define the use within a particular context. If you type a role in a collaboration with a type you are constraining the type regardless of its use within any collaberation that contains it. So, since it wasnt clear in UML which way to view collaberations, most people would not agree that that is the expected behaviour, the ServiceContract specifically provides that behaviour.
The next revised submission will be published to OMG in the next couple of weeks.
ServiceContract/Service interface: Specify in advance what all of the requirements are.
Another view is "I have a set of capabilities that I want to sell from my point of view" - No contract is involved, so all of the capability would be provided in the serviceInterface - no serviceContract is needed.
Suppose I have something I want to do, and I need the following things, which I specify in a formal way, specifying a serviceInterface with all my needs. The serviceInteface defining the service, and the serviceInterface defining the request may be separate, but to work together they must be fully compatibility.
In UML you can put things in packages. You can use it for any purpose that relies on something in a package). Package import and element import are available. However, there are many ways to organize things, in many orthogonal ways at the same time. OMG: RAS (reusable asset spec) has classification schemas to allow classification. Classifications may include architecture layer, etc. A simple solution is to include a Catalog: Organizes things in any manner desired. Catalog has categories. Applying a category to any element in the model adds it to the catalog. Are categories exclusive or inclusive? Catalogs can contain other catalogs, which can contain many categories: Distribution, Architecture Layer etc.
What about 11179 ISO registry? A catalog defines what goes in the 11179 registry.
Specifications
Blueprint layer
- DAM- Domain Analysis Model (represented as a set of views) includes Dynamic aka Business Context
- Should include
- Use cases
- Activity diagrams
- Should include
- DIM - Domain Information Model replaces DIM in original diagram.
- Business Context
- Business Drivers
- Motivations
- Intended usage
- EHR-S-Functional Profile
- Reference Context - Traceabilityh to HL7 Reference
- Functional Profile (AKA Computational Profiles) is an HSSP generic term that defines certain requirements (Grouping of Services Operations)
- Directly supports the use cases
- Includes a useful collection of functions
- Dynamic Blueprint - Functional Decomposition
- Semantic profile is really Semantic binding of Dynamic Blueprint to Functional Decomposition
Platform Independent layer
- CIM Constrained Information Model
- LIM Localized Information Model
- Choreography: Define sequences and interactions - Independent View -
- what could happen,
- what can happen,
- what can not happen
- Interface Design Specifications - IDL, model, or some way layout all of the operations, profiles, using classes from CIM and LIM.
- Rules, Focus, Purpose - constraint of the business context (Business Governance>?).
- Policies
- User roles
- Consent
- Relationships
- Timing
- Sequencing
Platform Binding Layer
- Transforms
- Schemas
- Interface design, e.g. WSDL, dotNET
- Orchestration: Higher degree of complexity - Bind the choreographies to services
- Instances that impact the coordination
- Execution context
- Deployment characteristics
- Interface Realizations
OHT Modeling project for HL7 - Lessons Learned (Rogers) (60 minutes)
Moved to Tuesday after lunch
