This wiki has undergone a migration to Confluence found Here
Difference between revisions of "SAEAFDrivers"
Jump to navigation
Jump to search
m |
m |
||
Line 1: | Line 1: | ||
===Drivers(Goals, customer needs, Performance measurements)=== | ===Drivers(Goals, customer needs, Performance measurements)=== | ||
− | [[Services_Aware_Enterprise_Architecture_Framework|Return to Table of Contents]] | + | [[Services_Aware_Enterprise_Architecture_Framework|Return to SAEAF Table of Contents]] |
The goal of this framework is to provide a business architecture that will enable the working groups to create content that will support the entire range of formats required by the user community, including messages, services(SOA), and Clinical Documents(CDA). | The goal of this framework is to provide a business architecture that will enable the working groups to create content that will support the entire range of formats required by the user community, including messages, services(SOA), and Clinical Documents(CDA). |
Latest revision as of 18:30, 6 August 2008
Drivers(Goals, customer needs, Performance measurements)
Return to SAEAF Table of Contents
The goal of this framework is to provide a business architecture that will enable the working groups to create content that will support the entire range of formats required by the user community, including messages, services(SOA), and Clinical Documents(CDA).
Customers have varying needs to communicate within the format set listed below
- Messages: Messages make sense for those use cases where an ancillary system, such as Laboratory, is used to push data to one or many repositories.
- Version 3(V3) The richness of HL7 Version 3 messaging makes it a prime choice for new development in messaging.
- Version 2.x(V2) - Vertical Bar Implementations(VBAR aka ER7) will continue to be used by mature (legacy) systems will for some years to come. Vendors to date have not been eager to adopt the V3 standards because there is no return on investment to do so.
- Services(SOA) While the SOA community touts services as the ONLY way to go, there are those in the community who understand that there are cases where SOA is not advised. Changing developement to SOA involves refining business needs to IT requirements, and then IT requirements to IT capabilities in order to identify technology to address the needs.[When_and when not to persue SOA]
- Clinical Documents(CDA): CDA will continue to be the format of choice for CCR and other document paradigms. Since CDA defines a payload, and not a transmision infrastructure, CDA documents can be shared by any of the above.
Tony 17:44, 6 August 2008 (UTC)