Download
1 / 22
220 likes | 316 Vues
Explore the caCIS Architecture and learn about Conformance Levels, Interoperability Specifications, and Behavioral Models. Conformance from Conceptual to Logical and beyond. Discover how organizations and vendors can adapt to achieve interoperability.
E N D
caCIS® Example Service: Allergy Value and Levels of Conformance
Inventory - Services • Allergy • Chemotherapy Management • Document Builder • Document Exchange • Family History • History & Physical • Immunization • Lab Result • Location Registry • Medication • Natural Language Processing • Order Request Management • Organization Registry • Patient Registry • Problem List • Provider Registry • Referral • Security • Authentication • Authorization • Identification • Anonymization • Consent Registry • Security and Privacy • Non-Repudiation • Federation • Social History • Terminology • Vital Signs
Inventory – Interoperability Specs • Referral • Document Builder – CDA • Document Exchange • Planned • Lab Order • Planned Medication Order • Planned Treatment Planning
Inventory – Enabling • Referral Management • Chemotherapy Management • Outcomes
Conformance: Systems, Services, Roles, Communities • Systems take on community roles by virtue of the interfaces they expose • Where roles and communities are pre-defined to provide value, this means that many legacy systems can be adapted to fit these requirements • Where roles and communities are NOT defined or insufficiently defined, these interfaces allow behavior to be defined and organized • Roles and communities have a many to many relationship • Service specifications define their own communities • Every consumer is the same • One system may expose multiple services • Interoperability specifications define communities that are important to achieve some goal beyond that of a single service
Conformance Levels • The caCIS Architecture defines the interoperability levels and the places where integration can happen • Organizations and vendors can build to that • Vendors are in the drivers seat in terms of managing this • Conformance is a touchstone against which we measure everything else • Where a vendor or organization controls all parts of a system, conformance can be made mandatory or ignored • The more likely scenario is where there are multiple systems, organizational boundaries, trading partners, etc. • Our architecture allows trading partners to variably conform • May mean using an adapter strategy to achieve interoperability
Conformance: Conceptual Specifications • Conceptual specifications provide a binding point between real or implied business analysis and a solution • Follows the ODP viewpoints (Enterprise, Information, Computational, Engineering) • Conformance to a conceptual specification is a starting point • Not enough for inter-organizational (or inter-system) interoperability usually • Instead, defines an endpoint, and allows classification of behavior and information
Conformance: Logical Specifications • Logical specifications begin to be more implementable by themselves • They exhibit some of the design decisions that NCI has made (HL7 V3, 21090) • They exhibit design decisions that the architectural team has made (MEPs, parameter decomposition, granularity decisions, service composition) • Serve as a solid foundation to implementation • Logical specifications may include • Multiple information types (Allergy List, Concern, and Negation) • Strict bindings to datatype localizations (21090) • Bindings to contract patterns (response envelopes, exception handling)
Conformance: Logical Specifications - WSDL • The WSDL reflects the architectural, design, and messaging patterns that we are using
Conformance: Logical Specifications – Meaningful Use • If you are looking for specs supporting meaningful use, some Logical Specifications begin to lay out what needs to be adopted to support Meaningful Use Criteria
Conformance: Interoperability Specifications • It is one thing to think of an architecture as a set of reusable components (services). It is another to think about putting these together into solutions • Interoperability specifications • Provide solution sets composed of existing components (services) • Conformance statements including • Conformance levels of dependent services • Choreography and shared state • Binding complex community contracts (including roles and responsibilities) to technical solutions
Architecture - Other • There are other pieces of the architecture, design, and development that are worth noting …. • RIM-based db • Exception Handling • Contract Binding • Choreography engines + Configurations • Document Exchange • Virtual E H R Scaffold • ISO 21090 localized data type specification • Service and Information Specifications, patterns and practices • HL7 + SOA • Identification • RLUS • Orders • Document Management
Summary: Architecture And Value • We are defining levels of interoperability between systems • Providing integration points that enable interoperability • Groups must build up to those • This is a central tenet of our architecture … these points of interoperability allow for great extensibility and future usage • Vendors can pick their efficiencies, components, and differentiating factors • Barriers to entry are pretty low • It is a chance to build communities of systems that reduce the barriers to provision of care • This can be based on a vendor model while still being pluggable to NCI’s core architecture
