Possible Opportunities for Integrating a

1
Possible Opportunities for Integrating a
Registry Service in a Distributed Object
Environment
2
Objectives

• Consider ways to use the value inherent in
  registry information as more than just a static
  reference.
• In particular are their ways to make a registry
  act as information resource that helps resolve
  architectural mismatch and semantic conflict in
  the day-to-day operation within a distributed
  object architecture?
• Also, can we build a capability to use the
  registry for automated or semi-automated
  maintenance of system interface definitions?

3
The CPR Interoperability using Object Oriented
Technology (CIOOT) Initiative
4
Background - Threat

• Loss of competitive advantage via inefficient
  information management
• Contingency support environment
• Managed care environment
• Paper records break the medical informatics loop
• Compromise of security, privacy, confidentiality

5
Background - The Medical Informatics Loop
6
The Main Problem
Manage
Paper records can break the loop
Assess
De liver
Therefore....
7
The CPR Advantage
Manage
CPR
Assess
Deliver
Information must be captured in digital form at
the point of service for reuse near real time
throughout the process at multiple levels.
8
Background - Situation

• Automated Information Systems (AIS) Crisis
• Stovepipes
• Maintenance costs
• Slow to develop and change
• User dissatisfaction
• Parallels AIS crisis in industry where
  traditional approaches maintained
• Multiple stakeholders, operational settings,
  legacy systems, functional activities

9
Background - Mission

• CHCS II Program Office
• Via the CPR, provide MHS decision makers with the
  integrated information resources necessary to
  optimize health service in managed care and
  contingency support environments
• CIOOT
• Provide CBA with a viable technical alternative
  toward the development of the interoperability
  infrastructure for CHCS II and its CPR

10
Strategy - Operational Concept
Master Patient Index
Object Interface
Object Interface
Object Wrapper
COTS 1
LEGACY 1
Clinical Data Repository
Terminology Services
Object Wrapper
LEGACY 2
11
Strategy - Target Architecture CHCS II, v 2.0
ATM and DISN Nets
ORB/ DCOM
Object Interface
NNMC CIS
ORB/ DCOM
ESI Wrapper
MGMC CHCS
Object Interface
CEIS
MGMC CIS
MGMC DDSS
ESI Wrapper
ORB/ DCOM
ESI Wrapper
WRAMC CHCS
WRAMC DDSS
NNMC DDSS
Object Interface
WRAMC CIS
Service
Object Interface
Resource broker
New DEERS
Intelligent agent
Application or applet
Data store
12
Accomplishments to Date

• Architecture taking shape per C4ISR Framework 2.0
• Industry OO methods tailored to DoD objectives
  leverage legacy systems
• Detailed collaborative process established
  working
• Key tools acquired being integrated for total
  life cycle RT
• Growing/attracting trained workers
• Networked with industry OOT community
• Best industry practices implemented - SEI CMM
• Successful proof of concept demo

13
Risks / Challenges

• Magnitude of complexity
• Resistance to paradigm change waterfall mindset
  / formats
• External dependencies Lexicon, CRDB burned
  before
• Affordable, experienced staff, esp. technical
  dedication to longer view
• CHCS software development coordination

14
Magnitude of Complexity

• Multiple heterogeneous systems
• Customization even within like systems
• Differing requirements
• Aid station vs. clinics vs. hospitals vs.
  teaching hospitals
• Stateside vs. overseas vs. forward deployed
• Peacetime vs. war scenario
• Managed care with differing regional contractors
• Each item of complexity adds to the likelihood of
  semantic and architectural mismatches that will
  need resolution

15
A Taxonomy of Possible Conflicts

• Identity - Same concept represented by different
  objects in different local databases
• Schema
• Naming - Homonyms and synonyms
• Structural - Concepts represented by different
  constructs (a method in one database and a class
  in another) or same construct used but with
  different structure (methods and/or parameters)
• Semantic - Same concept interpreted differently
  in different databases
• Data - Data Values of the same entity are
  different in different databases

From Evaggelia Pitoura, Omran Bukhres, and
Ahmed Elmagarmid, Object Orientation in
Multidatabase Systems, ACM Computing Surveys,
Vol.27, no. 2, June 1995.
16
Manage Interface Mismatches

• Initial Interfaces design IAW known Business
  Rules
• Errors are caused by
• Design errors
• Errors induced during maintenance or incremental
  development
• Goals
• Define dynamic interfaces that monitor
  maintenance and adjust for it using ontological
  services.
• Define exception interfaces that process
  exceptions through ontological/lexical
  services.
• Al least identify where and why a interface error
  occurred.

17
Manage Ontological Implementations

• Serve as a pointer from to/from
  lexicons/ontologies to those terms which are
  actually in use
• Identify registered concepts not covered in the
  lexical/ontological engines as gaps in coverage.
• Serve as persistent storage for an Meta Object
  Facility (MOF) implementation (Note The CORBA
  MOF appears to have no notion of stewardship
  other than the concept of name space)
• Translate from legacy to standard at interface
  nodes by automated distribution from the central
  registry

18
Serve as an On Line Reference for Relevant CORBA
Services

• Naming Service - it is the responsibility of the
  higher-level software to administer the name
  space. (CORBAServices)
• Relationship Service?
• Query Service - as a synonym finder?
• CORBAmed Lexical Service?
• CORBAmed Person Identification Service?

19
Set Scope for Modeling

• Enter only concepts that are in use and required
  by the enterprise (i. e., have stewards
  responsible for their maintenance) into an
  information model.
• Reduces the chance that relationships that are
  not tied to required functionality enter an
  enterprise model.
• Reduces the likelihood of shelfware models.
• Allows for modeling the standards rather than
  standardizing the models.

20
Final Thoughts

• Registries are there to publicize defined
  standards.
• Hopefully the good stuff wins and the bad stuff
  loses.
• Even when the second best wins, we gain from
  the network effect of enhanced reuse.
• Only when standards are imposed unilaterally,
  without recourse, are really bad things likely to
  happen.
• The blessing of the registry is that it allows
  for standards to be marketed. What works will be
  chosen. On-line use will work the same way.
• But then you all know that. So, Im just
  preaching to the choir.