Download
1 / 22
220 likes | 302 Views
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
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
