100 likes | 304 Views
caCIS Enterprise Architecture Specification. Contents and Publication. Definition and Scope (1). The caCIS Architecture activities do NOT produce and Enterprise Architecture Specification We do not have a Business Model We do not define roles and responsibilities
E N D
caCIS Enterprise Architecture Specification Contents and Publication
Definition and Scope (1) • The caCIS Architecture activities do NOT produce and Enterprise Architecture Specification • We do not have a Business Model • We do not define roles and responsibilities • We do not control the enterprise • We do not handle governance • We do not control publishing and consumption • We do not control implementation • System Architectures
Definition and Scope (2) • The caCIS Architecture activities DOES produce • Interoperability components • Intersections with Integration and Interoperability Standards (W3C, HL7, Snomed, LOINC, CDL, etc) • Best Practices, Local Practices • Architectural Patterns that are related to Contract Driven Development
Essential Elements • Interoperability Specifications • Service Specifications • Best Practices • Standards • Tooling • Communications between workstreams • Patterns • Integration • Interface • Interoperability • Business Realization • CIM – to – CFSS – to - PIM – to - PSM
Outline Notes • Outlines are linear, and we should realize that the way that we want to publish is not linear • Hyperlinks between deep, nested structures, for example • We don’t want to get hung up on the difference between patterns and best practices, for example
Outline • Best Practices / Patterns • Contract-driven implementation guidance (SAD Constraints) • WSDL, WADL, and Profiling • Persistence • Document Management (CDA) • RIM Structures • Datatypes, Localizations, and Computational Libraries • Deployment Guidance and Patterns • QRL and Query Rules • Semantic Resolution • Vocabulary / Terminology • Management Interfaces • Proxies and Brokering • Registries, Individual Resolution, and Notification • Ontology / Language of Interoperability • Integration Guidance • V2 / V3 • Translation / Transformation • Vocabulary / Terminology • Identity Management • Interoperability Specifications • Service Interfaces • Interoperability • Business-bound interoperability Patterns • Infrastructure • Technical Interoperability Patterns • Conformance Levels and Guidance • Core Specifications • Interoperability Patterns and Contract Semantics • Registry Resolution • Proxies and Brokering • Security • Interoperable Patterns (OO, etc) • Management Structures • Interface Patterns • QRL • EIS • Decomposition Guidance • Taxonomies • Proxies and Brokering • Run Time Bindings • Response Envelopes • Error and Exception Management • Behavioral Vocabulary • Tooling and Methodology • Computational Languages • Information Languages • RIM Semantics, Structural Vocabulary • Engineering Languages
Method (1) • ?????
Method (2) • ?????
Publication Requirements • Different groups need to see the same information in different ways • The Specification should be published so that pieces can be annotated with different context • For example: createPatient(_patient:patientCMET)::patientID:II Tags: Interface Operation, Identity Best Practices, Security Boundaries, ISO 21090 Datatypes, RIM Structures, Contract Semantics (Provenance, Jurisdiction, Authority Boundaries)
Questions • What do we deliver? • What can we give to IM to publish? • Do we have a sufficient ontology to move forward? (slide 6)