OMG CORBAmed Roadmap – Version 2.0 (draft)
Object Management Group
250 First Avenue, Suite 201
Needham, MA 02494, USA
Telephone: +1-781 444 0404
Facsimile: +1-781 444 0320
The CORBAmed
Roadmap
CORBAmed: The OMG Healthcare Domain
Task Force
OMG Document Number CORBAmed/2000-05-01
http://www.omg.org/docs/corbamed/2000-05-01.doc
Version 2.0 (draft)
21 May 2000
1 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
Revision History & Document Evolution Planning
Version
0.1
1.0
1.0a
1.0b
2.0
Release Date
November 8,
1998
December 14,
1998
December 18,
1998
Washington DC
Meeting,
January 13,
1999
Post Denver
Meeting, March
2000
Description
Reviewed by Roadmap Working Group prior to
Burlingame Technical Meeting.
Updated CHST to version 3.0.
Incorporate changes suggested by Erick
Hagstrom
To be voted by CORBAmed plenary to be an
official document
Replaced CHST with the CORBAmed Servicebased Architecture for Healthcare, updated lists
of adopted technologies and technologies
undergoing adoption. Also general editing and
improvement.
2 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
Table of Contents
1
Executive Summary..................................................................................... 5
2
Introduction .................................................................................................. 8
2.1
2.2
2.3
2.4
2.5
3
Business Case ........................................................................................... 10
3.1
3.2
3.3
3.4
4
CORBAmed Roadmap Charter .................................................................. 8
Intended Audience ..................................................................................... 8
Purpose of the CORBAmed Roadmap ....................................................... 9
Liaison Activity ........................................................................................... 9
Domain Architecture ................................................................................... 9
The State of Healthcare Informatics ......................................................... 10
The Distributed Object World in Healthcare ............................................. 11
Breadth of Applicability ............................................................................. 14
Return on Investment of using CORBAmed. ............................................ 14
Adopted Specifications and Specification Development (RFPs) .......... 15
4.1 Introduction .............................................................................................. 15
4.2 Specific Work Items ................................................................................. 15
4.3 Deliverables ............................................................................................. 15
4.4 OMG/CORBAmed Specifications Scorecard............................................ 16
4.5 Adopted Specifications ............................................................................. 17
4.5.1 Person Identification Service (PIDS) ................................................. 17
4.5.2 Terminology Query Services (TQS) .................................................. 18
4.5.3 Healthcare Resource Access Decision (RAD) .................................. 19
4.5.4 Clinical Observations Access Service (COAS) ................................. 20
4.5.5 Clinical Image Access Service (CIAS) .............................................. 20
4.6 Current Work Items .................................................................................. 22
4.6.1 Healthcare Information Locator Service (HILS) RFP ........................ 22
4.6.2 Summary List Information Management (SLiMS) RFP ..................... 22
4.6.3 Medical Transcription Document Management (MTM) RFP ............. 22
4.6.4 Healthcare Data Interpretation Facility (HDIF) RFP .......................... 23
5
Requirements Elaboration (Requests for Information - RFIs) ............... 24
5.1 Introduction .............................................................................................. 24
5.2 Specific Work Items ................................................................................. 24
5.3 Deliverables ............................................................................................. 24
5.4 Past Work Items ....................................................................................... 25
5.4.1 The CORBAmed RFI ........................................................................ 25
5.4.2 CORBA and HL7 - Approaches and Considerations RFI .................. 26
5.4.3 Lifesciences RFI ............................................................................... 27
5.4.4 CORBA/M Interoperability RFI .......................................................... 28
5.4.5 Healthcare, Administrative, Logistical and Financial Encounter
Management RFI (HALFEM) ....................................................................... 29
6 CORBAmed Service-based Reference Architecture for Healthcare
(SeRAH) ............................................................................................................. 31
3 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
6.1 Introduction .............................................................................................. 31
6.2 Charter for SeRAH ................................................................................... 31
6.3 Structure of SeRAH .................................................................................. 31
6.4 The CORBAmed Service-based Architecture for Healthcare (SeRAH) .... 33
6.4.1 SeRAH Part1: The CORBAmed Applications Template.................... 33
6.4.1.1
6.4.1.2
6.4.1.3
6.4.1.4
Provider View – Direct Service Provision ..........................................................................33
Clinical Systems Developer’s View ...................................................................................34
Provider View – Billing .......................................................................................................35
Payer View ........................................................................................................................35
6.4.2 SeRAH Part2: The Reference Architecture ....................................... 36
7
OMG Support ............................................................................................. 47
7.1 Introduction .............................................................................................. 47
7.2 Specific Work Items ................................................................................. 47
7.3 Deliverables ............................................................................................. 47
8
OMG Policy and Procedure....................................................................... 48
8.1 Explanation of the OMG RFI Process ...................................................... 48
8.2 Explanation of the OMG RFP Process ..................................................... 49
8.2.1 Submissions ...................................................................................... 49
8.2.2 Revised Submissions ........................................................................ 49
8.2.3 Specification Selection ...................................................................... 49
8.3 Explanation of the OMG RFC Process ..................................................... 51
9
Appendices ................................................................................................ 53
9.1
9.2
9.3
9.4
9.5
9.6
Appendix A: Healthcare DTF Three-Year Plan ........................................ 53
Appendix B: Acronyms and Abbreviations ............................................... 55
Appendix C: References .......................................................................... 56
Appendix D: Contacts .............................................................................. 57
Appendix E: CORBAmed Mission and Goals ........................................... 58
Appendix F – OMG Background .............................................................. 60
4 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
1
Executive Summary
Health care providers across the world are finding that the issue of
interoperability between heterogeneous information systems is adversely
impacting their delivery of health care. Information systems that do not
interoperate fail to provide information to address business needs. Inefficiencies
in information management can effect organisations in many ways. For instance:










Are you capturing encounter data at the point of service in an electronic form?
Can electronic data captured in one clinical service by used by another?
Can your information systems provide timely good quality information for
clinical decision support?
Can your information systems provide timely good quality information for
managerial decision support?
Can your clinical system interoperate with your financial systems?
Do your computer systems allow for shared care between multiple caregivers
within and across organisations?
Can you communicate with external organisations, for example government
agencies?
Do you have adequate information to support appropriate disease or medical
management?
Are your maintenance and interfacing costs shrinking?
Do you have flexibility, not locked in into current information systems and
applications?
If the answer is NO to any of these, you have an interoperability problem!
Here are the Information Management/Information Technology "facts of life" you
should be aware of:






There will not be consensus on hardware platforms
There will not be consensus on operating systems
There will not be consensus on programming languages
There will not be consensus on graphical user interfaces
There will not be consensus on domain boundaries
There will not even be consensus on data standards
Therefore, there MUST be consensus on a COMMON INTERFACE
ARCHITECTURE.
A common interface architecture consensus is now emerging on a global scale.
Solutions to interoperability challenges, are being defined and adopted by
International Standard Organisations. SOLUTIONS ARE BEING BUILT INTO
INFORMATION SYSTEMS TODAY!
5 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
The Object Management Group (OMG) is an international standards organisation
that develops technically excellent, commercially viable and vendor independent
specifications for the software industry.
The OMG has reached international consensus on a common interface
architecture, named the Common Object Request Broker Architecture (CORBA).
Starting in the OMG, consensus has been achieved to accomplish a number of
ISO (International Standards Organisation) standards. In addition, OMG and
CORBAmed has functional liaisons with various standards organisations, from
ISO to the W3C, including healthcare specific groups such as DICOM, HL7,
NCPDP and X12.
CORBAmed is the OMG's Domain Task Force on Healthcare with the mission to:




Improve the quality of care and reduce costs by use of CORBA technologies
for interoperability throughout the global healthcare community.
CORBAmed defines standardised object-oriented interfaces between
healthcare related services and functions.
These interfaces serve to promote interoperability between a variety of
platforms, operating systems, languages and applications.
Utilise the OMG standardisation process.
Thank you for your interest in CORBAmed the Object Management Group's
Domain Task Force on Healthcare. We hope you will find relevant interoperability
solutions for healthcare in the CORBAmed Roadmap and associated Toolkit
CORBAmed 1.0. We look forward to your participation in CORBAmed. Allow the
OMG to serve as your resource for healthcare interoperability standards. We
hope that you will find the CORBAmed Roadmap and associated CORBAmed
Toolkit (version 1.0) enjoyable and effective.
Included in the CORBAmed Roadmap is an introduction to CORBAmed and the
business case highlighting the importance of distributed object computing in
healthcare:



Requirements Elaboration are activities which increase the Task Force's
level of awareness for contemporary industry requirements. The OMG
standardisation process includes issuance of a Request for Information (RFI)
and attendant response evaluations.
Specification Development is the core of CORBAmed activity that results in
standard specifications and adoption of object interfaces for healthcare
domain components. The OMG standardisation process includes issuance a
Request for Proposal (RFP) and attendant response evaluations.
Healthcare Domain Architecture Development is an activity that defines a
framework to support and guide activities. A logical representation of a
CORBAmed Healthcare System Template (CHST) provides the basis for this
6 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)

guidance. This logical representation is based on the ISO Reference Model
for Open Distributed Processing (RM-ODP). The RM-ODP representation is
then represented in UML based models to provide both a high level
representation of CORBAmed services, the inter-dependencies and
relationships between CORBA services.
OMG Support provides policies and procedures for standardisation activities.
Ensuring consistency with, and support of, healthcare domain requirements
with current OMG specifications provides viable solutions for healthcare and
leverages solutions from other domains, such as Electronic Commerce,
Finance, Telecommunications, Transportation and more.
A Toolkit of CORBAmed solutions (CORBAmed version 1.0) has been published
for your convenience. The CORBAmed Toolkit includes the following items and
much more to set you on the path to healthcare solutions:





Standard Specifications
Trial products and demonstrations
White papers and presentations
Available products
Companies contributing to the task force
The success of CORBAmed truly relies on the priceless input from the healthcare
industry. We strive to design compelling standard object services that meet your
needs and the needs of your organisation. It is our goal to provide you with the
most value for your investment in CORBAmed.
Technology will not stand still while business systems catch up. An integration
architecture must be adopted that enables continuous managed migration of
technology, infrastructure and business services.
OMG and CORBAmed invite you to join them in their mission of bringing true
interoperability to the healthcare industry. CORBAmed meets in conjunction with
scheduled OMG Technical Committee meetings.
CORBAmed’s Mission and Goals are explained in more detail in Appendix E, and
a brief description of OMG is given in Appendix F.
7 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
2
Introduction
2.1 CORBAmed Roadmap Charter
In April 1998, CORBAmed created it’s Roadmap group and set out its intention to
create a roadmap by adopting a charter. This charter was updated in March
2000:
CORBAmed Roadmap Charter
Version 2, 6th March 2000
The primary responsibility of the Roadmap Working Group (RWG) is to produce
and maintain the CORBAmed Service-based Reference Architecture for
Healthcare (SeRAH). The SeRAH is a template of software interface
specifications for common services that can be used by both providers of
healthcare and suppliers of health information systems. It also positions these
modules in relation to other necessary elements of integrated health information
systems: Information Models, APIs and infrastructure services. The purpose of
the Reference Architecture is to delineate and describe the interfaces and
interactions between the various logical modules in health care systems. The
interactions and interfaces between the modules will then serve as a reference
against which the issuance of future health care related Requests For
Information (RFIs) and Requests For Proposal (RFPs) can be considered.
The SeRAH is the property of the CORBAmed Domain Task Force (DTF) as a
whole. It is the role of the RWG to produce the SeRAH for validation and
acceptance by the DTF, and to maintain it on behalf of CORBAmed. The RWG
acts as the guardian of the SeRAH in assessing the impact of proposed RFIs and
RFPs, both in CORBAmed and in other Task Forces, in achieving the goals of
CORBAmed and in evolving the Reference Architecture itself.
One of the missions of the Roadmap Working Group will be to facilitate
communication between CORBAmed and other groups in the Object
Management Group, as well as external organisations, where there are common
interests. The RWG will make recommendations to DTF chairs on the need for
and practical means of achieving technical interaction, including timetabling,
communication and feedback.
2.2 Intended Audience
There exists a need to communicate the activities of the CORBAmed Domain
Task Force to a variety of groups of individuals. These groups include OMG
members who are not active participants within CORBAmed, new members to
CORBAmed, and also existing members of CORBAmed. It is becoming more
and more difficult to remain current on all activities as the group is growing at
such a rapid pace. Therefore we have created this working document to
communicate past and current activities as well as to provide guidance for our
future activities.
8 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
2.3 Purpose of the CORBAmed Roadmap
The purpose of the CORBAmed Roadmap is to enable the creation of OMG
deliverables; interoperability specifications within the Healthcare domain, whilst
creating a template of the services that CORBAmed offers or plans to offer. One
of the goals of the roadmap is to enable immediate significant achievements to
be achieved within CORBAmed by clearly defining the scope and boundaries of,
and the relationships between the components in, one or more sub-sections of
the vast domain of healthcare.
This document serves as a plan and schedule for the activities related to creating
OMG specifications within healthcare. It identifies categories of activity and
specific work items within those categories, lists expected work item deliverables;
and provides a schedule for work items. Hence, this document will serve the
purpose of guiding as well as describing the CORBAmed activities.
Much of what is contained in this document exists in the minds of those who
participate in CORBAmed DTF activities. The purpose of this inclusion is to
provide communication to those expressing an interest. This can be seen in the
following sections: requirements elaboration and specification development.
2.4 Liaison Activity
CORBAmed has formed both informal and formal relationships with several other
standards groups:















Health Level 7 (HL7)
DICOM
Stichting Groupe RICHE
W3C
The Open Group
ISO TC215
ISO/IEC JTC1
ASTM
NEMA
IEEE1073
X12
NCPDP,
CEN TC251
GEHR Foundation
NCVHS (the US Government National Committee on Vital Health
Statistics)
2.5 Domain Architecture
This document, including the CORBAmed Service-based Architecture for
Healthcare is intended to be a step upon the path to create a Domain
9 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
Architecture for Healthcare. Whilst it is already clear what such a Domain
Architecture will look like in part; namely a set of interoperable component
specifications, there is still considerable debate on the role and existence of
domain architecture(s) within the OMG, and further elaborations will emerge.
There is a great deal of OMG and ISO activity in exploring an appropriate
methodology and model for describing such architectures.
One as a likely and appropriate candidate methodology to describe a domain
architecture is he enterprise view of the Reference Model – Open Distributed
Processing (RM-ODP).
3
Business Case
3.1 The State of Healthcare Informatics
To understand the present work and objectives of CORBAmed, it is worthwhile
examining some of its historical context.
The use of automation in healthcare began in the late 1960’s with the advent of
Hospital Information Systems (HIS). The original HIS’ were mainframe based
information systems and supported billing. Other administrative functions
(admission-discharge-transfer of patients, inventory, scheduling) were added with
time. The availability of lower cost minicomputers in the 1970’s spurred the
introduction of departmental information systems (radiology information system,
lab information system, pharmacy management system, etc.). These systems
supported similar administrative and workflow tracking functions at the clinical
departmental level. The mainframe-based HIS systems tried to respond by
adding departmental modules, but the special clinical requirements of individual
departments hindered this (at least until the early 1990s when acquisitions
resulted in a few companies with domain expertise across the hospital’s
departments. However, ambulatory care remains an informatics speciality largely
unto itself to this day). The result has been a “tower of Babel” situation where
most information systems within a hospital or IDS (Integrated Delivery System)
cannot interoperate. There are existing standards that allow these systems to
communicate, but the industry is yet to achieve healthcare systems
interoperability.
The 1980’s saw the rise of relational database management systems and client
server computing. Many businesses made major investments in converting to
these technologies. However, healthcare has been slow to respond. The
reasons for this can only be speculated upon, but it has been noted that
healthcare institutions typically spend a far lower percentage of their operating
budgets on informatics than do other industries, such as banking,
communications and transportation. This is thought by many to be due to a lack
of incentive under fee for service medicine to invest in money saving informatics.
In addition, there has been a strongly held belief on the part of clinicians that
healthcare delivery is not a “business” and cannot be managed as such (note:
10 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
managed care directly challenges this assumption which is one likely reason why
it is so controversial). In any event, the healthcare informatics business is just
now in the process of converting from mainframe/minicomputer – terminal
technology to client-server. Industry groups such as Microsoft’s Healthcare
Users Group (HUG) have grown in response to this trend.
While informatics has long supported the financial and administrative sides of
healthcare, it is only recently that it has looked toward supporting the clinician.
Electronic patient monitoring and imaging equipment has been around since the
1960’s, but until the 1990’s each such piece of equipment was an island unto
itself. Physicians typically never touched these machines; specially trained
technologists operated them and produced hardcopy for the physician to
diagnose from. The medical imaging business responded to a call for
interoperability in the mid-1980’s with the ACR-NEMA standard, but it took over
ten years for this to evolve to the present DICOM standard. DICOM supports
interfacing various pieces of imaging equipment, but interoperability remains an
elusive goal. Clinical monitoring equipment has likewise achieved cross-vendor
connectivity (i.e. with the Medical Information Bus – MIB – standard), but not true
interoperability.
As we move toward the year 2000, we find that healthcare institutions (the IDS’,
in particular) have developed a strong need for affordable, interoperable
information systems. These systems must operate seamlessly across a wide
variety of institutions – pharmacies, laboratories, physician practices of all sizes,
outpatient clinics, community hospitals, and tertiary/quaternary care regional
medical centres. Furthermore, the MCO model means that participating
institutions need to interoperate by sharing their information; but as individual
business entities, each institution in an IDS must maintain ownership of their
important patient-centred records. Centralised systems cannot meet these
needs. Neither can client-server systems (which, themselves, are centralised
data storage systems with local data analysis and presentation capabilities).
However, distributed object technology would seem ideal for this purpose. The
object oriented (OO) principle of encapsulation is ideal for the protection of data
ownership while allowing controlled access to the information by external clients.
Distributed object technology (such as CORBA) allows healthcare related objects
to communicate over a network; in particular, across physical computer
boundaries. CORBA, specifically, as a platform and language independent
standard for distributed object technology, seems to offer the best migration path
from the current tower of Babel to interoperable IDS’s.
3.2 The Distributed Object World in Healthcare
The last section presented a brief history of healthcare informatics and stated a
case for distributed object technology in healthcare in terms of encapsulation and
platform independence. Section 2 argued that current events are forcing
healthcare to look at itself as a business, and to behave as such. In the USA this
is seen in the trend toward managed care. In the UK the market led reforms of
11 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
the early 1990s produced a similar effect (although these have been partially
withdrawn), and across the world, healthcare providers are being expected to
justify their existence as never before. If this continues (and there is no reason to
believe that it will not), then the other important OO attributes of inheritance and
polymorphism should support a major paradigm shift in healthcare informatics;
that is, the trend way from “vertically oriented” departmental systems toward
“horizontally oriented” business objects. This concept is depicted in the figure
below.
Departmental View
Enterprise View
Billing
PACS
radiology
PACS
cardiology
Access
Control
Workflow
Mgmt
Order
entry
Scheduling
Healthcare
Record
MPI
Lab.
Person Id
Pharmacy
Order
entry
Present
Future
Figure – The changing paradigm of Health Informatics
Instead of viewing the IDS as radiology, cardiology, laboratory, etc., the object
oriented view is of common services, e.g.: order entry, enterprise scheduling,
results reporting, etc. These services have many operations (methods) in
common across the clinical departments. If they are created on an enterprise
basis, they can be subclassed to meet any detailed needs or nuances of specific
clinical departments. The feeling here is that a lot of duplicated functionality (in
operations, staffing and software) could be eliminated with this approach.
The cost and quality of healthcare software can be improved by inheriting
characteristics which are common to other businesses. Most businesses involve
persons and/or institutions which interact in the following ways:


Ordering
Tracking (workflow)
12 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)






Scheduling
Delivery of goods/services (order fulfilment)
Billing
Inventory
Personnel administration
Common services (security, timekeeping, persistence, vocabulary, etc.)
It should therefore be possible to build a top level model of the healthcare
domain which inherits from these general business functions:







Persons:
 Patients
 Guardians/guarantor
 Physicians
 Nurses
 Technologists
 Therapists
 Pharmacists
 Clerical Personnel
 Administrative personnel
 Maintenance personnel
 Etc.
Institutions:
 Hospital
 Clinic
 Office practice
 Laboratory
 Pharmacy
 Etc.
Ordering
 Clinical Orders (medications, diagnostic procedures, therapeutic
procedures)
 Pharmacy
 Event orders (ADT)
Tracking
 Enterprise (patient tracking)
 Departmental (workflow tracking)
Scheduling
 Enterprise
 Departmental
Delivery of goods/services (order fulfilment)
 Clinical Observations/Results Reporting
 Clinical Decision Support
Etc.
13 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)

Healthcare Financial Services
The present work of CORBAmed is related to many of these business areas.
It is important to note that the transition from a legacy department-based
information environment to an enterprise-wide distributed object environment
cannot realistically take place in one shot. There are far too many legacy
systems which support essential functions within the healthcare delivery system
today. Therefore, CORBAmed should adopt a solution which allows CORBA
specifications to support implementations that bridge between message-based
legacy systems and interoperable CORBA components.
3.3 Breadth of Applicability
The goodness of most CORBAmed specifications can be gauged by their ability
to support disparate cultures and organisational structures. For example the
authors of the COAS (Clinical Observations Access Service) specification took
account of models of health delivery from a wide range of sources: CEN (Centre
Européen pour Normalisation), the UK Healthcare Model, HL7 etc.. COAS
sought to ensure that the specification would work with as many models of the
clinical observation as possible.
Applying this generic approach across the range of CORBAmed’s work has
produced a number of benefits:
1.
2.
3.
Services built to CORBAmed specifications are aimed at the largest
possible market place, not limited to one country or one mode of health
care delivery.
CORBAmed services do not force users to adapt to software that is
designed for administrative and commercial methods that are different
from their own.
CORBAmed specifications, and often their associated implementations do
not become “dated” by organisational changes in healthcare providers and
purchasers, because they are not tied to one culture or method of delivery.
This approach is not applied dogmatically. For example the present work on
SLiMS (Summary List Management Service) is aimed at producing, probably with
the help of COAS, a specific summary list of the hospital patient record that is
demanded by US legislation. However, even in this case, consideration is being
given to making SLiMS adaptable to the needs of other countries and, of course,
such adaptability will insure the users of SLiMS services against the possibility
(or likelihood) of future changes in US legislation.
3.4 Return on Investment of using CORBAmed.
Awaiting info from Raj Mukerji
14 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
4
Adopted Specifications and Specification Development
(RFPs)
4.1 Introduction
The central focus of the work of CORBAmed is to foster the adoption of standard
object interfaces for healthcare domain components. These standard object
interfaces will be developed through the group’s adherence to OMG convention,
that is, the issuance of Requests for Proposal (RFP), the evaluation of proposed
solutions to the RFP, and the development of a public specification.
To reiterate, this focus activity is the primary purpose for the group’s existence.
4.2
Specific Work Items
Work items identified within this focus activity include:
 Issue Requests for Proposal (RFPs)
 Evaluate responses to RFPs
 Make recommendations for adoption - specification development
 Follow-up with RFPs that subsume integration frameworks and address
domains
4.3
Deliverables
Anticipated deliverables produced by this focus activity include:
 RFPs
 RFP responses
 Recommendations to DTC (the OMG Domain Technical Committee)
15 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
4.4 OMG/CORBAmed Specifications Scorecard
The table below sets out, in short-form, the present state of CORBAmed
adoptions and pre-adoptions. These are described in more detail in sections 4.5
and 4.6.
Specification
Status
Function
Existing Products
Person Identification
Service (PIDS)
Adopted
Service for uniquely
identifying a person
within an environment.
Terminology Query
Service (TQS)
Adopted
Resource Access Decision
(RAD)
Adopted
Clinical Observation
Access Service (COAS)
Adopted
Service used to access
terminological
information for use in
mediation, presentation
and dynamic discovery.
Service used to obtain
authorisation decisions
and administrating
access decision policies
for medical information.
Service used to retrieve
clinical information about
a person.
Clinical Image Access
Service (CIAS)
Health Information Locator
Service (HILS)
Adopted
Summary List
Management Service
(SLiMS)
Medical Transcription
Document Management
(MTM)
Healthcare Data
Intpretation Facility (HDIF)
Order Management
Service (OMS)
Service used to retrieve
and manage images.
Service that will be used
to locate medical
information.
Service used to manage
medical summary lists.
Current Work
Item – RFP
Issued
Current Work
Item – RFP
Issued
Current Work
Item – RFP
Issued
Service to transcribe
clinical information.
Current Work
Item – RFP
Issued
Current Work
Item – RFP
Issue planned
Component of clinical
decision support.
Serviced used to mange
orders within a medical
environment.
16 of 60
3M Care Innovation
(Enterprise Master
Person Index)
Care Data Systems
(Correlation Channel)
Protocol Systems
(Acuity®)
3M Care Innovation
(Health Data Dictionary
bundled with their CDR)
Care Data Systems
(In progress)
2AB/DASCOM
(In progress)
3M Care Innovation
Clinical Data
Repository
(In Progress)
4.5
Adopted Specifications
4.5.1 Person Identification Service (PIDS)
Throughout an individual’s lifetime they may have episodes of care supported by
hundreds of healthcare providing organisations (e.g. hospitals, medical centres,
Dr. offices, etc.). These organisations maintain medical records for the patients
they have cared for. When a patient comes into a healthcare organisation for
care there is a need to find the records for any previous care that patient had with
the institution. Each healthcare provider may have used a different scheme (e.g.
numbering system and/or identifiers) to identify the patient. The system used for
identifying a patient is called a Master Patient Index (MPI).
In addition it is desirable to combine the medical records from multiple institutions
in order to show a complete picture of a person’s health record. This need to
combine records from different organisations has increased dramatically in the
last few years due to consolidations and collaborations between providers.
Because of the rapid change in the healthcare environment within the last few
years the systems and standards needed to satisfy this need to share patient
records are now just emerging. One of the major impediments to this sharing of
patient records between organisations was the need for a consistent way to
identify a patient. Due to this inability there is no standard way today to combine
a patient’s records from multiple institutions.
PIDS provides a specification addressing the common features of a patient
identification system that allows multiple of these patient identification systems to
interoperate.
It is designed to:
 Support both the assignment of IDs within a particular ID Domain and the
correlation of IDs among multiple ID Domain.
 Support searching and matching of people in both attended-interactive and
message-driven-unattended modes, independent of matching algorithm.
 Support federation of PIDS services in a topology-independent fashion.
 Permit PIDS implementations to protect person confidentiality under the
broadest variety of confidentiality policies and security mechanisms.
 Enable plug-and-play PIDS interoperability by means of a “core” set of profile
elements, yet still support site-specific and implementation-specific
extensions and customisation of profile elements.
 Define the appropriate meaningful compliance levels for several degrees of
sophistication, ranging from small, query-only single ID Domains to large
federated correlating ID Domains.
CORBAmed PIDS compliant Servers can be obtained from:
 Ken Rubin, April 2000
OMG CORBAmed Roadmap – Version 2.0 (draft)
Enterprise Master Person Index
xxxxxxxxxx
3M Care Innovation
575 West Murray Boulevard
Murray, UT 84123-4611
+1 801 265 4534
xxxxxxx@wpmail.code3.com
Correlation Channel
Jon Farmer
Care Data Systems, Inc.
3500 Deepwoon Lane
Lambertville, MI 48144
+1 734 856 8181
jfarmer@caredatasystems.com
Acuity®
Steven Tufty
Protocol Systems, Inc.
8500 SW Creekside Place
Beaverton, OR 97008-7107
+1 503 526 4376
pop@protocol.com
4.5.2 Terminology Query Services (TQS)
This service provides lexicons (controlled terminology resources) in a distributed
object system. The ability to represent a concept in an unambiguous machinereadable format is key to the better management of clinical processes within a
healthcare organisation, and between a healthcare organisation and its various
trading partners. The ability to support a discrete coded lexicon is of critical
importance in healthcare.
The scope of this specification is to specify a set of common, read-only methods
for accessing the content of medical terminology systems. What constitutes a
medical terminology system can vary widely, from a simple list consisting of a set
of codes and phrases at one extreme, to a dynamic multi-hierarchy classification
and categorisation scheme at the other. The focus was to determine what could
be construed to be “common” elements of terminology systems. By “common,”
we mean the set of elements in which the semantics are fairly widely accepted,
even though they may not be present in all or even many of the terminology
systems available today. The goal was to produce a specification that could be
used to implement a reasonable and useful interface to any of the major medical
coding schemes.. It is the first step towards being able to:
Page 18 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)



Better manage the communication of information between disparate
organisations
Support the collection and analysis of clinical processes and outcomes as a
result of consistent and clinically specific encoding
Enable the use of sophisticated rule-based ‘decision support’ tools, which
require consistent data representation to be effective. For example, the rule:
If the order is for any drug in the category antibiotics and there is a history
of allergy to any antibiotic, send an alert regarding possible cross-allergic
reactions requires the ability to classify all antibiotics under a single
‘parent’ in a specified hierarchy to assure that no matter what drug is
ordered, if it is in the category antibiotics, this rule is triggered.
It is important to make the distinction between the terminology content (i.e., the
“vocabularies” themselves), and the methods to support terminology queries and
functions. In fact, we should not assume that the terminology query services
defined through this effort are necessarily limited to support of a health
lexicon/domain of content. It has been anticipated that these services are a
requirement across other domains/task forces within OMG. However, since the
primary interest and critical, near term need resides within the healthcare
domain, CORBAmed took the lead in the effort to define these services.
CORBAmed TQS compliant Server can be obtained from:
Health Data Dictionary
xxxxxxxxxx
3M Care Innovation
575 West Murray Boulevard
Murray, UT 84123-4611
+1 801 265 4534
xxxxxxx@wpmail.code3.com
4.5.3 Healthcare Resource Access Decision (RAD)
To be added – Author has been unable to locate a summary description of RAD
CORBAmed RAD compliant servers will be available from:
Jon Farmer
Care Data Systems, Inc.
3500 Deepwoon Lane
Lambertville, MI 48144
+1 734 856 8181
jfarmer@caredatasystems.com
Page 19 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
xxxxxxxxxxx
2AB/DASCOM
xxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxx
4.5.4 Clinical Observations Access Service (COAS)
To be added – Author has been unable to locate a summary description of COAS
The CORBAmed COAS compliant server will be available from:
xxxxxxxxxx
3M Care Innovation
575 West Murray Boulevard
Murray, UT 84123-4611
+1 801 265 4534
xxxxxxx@wpmail.code3.com
4.5.5 Clinical Image Access Service (CIAS)
This service enables the accessing (i.e. retrieving) of clinical images and related
information. Clinical images are a subset of clinical observations and the Clinical
Image Access Service (CIAS) is a specialisation of the CORBAmed Clinical
Observations Access Service (COAS). CIAS provides more detailed, imagerelated access services to COAS. CIAS provides image scaling and windowing
to meet the needs of general clinicians for the non-diagnostic viewing of medical
images. CIAS is a retrieve-only service. Furthermore, CIAS deals only with
clinical images; requirements for document images (bit maps) are not covered by
this service.
The most prominent standard for image interchange in medicine is the Digital
Imaging and COmmunications in Medicine (DICOM) standard of the National
Electrical Manufacturers Association (NEMA). CIAS provides a simplified view
of the DICOM information model which supplies images and limited meta-data to
users in formats which are compatible with better known image standards and
with office type computing equipment and networks. CIAS hides the complexities
of DICOM while providing the basic services needed to support computer-based
patient records over low and moderate speed networks.
The CORBAmed CIAS compliant server will be available from:
Yasser alSafadi & Jingkun Hu
Philips Research
345 Scarborough Road
Page 20 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
Briarcliff Manor, NY 10510 USA
+1 914 945 6294
yha@philabs.research.philips.com
jhu@philabs.research.philips.com
Christian Zapf
Siemens Health Services
Henkestr. 127
D-91052 Erlangen, Germany
+49 91 31 84 8206
christian.zapf@shs-online.de
Page 21 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
4.6 Current Work Items
The principal work items in this focus activity are related to the issuance and
evaluation of RFPs.
4.6.1 Healthcare Information Locator Service (HILS) RFP
The Healthcare Information Locator Service (HILS) RFP is intended to address
the need to identify locations of information across a distributed enterprise. This
information could pertain to an individual, population, or defined set of
characteristics. Though there are presently standards addressing the
identification of individuals within and across domains, HILS is intended to
complement these capabilities in locating and providing summary data about
records identified to exist for specified criteria.
Within the medical environment, there is a tendency for patients and populations
to migrate across various points-of-care. Similarly, the medical records are
maintained at the point of treatment. This creates a problem in assembling and
making available information at the point it is needed, as it must first be identified
and located within and across enterprises. HILS is intended to provide for this
identification.
http://www.omg.org/docs/corbamed/99-11-18.doc
4.6.2 Summary List Information Management (SLiMS) RFP
This RFP solicits proposals for a service capable of tracking significant
diagnoses, procedures, drug allergies and medications for a patient. This
information, referred to as summary lists, is used by providers to get a summary
overview of a patient’s condition. The U.S. Joint Commission of Accreditation of
Healthcare Organisations (JAHCO) requires, as part of their Information
Management Criteria (IM 7.4), that summary lists have to be up to date by the
third outpatient visit for ambulatory care. Beyond this U.S. accreditation
requirement, there has been international interest for a capability to manage
patient summary lists. The focus of this RFP is for a service specification that
allows the creation, update and management of summary lists.
http://www.omg.org/docs/corbamed/99-03-27.doc
4.6.3 Medical Transcription Document Management (MTM) RFP
The management of documents throughout an organization requires tight
integration and strong communication among multiple entities.
Historically, manual interfaces, proprietary interfaces, and HL7 (Health
Level 7) messaging have met these needs. However, these solutions
have only been partial, and are proving inadequate in today's complex
healthcare environments. Standardized object interfaces promise to
provide a solution which not only preserves the current modes of
document management, but also provides a solid, long-term technical
Page 22 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
framework to build the next generation of healthcare information
systems.
This RFP solicits proposals for document management facilities
compatible with the COAS (CORBAmed Clinical Observation Access
Service). Such facilities will provide mechanisms to access medical
documents and related meta-data in a manner that supports the
workflow pertaining to capturing, managing, documenting, routing,
authenticating (signing), notifying, and verifying.
http://www.omg.org/docs/corbamed/98-04-03.pdf
4.6.4 Healthcare Data Interpretation Facility (HDIF) RFP
This RFP solicits proposals for a Healthcare Data Interpretation Facility (HDIF)
that will provide a general-purpose infrastructure capable of the following:

accommodate a variety of intelligent transforms for clinical data;

enable easy integration of so called intelligent systems into existing
healthcare information systems;

provide common interfaces for performing intelligent transforms on healthcare
data distributed across disparate healthcare data domains.
http://www.omg.org/docs/corbamed/98-03-30.doc
Page 23 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
5
Requirements Elaboration (Requests for Information - RFIs)
5.1 Introduction
The purpose of this focus activity is to acquire more detailed requirements. This
is vital to the group’s comprehension of industry needs and is crucial in aligning
OMG specification development with healthcare requirements. The request for
discovering requirements in a particular area is primarily based on an interest
and participation by an OMG member.
5.2 Specific Work Items
Work items of a general nature identified within this focus activity include:
 Issue RFIs on requirements / solicit vendors
 Survey available, existing healthcare architectures (via RFIs) for purpose of
identifying candidates for standardisation, positioning the group to ask rather
than define healthcare frameworks
 Issue white papers addressing healthcare topics
5.3 Deliverables
Anticipated deliverables produced by this focus activity include:
 White papers
 RFIs
 RFI responses
 Updated CORBAmed Service-based Architecture for Healthcare
 Scope definitions for RFPs
Page 24 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
5.4 Past Work Items
This section comprises some of the Requests For Information (RFIs) that have
been issued over the history of CORBAmed. Not all RFIs are included here as
some have been superseded by further work. For example, COAS, the Clinical
Observations Access Service, began life as an RFI, moved onto being a Request
for Proposal (RFP) and finally became an adopted specification. For most
readers, it is the adopted specification that is of interest at this time. Historical
information about the progress of COAS, or any CORBAmed work, can be
obtained by searching the OMG Library.
5.4.1 The CORBAmed RFI
Summary
CORBAmed RFI 1 was issued to solicit information about requirements, projects,
and products that would provide guidance for healthcare related object system
interoperability. The Object Management Group (OMG) CORBAmed Domain
Task Force will use this information to begin the technology adoption process for
OMG-compliant interfaces for systems used in healthcare delivery. This RFI
seeks information to help CORBAmed make useful and efficient decisions in the
healthcare technology adoption process.
CORBAmed RFI 1 can be found on the OMG web server as document #:
http://www.omg.org/docs/corbamed/96-01-01.rtf : CORBAmed RFI
Responses to CORBAmed RFI 1 are as follows:
 http://www.omg.org/docs/corbamed/96-04-01.rtf : IBM Health Solution Unit
RFI response
 http://www.omg.org/docs/corbamed/96-05-01.rtf : HL7 IMSIG Response to
CORBAmed RFI
 http://www.omg.org/docs/corbamed/96-05-02.rtf : HealthMagic CORBAmed
RFI response
 http://www.omg.org/docs/corbamed/96-05-03.rtf : University of Magdeburg
RFI response
 http://www.omg.org/docs/corbamed/96-05-04.rtf : RFI response from SHINE
 http://www.omg.org/docs/corbamed/96-05-05.rtf : RFI response from RICHE
 http://www.omg.org/docs/corbamed/96-05-06.rtf : Protocol Systems RFI
response
 http://www.omg.org/docs/corbamed/96-05-07.rtf : CORBAmed RFI response
from Andersen Consulting
 http://www.omg.org/docs/corbamed/96-05-08.rtf : University of Wales,
Aberystwyth RFI response
 http://www.omg.org/docs/corbamed/96-05-09.rtf : Benchmarking Partners RFI
response
Page 25 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)






http://www.omg.org/docs/corbamed/96-05-10.rtf : Hewlett-Packard RFI
response
http://www.omg.org/docs/corbamed/96-05-11.rtf : Health Data Sciences Corp.
RFI response
http://www.omg.org/docs/corbamed/96-05-12.rtf : Los Alamos National
Laboratory RFI response
http://www.omg.org/docs/corbamed/96-05-13.rtf : NHS RFI response
http://www.omg.org/docs/corbamed/96-05-14.rtf : Koop Foundation RFI
response
http://www.omg.org/docs/corbamed/96-05-15.rtf : Kurzweil AI RFI response
5.4.2 CORBA and HL7 - Approaches and Considerations RFI
Summary
CORBAmed RFI 4a solicits information about requirements that will provide
guidance to the CORBAmed Domain Task Force (DTF) of the Object
Management Group (OMG) in the area of CORBA based HL7 implementation
approaches. The overall goal of CORBAmed is to adopt vendor-neutral common
interfaces that may improve the quality of care and reduce costs. CORBAmed
DTF will utilise the OMG’s open technology adoption process to standardise
interfaces in the healthcare arena.
In the area of HL7 as a standard messaging approach, CORBAmed has
established a liaison relationship with the HL7 standards group. One of the
primary reasons for this liaison is the desire on the part of CORBAmed to not
‘recreate the wheel’. CORBAmed desires to leverage the HL7 reference
information model, other HL7 based initiatives, and other standards that help
support healthcare communications. As part of that relationship, CORBAmed is
attempting to assist HL7 by providing technical analyses regarding
implementation approaches, and how to best take advantage of the capabilities
inherent in the CORBA distributed object technology framework. We believe that
there are a number of possible technical approaches that can be utilised, but are
uncertain as to the most optimal approach. Several approaches have been
defined already within HL7, through the SIGOBT. There are, we believe, a
number of other organisations who have begun to implement CORBA based
solutions, who are also using HL7 messages as the semantic backdrop to their
implementations.
The complete CORBAmed RFI 4a can be found on the OMG web server as
document:
http://www.omg.org/docs/corbamed/97-09-15.rtf : HL7 RFI
Responses to RFI 4a are as follows:
 http://www.omg.org/docs/corbamed/98-01-04.rtf : HBO & Company Response
to the HL7 RFI
Page 26 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)

http://www.omg.org/docs/corbamed/98-01-05.rtf : Hewlett-Packard Response
to the HL7 RFI
5.4.3 Lifesciences RFI
Summary
CORBAmed RFI 4b solicits information about requirements, projects, and
products that will provide guidance for life sciences research related object
system interoperability. The Object Management Group (OMG) and, specifically,
the Life Sciences Research Domain Special Interest Group (LSR-DSIG), will use
this information to begin the technology adoption process for OMG-compliant
interfaces for systems used in life sciences research. The mission of the Life
Sciences Research DSIG is:
 To improve the quality and utility of software and information systems used in
Life Sciences Research through use of the Common Object Request Broker
Architecture (CORBA) and the Object Management Architecture (OMA).
 To encourage the development of interoperable software tools and services in
Life Sciences Research.
 To prepare to use the Object Management Group (OMG) technology adoption
process to standardise interfaces for software tools, services, frameworks,
and components in Life Sciences Research.
 To communicate the requirements of the Life Sciences Research domain to
the Platform Technical Committee.
To co-ordinate with OMG Task Forces and Special Interest Groups, and other
standards organisations and information providers to ensure common standards.
The OMG encourages users, consultants, systems integrators, and developers of
life sciences research related devices, instruments, applications, databases, and
systems to become involved with this process by responding to this RFI. OMG
members and non-members may submit responses. Current compliance with
OMG specifications is not a prerequisite for response to this RFI. The RFI
response can consist of pre-existing product documentation, but should
preferably be organised and presented in accordance with this RFI.
NOTE: According to OMG rules, SIGs may not issue RFIs. Therefore, this RFI is
being issued by the CORBAmed Task Force on behalf of the Life Sciences
Research DSIG. Responses to this RFI will be reviewed by LSR-DSIG.
The complete CORBAmed RFI 4b can be found on the OMG web server as
document:
http://www.omg.org/docs/corbamed/97-09-16.rtf : Life Science Research RFI
(CORBAmed RFI4)
Responses to RFI 4b are as follows:
Page 27 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
















http://www.omg.org/docs/corbamed/97-11-07.rtf : Birkbeck College, Dept. of
Crystallography Response to the Lifescience RFI
http://www.omg.org/docs/corbamed/97-11-08.rtf : Genome Database
Response to the Lifescience RFI (Part 1)
http://www.omg.org/docs/corbamed/97-11-09.rtf : Genome Database
response to the Lifescience RFI (Part 2)
http://www.omg.org/docs/corbamed/97-11-10.rtf : Oxford Molecular Group
Response to the Lifescience RFI
http://www.omg.org/docs/corbamed/97-11-11.rtf : Roslin Institute Response to
the Lifescience RFI
http://www.omg.org/docs/corbamed/97-11-12.rtf : University of Manchester
Response to the Lifescience RFI
http://www.omg.org/docs/corbamed/97-11-13.rtf : University College London
response to the Lifescience RFI
http://www.omg.org/docs/corbamed/97-11-14.rtf : National Center for
Genome Resources Response to the Lifescience RFI
http://www.omg.org/docs/corbamed/97-11-15.rtf : Sequana Therapeutics
Response to the Lifescience RFI
http://www.omg.org/docs/corbamed/97-11-16.rtf : Bioperl Developers
response to the Lifescience RFI
http://www.omg.org/docs/corbamed/97-11-17.rtf : Tripos Response to the
Lifescience RFI
http://www.omg.org/docs/corbamed/97-11-18.rtf : NetGenics Response to the
Lifescience RFI
http://www.omg.org/docs/corbamed/97-11-19.rtf : EBI Response to the
Lifescience RFI
http://www.omg.org/docs/corbamed/97-11-20.rtf : Berkeley Drosophila
Genome Center Response to the Lifescience RFI
http://www.omg.org/docs/corbamed/97-11-21.rtf : G.I.S Infobiogen Response
to the Lifescience RFI
http://www.omg.org/docs/corbamed/97-11-22.rtf : University of Pennsylvania
Response to the Lifescience RFI
5.4.4 CORBA/M Interoperability RFI
Summary
CORBAmed RFI 5 solicits information to guide the CORBAmed Domain Task
Force (DTF) of the Object Management Group (OMG) in developing
specifications that will facilitate the integration of information systems written in
the American National Standards Institute (ANSI) M programming environment
with the Common Object Request Broker Architecture (CORBA). The overall
goal will be to adopt vendor-neutral specifications that will preserve and enhance
ANSI M systems by leveraging CORBA distributed-object technologies. The
CORBAmed DTF will utilise the OMG’s open technology adoption process in
pursuit of this goal.
Page 28 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
CORBAmed will use responses to this RFI to determine the interest and
requirements of the information systems community for interoperability standards
between M and CORBA technologies. If appropriate, one or more Requests For
Proposal (RFPs) may be issued to solicit CORBA/M interoperability
specifications.
Alternatively known as MUMPS (Massachusetts General Hospital Utility MultiProgramming System), the M programming environment consists of an
interpreted, multi-user, multi-tasking, general-purpose programming language
with integrated hierarchical persistent storage. M is the predominant language
world-wide with which large integrated hospital information systems have been
developed. In addition to numerous commercial healthcare systems, the hospital
information systems for the United States Department of Defense (DoD),
Department of Veterans Affairs (VA), and Indian Health Services (IHS) have all
been written in M. M has also found success as a language for implementing
systems in financial, travel, shipping, and other industries.
This RFI is being issued in order to gather information from the M and CORBA
communities with respect to the business case, technical need, and prospective
solutions for integrating their respective technologies.
The complete CORBAmed RFI 5 can be found on the OMG web server as
document:
http://www.omg.org/docs/corbamed/98-02-04.rtf : CORBA/M Interoperability RFI
(CORBAmed RFI5)
Responses to RFI 5 are as follows:
None posted at this time
5.4.5 Healthcare, Administrative, Logistical and Financial Encounter
Management RFI (HALFEM)
Summary
CORBAmed RFI 7 solicits information about requirements in the area of the
Administrative Encounter that will provide guidance to CORBAmed, the
Healthcare Domain Task Force (DTF), within the Object Management Group
(OMG). The overall goal of CORBAmed is to adopt vendor-neutral common
interfaces that may improve the quality of care and reduce costs. CORBAmed
DTF will utilise the OMG’s open technology adoption process to standardise
interfaces in the healthcare arena.
HALFEM information can be used to streamline registration, admission and
billing processes. Today this information sits in many places in various degrees
of completion and accuracy.
Page 29 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
The responses may describe the data being captured during the information
collection process, in particular to streamline the process.
The complete CORBAmed RFI 7 can be found on the OMG web server as
document:
http://www.omg.org/docs/corbamed/98-07-02.rtf : Healthcare, Administrative,
Logistical and Financial Encounter Management RFI (CORBAmed RFI7)
HALFEM information may include things like the following:
 Demographic information
 Mechanism for managing identifiers for clinical encounters
 Next of kin
 Advanced directives
 Provider information (primary, attending, consulting)
 VIP status
 Insurance/Guarantor Information
 Waiting list
 Eligibility
 Enrolment
 Scheduling
Response to RFI 7 is as follows:
http://www.omg.org/docs/corbamed/99-02-03.rtf
Page 30 of 60
6
CORBAmed Service-based Reference Architecture for
Healthcare (SeRAH)
6.1 Introduction
The purpose of the CORBAmed Service-based Reference Architecture for
Healthcare (SeRAH) is to define a reference template for healthcare domain
software components and a broader CORBAmed Service-based Architecture for
Healthcare. SeRAH supports the requirements elaboration focus activity and will
provide a framework for continuous specification development activity. This
architecture is not static, it will change and develop with the work of the
CORBAmed DTF.
6.2 Charter for SeRAH
The CORBAmed Roadmap Charter describes the CORBAmed Service-based
Architecture for Healthcare thus,
“….The SeRAH (CORBAmed Service-based Reference Architecture for
Healthcare) is a template of software interface specifications for common
services that can be used by both providers of healthcare and suppliers of
health information systems. It also positions these modules in relation to
other necessary elements of integrated health information systems:
Information Models, APIs and infrastructure services. The purpose of the
Reference Architecture is to delineate and describe the interfaces and
interactions between the various logical modules in health care systems.
The interactions and interfaces between the modules will then serve as a
reference against which the issuance of future health care related
Requests For Information (RFIs) and Requests For Proposal (RFPs) can
be considered.”
(see above for full Charter).
The CORBAmed Service-based Architecture for Healthcare is the property of
CORBAmed and it’s contents are determined by the DTF as a whole. The early
versions are intended to provide a basis for discussion and as each new version
appears it should more fully reflect the views of the DTF. One of the primary
influences on the Architecture will be the process of developing, issuing and
responding to RFPs (Requests for Proposal). As RFPs progress new information
and knowledge will emerge that demands changes to the Architecture and the
Roadmap group will make those changes and issue a new version.
6.3 Structure of SeRAH
SeRAH consists of two components:
1.
The CORBAmed Applications Template. This shows the adopted and
proposed modules that make up the stock-in-trade of CORBAmed. To
make this template accessible, it is shown in a honeycomb form, with each
cell being a CORBAmed module.
 Ken Rubin, April 2000
OMG CORBAmed Roadmap – Version 2.0 (draft)
2.
The Reference Architecture. This shows the relationships between the
modules in the CORBAmed Applications Template and other necessary
elements of integrated health information systems: Information Models,
APIs and infrastructure services etc..
©Ken Rubin
Page 32 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
6.4
The CORBAmed Service-based Architecture for Healthcare (SeRAH)
6.4.1 SeRAH Part1: The CORBAmed Applications Template
The CORBAmed Applications Template is a number of simplified views of the
interrelationships between the various specifications, adopted, in pre-adoption,
planned and under consideration. The mode of expression adopted is the
hexagon. This is not perfect as it does not always allow the full range of
possible interfaces to be depicted. However, a number of approaches have been
attempted and none satisfactorily provided the combination of simplicity and
near-completeness of this one.
Several “user views” are given below, showing different services and
combinations of services that we believe will be of interest to different user
groups.
6.4.1.1 Provider View – Direct Service Provision
Here, the focus is the provider of care, typically a provider (USA) or hospital trust
(UK). All of the adopted specifications (in red) are viewed as being key to this
view. In addition the Order Entry/management, Charge Capture and Eligibility
Services are key.
Summary List
Management
Service
Eligibility
Service
Charge
Capture
Management
Service
Medical
Transcription
Service
Person
Demographic
Service
Order Entry
Service
Order
Management
Service
LEGEND
Adopted
Clinical
Observation
Access
Service
Clinical
Image
Access
Service
RFP
Terminology
Query
Service
Person
Identification
Service
Health
Information
Locator
Service
Resource
Access
Control
Service
Healthcare
Relationship
Service
Pre-RFP
RFI
Provider View – Direct Service Provision
©Ken Rubin
Page 33 of 60
Party
Management
Facility
OMG CORBAmed Roadmap – Version 2.0 (draft)
6.4.1.2 Clinical Systems Developer’s View
Here we see the focus of the delivery of clinical care. We see the Person as
being central, with access to demographic and clinical information figuring
heavily. Order Entry/Management control the delivery of care for that individual
whilst the Health Information Locator Service covers the need to get a complete
clinical picture of that individual.
Terminology
Query
Service
Person
Demographic
Service
Clinical
Order Entry
Observation
Service
Access
Service
Resource
Party
Person
Access
Management
Identification
Control
Facility
Service
Service
Clinical
Order
Image
Management
Access
Service
Health
Service
Information
Locator
Service
Healthcare
Relationship
Service
©Ken Rubin
Page 34 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
6.4.1.3 Provider View – Billing
This group shows the services needed to track an individual patient’s progress
though a provider encounter, capturing charges and checking eligibility (note the
Eligibility Service is slightly detached because it is viewed as being in the payer
domain).
Terminology
Query
Service
Eligibility
Service
Person
Demographic
Service
Claims
Management
Service
Order Entry
Service
Charge
Capture
Management
Service
Remittance
Management
Service
Person
Identification
Service
Resource
Access
Control
Service
Party
Management
Facility
Healthcare
Relationship
Service
6.4.1.4 Payer View
Here the payer takes care of enrolling people to health plans, managing the
plans and, in co-ordination with slightly detached provider services, checking
eligibility for, and authorising care.
Enrolment
Management
Service
Health
Benefit Plan
Management
Service
Person
Demographic
Service
Claims
Management
Service
Person
Identification
Service
Care
Authorization
Management
Service
Charge
Capture
Management
Service
Remittance
Management
Service
Eligibility
Service
©Ken Rubin
Page 35 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
6.4.2 SeRAH Part2: The Reference Architecture
This paper was written to position the use of CORBAmed specifications by the
US Government Patient Record Programme (G-CPR) in relation to other
specification and modelling work. It so closely reflects the need of CORBAmed
to so position itself, that it is reproduced in full here. With the CORBAmed
Applications Template, it constitutes the second part of the CORBAmed Servicebased Architecture for Healthcare (SeRAH).
________________________________________________________________
Using a Taxonomy Matrix as a Communications Instrument
Version 1.01
April 14, 2000
Overview
KENNETH S. RUBIN
Models are produced in a context, for a purpose, and with objectives. A consumer of these
work products is likely to find contextual information is rarely captured within the models
themselves, making it difficult to determine where these products can best-address projectlevel needs or requirements.
To cope with this deficiency, a taxonomy matrix can serve as communications vehicle. In
this capacity it allows a better understanding the interrelationships of these models, their
relevant context, and their appropriate application as artefacts to support system
development activities.
The taxonomy matrix described in this paper is the result of several months of analysis
focused on solving an instance-problem (related to reconciling several modeling components
produced for a particular development effort). The matrix provides the means necessary to
both understand and address varying levels of abstraction, context, and intention. Its
application resolved what had been months of intellectual debate.
Audience
This paper is intended for professionals whom are interested in the capture, understanding,
and application of formal artefacts in the context of complex problem spaces. Though
primarily focused on information technology systems across the life cycle of their
development, the contents are not predicated on that environment.
Also, as this is resulting from efforts within healthcare information technology, the examples
included tend to remain particularly focused towards within that domain.
What it is
The matrix is a template allowing its user to differentiate between models or work-products
that result from a software development activity. Along the horizontal “axis” are listed a
©Ken Rubin
Page 36 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
series of viewpoints derived from an ISO standard: The Reference Model for Open
Distributed Processing (RM-ODP)1. Each viewpoint addresses a different perspective of the
same area of interest. By separating concerns, they collectively provide an effective means of
communicating a complex environment.
In addition to the breadth-wise parsing offered by the differing viewpoints, the matrix
provides a depth-oriented element identifying contexts that supplement each other. These
contexts include the business functional context, the service context, and the implementation
context. Furthermore these contexts mirror work-products that result from the various
aspects of system analysis and design. The result is a multi-dimensional view of an interest
area that allows for a more detailed understanding of how component parts fit together.
The matrix is not intended to be a solution. Towards that end, however, it makes possible
the identification of collaboration opportunities, highlights conflicting efforts, and relates
dependencies within activities and products. Resulting is the ability to better understand a
complex environment space.
Background
The U.S. Government had needed to establish a reference information model as a part of a
large healthcare project: the Government Computer-based Patient Record (GCPR)2. This
modeling activity was undertaken with two primary missions. The first was to ensure that
the GCPR modeling activity did not produce a parochial model, as several models of this
type exist and have not to-date successfully addressed interoperability across multiple large
care organisations. Second was the approach to leverage to the maximum extent possible
existing standards and expertise through close collaboration with established Standards
Development Organisations and/or products.
Through this approach, models from the following sources were examined and extensively
leveraged in the synthesis of the target Government model. As needed the models were
specialized, extended, or adapted to allow for maximum reuse of existing intellectual capital
within the context of articulated GCPR objectives.




1
Electronic Healthcare Record, Technical Committee on Health Informatics,
European Committee for Standardisation (CEN TC-251 EHCR)3
CORBAmed Person Identification Service Specification (PIDS)4
CORBAmed Clinical Observations Access Service (COAS)5
Health Level Seven Reference Information Model (HL7 RIM)6
The RM-ODP standard can be found at the ISO website at http://www.iso.ch:8000/RM-ODP
The GCPR is a U.S. Government project to provide interoperability across three Federal healthcare provider
organizations: Department of Defense, Veterans Health Administration, and Indian Health Service.
http://www.gcpr.gov.
3 http://www.centc251.org
4 http://www.omg.org/homepages/corbamed
5 Ibid. Note that this is the proposed name for what had been the Clinical Observation Access Service.
6 http://www.hl7.org
2
©Ken Rubin
Page 37 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)

U.K. National Health Service Healthcare Model (NHS HcM)7
Based on project critical-path dependencies, the first phase GCPR models had to produce
fine-grained results and be completed in a very short (<2 month) timeframe. Given this
constraint, a bottom-up modeling approach was taken. The project team chose to conduct
its modeling activity within the RM-ODP Information Viewpoint, as their primary task was
to define the information requirements of the Framework. The hope was that the use of the
RM-ODP (and the Information viewpoint focus in particular) would facilitate integration of
the disparate partitions upon completion of the modeling phase.
What emerged were five partition-level models, each in the RM-ODP information viewpoint
that would not integrate. Several efforts to understand and describe the disparities among
the partitions were attempted. In particular, each partition was examined to validate that it
was, in fact, in the RM-ODP Information Viewpoint. Similarly, analysis regarding the
granularity/abstraction of each partition was conducted as part of the efforts to reconcile,
yielding in fruitless results. The group was at a loss to explain the situation.
After some effort, it was discovered the disparity across the “partitions” was contextually
based and not abstraction-based. Although validated as part of the RM-ODP Information
Viewpoint, the group came to understand that the partition-level artefacts were not
consistent in their objectives and/or contextual grounding. As an instance example,
consider “demographics”. Within this space were produced two modeling artefacts: one
identifying the trait set of interest for the GCPR, the other documenting how any arbitrary
trait set could be used as the basis for unique identification. In other words, one model was
defining the information content, the other describing key aspects of unique identification.
Finding this cause however took an unanticipated number of discussions with input from
modeling team members, RM-ODP experts, and others.
Contexts
RM-ODP Viewpoints 
Figure 1.
Based on this understanding, the approach resulting was to add a “depth” dimension to the
RM-ODP viewpoints to tease apart the identified contextual differences. This matrix
successfully explained how the “partitions” fit together. Further, it filled a communicationsgap with the implementation contractor, working as a tool to identify appropriate artefacts
required to successfully describe system requirements.
Given a consensus on the work-products that were identified, requisite supporting
documentation was penned to formally articulate requirements of those work-products.
7
http://www.imc.exec.nhs.uk/hcm/
©Ken Rubin
Page 38 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
This documentation described in detail the artefacts being produced with the intention of
minimizing gaps between delivery and expectation.
The matrix alone is not capable (and is not intended) to solve reconciliation problems
between artefacts at different levels and with differing contexts. Instead, the matrix merely
serves as a vehicle for focusing discussion and attention on the complex interrelationships of
a large, distributed system development environment.
Composition of the Matrix
The previously introduced matrix is a two-dimensional representation containing the RMODP viewpoints across the columns and three “contexts” down the rows. Although brief
descriptions of the RM-ODP viewpoints are provided within the matrix, the authoritative
reference to these is the ISO work itself.
The “contexts” that appear on the matrix are merely those that have proven themselves to
be useful in identifying and differentiating problem spaces. The matrix is not intended to be
normative, so specializations or extensions should be added as-needed to address projectspecific concerns. The default contexts on the matrix include:
Business Functional Context: Describes the business domain. This context has two subcomponents: Granular (fine-grained) and Abstract. The Granular section is intended specify
the detailed content to be addressed, implemented, or carried by the system. The Abstract
section defines artefacts capable of transporting or representing that detailed content (such
as information “containers”). Within this abstract context would include concepts such as
metadata, templates, and/or archetypes of information.
Service Context: Describes the core capabilities required to support the business functional
context described above. This would include items such as common services, technical
architectures, etc.
Implementation Context: Artefacts specifically addressing the [to-be] implemented
system. This context is generally derived from both of the above contexts, but scoped
specifically to those requirements being addressed within the implementation. In other
words, the Business Functional and Service contexts serve as reference-level resources with
potentially broader scope than required for the implementation context. This context
narrows the focus and scope based upon the needs of
the target system being developed.
Though RM-ODP provides
It is important to note that RM-ODP was selected as
the key differentiation mechanism for several reasons.
First, it is based on an internationally accepted standard,
providing a solid foundation from which to build.
Second, RM-ODP does a nice job of identifying and
defining tangible classifications for separating concepts
that are often intermingled in software development
activities. Though RM-ODP provides perhaps the
most generally-applicable and best starting-point for
©Ken Rubin
perhaps the most generallyapplicable and best startingpoint for this approach, the
Taxonomy Matrix itself is not
contingent upon the RMODP.
Page 39 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
this approach, the Taxonomy Matrix itself is not contingent upon the RM-ODP. In fact
some matrix users have already specialized the columns to address more project-specific
concerns, replacing RM-ODP as their choice classification vehicle.
RM-ODP Overview
The ISO Reference Model for Open Distributed Processing (RM-ODP) provides a
framework for the standardisation (and description) of distributed, heterogeneous systems
within and across organisations. The RM-ODP provides the “big picture” necessary to
organize these pieces of a complex distributed system into a coherent whole.8
Within the context of GCPR, RM-ODP provides the fundamental semantics required to
successfully articulate the components of this complex framework environment. RM-ODP
and its components offer the tools required to identify and define both the requirements of
and interactions of complex systems.
The RM-ODP defines within it a series of viewpoints identifying different perspectives
and/or aspects of system development. Within this standard are defined the following (as
described by Raymond):
 Enterprise Viewpoint: focused on purpose, scope and policies for the system;
promoting an understanding of the business environment and its influences upon the
distributed system.
 Information Viewpoint: focused on the semantics of the information and the
information processing performed; essentially the articulation of the business rules and
content to be supported by the system. Addressed within this viewpoint are the static,
invariant, and dynamic behaviors of the system.
 Computational Viewpoint: enables distribution through functional decomposition of the
system. In less precise terms, this viewpoint provides for the logical design of the system
through encapsulation of capability, separation of functionality, and interface definition.
 Engineering Viewpoint: focused on mechanisms and functions to support distributed
interaction between the components of the system. Essentially, this is to determine the
required distribution aspects of the system [for example, the distribution architecture to
be used];
 Technology Viewpoint: focused on the choice of technology to be employed within that
system. This is a description of the implementation of the system and testing
requirements.
Taken collectively, the RM-ODP standard provides a comprehensive collection of
perspectives to describe a complex system. This makes it an appropriate delineation for the
matrix’ premise as a tool to provide for the separation of concerns.
“Reference Model of Open Distributed Processing: Introduction,” Raymond, Kerry, Centre for Information
Technology Research, Undated, University of Queensland.
8
©Ken Rubin
Page 40 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
Using the Matrix
A matrix may be used to address most interest areas.
For each given problem space a matrix would be
instantiated. Generally speaking, a problem space
should have the complexity of a “project” or larger
for this activity to be fruitful, though there is nothing
conceptually restricting its use within smaller scopes.
Since these contexts are
not intended to be
normative, some thought
should be given in defining
the best way to customize
to meet targeted objectives.
Within the identified problem space, particular
attention and consideration must be given to the
default Contexts presented within the template version of the matrix. Since these contexts are
not intended to be normative, some thought should be given in defining the best way to
customize to meet targeted objectives. They often achieve greater value when “tailored,” so
departures to contexts that make sense within a problem space are encouraged. For
example, this may mean the addition of new context, sub-typing of existing contexts, or
removal of contexts that are inappropriate.
It is not necessary to fully populate the matrix. Identifying a cell as “out of scope” is entirely
appropriate. If completing such a cell adds no further value it is best avoided. Similarly, the
level of cell depth or detail is varied as needed—there is no requirement for every cell to be
completed to a consistent depth or granularity. Since this is a tool for understanding,
pragmatism should guide the level of effort.
Artefact identification is another important aspect. One of the best uses of the matrix is to
understand, through instance examples, how both existing and intended artefacts fit
together. Identifying these artefacts and placing them onto view should be one of the key
objectives. The matrix is also used as a springboard to detailed documentation. As a
cautionary note however, it is important to understand that while the matrix itself can be
useful in identifying and sharing understanding of a problem space, it is not sufficient to
that space. Once artefacts are identified
If completing such a cell document
and understandings gleaned, they must be
adds no further value it
documented in more formal deliverables. These may
take the form of artefact description documents,
is best avoided…Since
contractual deliverables, and other products.
this is a tool for understanding, pragmatism
should guide the level of
effort.
Figures 2 and 3 below represent two examples of the
matrix. The first is an “instance example” of the
matrix as applied to global healthcare models. The
second is the “reference version” containing
definitions of each of the cells as relating to the ISO
RM-ODP and the identified “contexts”.
©Ken Rubin
Page 41 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
Who is Using It?
Within the past few months several groups and organisations have applied the taxonomy
matrix to their individual problem spaces. This has been done with varying levels of depth
and with different intentions. While it is still early, the initial experiences have been highly
successful. Additionally, as word of this technique has spread additional groups have
expressed interest in exploring the use of the matrix. The following table lists these
activities:
Group
GCPR
OMG CORBAmed
Veterans Health Administration
Good Electronic Health Record
Initiative (GEHR)
HL7 Government Special
Interest Group
Application
Communications and scoping vehicle to assist in defining work products
and deliverables
“Roadmap” to demonstrate how CORBAmed services and interface
specifications interrelate with healthcare information models
“Crosswalk” effort to understand the interrelationships of healthcare
models available an approach to relate separate concerns in modeling
activities
Application of the matrix is under consideration for applicability.
HL7 Component-based Messaging
Group
UK National Health Service
Conclusion
The conundrum facing systems analysts is to make “method out of madness,” choosing (or
producing) those information sources that add value and ignoring those that do not. The
taxonomy matrix outlined in this paper can serve as a valuable tool in understanding the
landscape and making informed decisions.
Through the identification of relevant contexts, as viewed within the applied ISO reference
model viewpoints, the analyst has available new tools to understand and communicate
artefacts and their relationships.
The taxonomy matrix serves to document a part of the life cycle development process
which has largely been untouched: context. By providing consumers sufficient contextual
basis, better decisions can be made based upon articulated objectives, allowing for
interdependencies to be identified, examined, and explored.
Though the taxonomy matrix approach does not proscribe direct solutions for solving
complex problems encountered in systems development, it does provide a means to a better
understanding of the problem: an interim, essential step towards successful development.
©Ken Rubin
Page 42 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
Bibliography
Government Computer-based Patient Record Project Documentation
(http://www.gcpr.gov )
International Standards Organization Reference Model for Open Distributed Processing
(http://www.iso.ch:8000/RM-ODP)
“Reference Model of Open Distributed Processing: Introduction,” Raymond, Kerry, Centre
for Information Technology Research, Undated, University of Queensland.
Unified Software Development Process; Booch, G., Rumbaugh, J., Jacobson, I.; AddisonWesley, 1999.
Business Specifications, Kilov, H; Prentice Hall, 1998.
Ken Rubin is a senior consultant with Electronic Data Systems, Inc. (EDS) providing system
architecture and object technology support to the Veterans Health Administration
Information Technology Architecture Office and the Government Computer-based Patient
Record Project. Mr. Rubin is an active participant in the Object Management Group within
their Healthcare Domain Technical Committee (CORBAmed) and Health Level Seven
(HL7) standards organisations.
The author would like to acknowledge and give special thanks to the following individuals
for their substantial contribution to this work: Doug Felton (UniMed), Haim Kilov (Genesis
Development Corporation), Jim Demetriades (VHA IT Architecture Office), Tom Beale
(Deep Thought Informatics), Lt. Col. Janet Martino (U.S. Air Force, Military Health System),
OMG’s CORBAmed Domain Task Force, the VA IT Architecture Office, and the entire
GCPR Reference Modeling Team.
The opinions expressed herein are solely those of the author and do not necessarily reflect the opinions of the GCPR
Project, the Veterans Health Administration, or Electronic Data Systems.
The work represented in this white-paper was funded as part of modeling activities within the U.S. Government Computer-based Patient Record
Project and the Veterans Health Administration Information Technology Architecture Office.
Comments can be directed to ken.rubin@acm.org and are welcomed.
©Ken Rubin
Page 43 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
<subtype as needed>
Implementation
Context13
Service
Context12
Abstract
(form)11
Granular
(content)10
Business Functional Context9
Description
Healthcare Standards Roadmap Matrix v2.0
Viewpoint
Enterprise
Technology
Information
Formalized scope, business purpose,
policies, impacts of the system.
Includes the roles played, activities
under-taken, and policy statements
about the system.
Choices of specific HW, SW, constraints
to assure compliance with other viewpoints;
identification of conformance points,
implicit or explicit, resulting from technical
choices
Defines the information and
relationships, information semantics, and
information processing requirements of the
system. Includes static, dynamic, and
invariant schemas.
Identification of those
components of the healthcare
domain impacting
information interchange and
interoperability
Not proscribed so as to be able to
support a multiplicity of
technologies and paradigms.
-FAM-D
-HL7 RIM
-HL7 USAM
-Canadian Health Data Model
-Australian NHIM
-POMA
-UK NHS HcM
Representation of highlygranular components capable
of encapsulating, transporting,
and/or representing the
content of information
models
Should be suitable for a variety of
technologies: in particular messageoriented middleware and distributed
object technologies.
Common services Supporting
the Reference Domain
Specification.
Requirements, scope, and
objectives of an
implementation.
Computational
Engineering
Structures, concepts, interaction rules, for
the specification + functional
decomposition into objects. Includes
bindings, interface specifications,
environment contract behaviour, and
transparencies.
-HL7 Use Cases
-COSMOS Model
-FAM-A
The expression of the way [object]
inter-action is achieved and the
resources needed to do so: primarily
the support of the interactions
between computational objects.
-HL7 PRA Metamodel
-CEN TC-251 EHCR PRA
-GCPR PRA Model
-HL7 Clinical Template Mdls
-GEHR Archetypes
ISO 11179 Compliant Metadata
-HL7 Clinical Templates
-HL7 XML PRA
Technological paradigm in which
the services are to be implemented
(e.g., messages, distributed objects,
etc.)
-CORBAmed Info Models
-CCOW Standard
-GEHR Object Model
-GEHR Object Model
-CORBAmed (Signatures,
mandatory/optional requirements)
Normative Interface
Definitions (IDL)
Technology instances on which the
implementation is to be based (e.g.,
COTS products, platform, etc.)
Logical Database Design
HL7 RIMs
Service Design Specifications (e.g.,
CORBAmed services)
VHA Data Registry Design
HL7 MDF
GEHR Kernel
HL7 2.x messages
HL7 3.x messages
CORBAmed Services
GCPR Framework
CCOW Implementations
Space
Modeling Formalizations
UML, USDP products
RM-ODP Viewpoints
9
Documentation of the problem space, domain of interest, functional requirements etc.
.Artifacts, products, etc. with the objective of identifying, describing, and/or relating business functional components at a granular level.
11
Artifacts, products, etc. with the objective of identification of abstractions, meta-models, etc. (e.g., generalization of the granular models, templates defining structure of granular models, “containers”
capable of transporting details, etc.
12
The component services required to support needs/content as identified by the business functional context, (or services implicit in supporting and/or managing that content).
13
Work products developed with the intention of building implementable systems. Draws from other contexts as scoped to address requirements for a targeted implementation
10
©Ken Rubin
Page 45 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
Subtype as
needed
Implementation
Service
Context
Abstract(Form) Granular (Content)
Business Functional Context Description
Taxonomy Reference Matrix v2.0
Viewpoint
Enterprise
Space
Formalization of the business
purpose, scope, policies, impacts
of the system. Includes the roles
played by, activities under-taken
by, and policy statements about
the system (including relevant
contracts).
Describes purpose, scope,
policy, etc., particularly org.
issues.
Technology
Articulation of the choices of
specific hardware, software
constraints assuring compliance
with the other viewpoints;
identification of conformance
points implicit or explicit as a
result of the technology choices.
Since the scope of the domain
context is primarily content
definition, there are no
technology viewpoint constraints.
Information
Defines the information and
relationships, information semantics,
and information processing
requirements of the system. Includes
static, dynamic, and invariant
schemas.
Information defined by, required of,
or identified in the enterprise view.
Includes entities, states, semantics,
relations, etc.
Computational
Engineering
Structures, concepts, interaction
rules, for the specification/
functional decomposition into
objects. Includes bindings,
interface specification,
transparencies, and environment
contract behaviour.
Domain triggers, relationships, use
cases pertaining to the healthcare
business domain.
The expression of the way
[object] interaction is achieved
and the resources needed to
do so: primarily the support
of the individual interactions
between computational
objects.
Work products in formal
notation (UML, OCL, ASN1,
etc.), formal models,
diagrams, text.
Terminology to include concept
formation, definition, system
Requirements of the
representation format
(evidentiality, currency, etc.)
Terminology including term
& symbol specification, termconcept assignment
(Archetype defining the
representation metamodel?)
Metamodel of information content
and its representation (e.g., PRA,
terminological modeling, etc.)
Terminology Work
- term specification
- symbol specification
- term-concept assignment
- Metadata Registries
Controlled Vocabularies and
codesets, lexicons, etc.;
clinical templates
Common services Supporting
the Reference Domain
Specification.
Technological paradigm in which
the services are to be
implemented (e.g., distributed
objects, messages, etc.)
Service definition, list, information
requirements and parameters. Akin to
CORBAmed services’ info models.
Specifications at a low level of
detail highlighting interaction
between the services or
subsystems.
Means by which to forward
interests to SDOs addressing
interoperability services.
Requirements, scope, and
objectives of the implementation
Paradigm and COTS
infrastructure environment (e.g.,
ORB, messaging standard – HL7
2.x, etc.)
Products supporting the instantiation
of the Ref. Domain Representation.
Products supporting the Reference
Domain and Service contexts as
scoped by system activities.
System products, e.g.
executables, training
(Draw from PRA definition,
only more generalized)
Scope
RM-ODP Viewpoints
©Ken Rubin
Page 46 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
7
OMG Support
7.1 Introduction
The purpose of this focus activity is to ensure consistency and support of
healthcare domain requirements with existing and future OMG specifications. It
will also be a forum for expressing healthcare requirements to existing and future
OMG specifications.
7.2 Specific Work Items
General work items within this focus activity identified to date include:
 Identify and evaluate appropriate OMG specifications
 Participation in the Domain Technical Committee (DTC)
 Observation of the OMG Architecture Board (AB) activities
 Participation in Platform Technical Committee (PTC) task forces
Specific work items include:
 Unifying CORBAmed frameworks / interfaces with related OMG activities
 Working with the Business Objects Domain Task Force (BODTF) to develop a
unifying OMG domain model
 Alignment with workflow specifications
 Evaluation of the CORBA security service
 Evaluation of the Notification Service
7.3 Deliverables
Anticipated deliverable produced by this focus activity include:
 Documented conflicts / gaps / overlaps / acceptances
 Revisions to OMG DTC (and possibly PTC) specifications
 Revisions to healthcare domain specifications
Page 47 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
8
OMG Policy and Procedure
The OMG Process FAQ – “Facts About Major OMG Technology Processes” can
be found at http://www.omg.org/techprocess/faq_process.html.
8.1 Explanation of the OMG RFI Process
Requirements Elaboration activities are achieved primarily through the issuance
of Requests for Information (RFIs). The OMG RFI process does not directly lead
to technology adoption. RFIs are used by task forces to solicit general
information from the industry. Both OMG members and non-members can
respond. Submissions may include information about relevant technologies,
products, standards, research, requirements, and other guidance for the task
force.
RFIs are recommended by CORBAmed to the Architecture Board (AB) and
Domain Technical Committee (DTC) for issuance. RFIs are usually created
whenever information is needed by the task force or a collaborating group to
solicit information about industry requirements. In some cases, CORBAmed will
issue an RFI in order to define industry requirements for key OMG technology
and to help locate potential technology sources for fast track adoption.
There are no restrictions on who may respond to an RFI. RFI responses are
evaluated by members of the CORBAmed and are used to guide the group’s
activities. Restrictions are placed on the voting process, however. A DTC
member must be at least at the Domain Contributing Member (DCM) level in
order to vote for issuance of a RFI.
The following timetable shows a typical schedule of events for a CORBAmed
RFI. The duration is approximate. An exact schedule (with specific dates) is
established for each RFI.
Day
Event / Activity
RFI review (“Three week rule”)
Vote by CORBAmed to issue RFI
0
Vote by AB and DTC to issue RFI
Preparation of submissions
120
Submissions due
Review of RFI responses by CORBAmed
150
Evaluation report by CORBAmed
TYPICAL RFI PROCESS TIMETABLE
Page 48 of 60
Duration
21 days
120 days
30 days
OMG CORBAmed Roadmap – Version 2.0 (draft)
8.2 Explanation of the OMG RFP Process
The OMG Request for Proposal (RFP) process entails a solicitation for
technology proposals, followed by revision, evaluation, selection, and approval
processes. CORBAmed evaluates the RFP submissions and revised
submissions. CORBAmed then selects specifications (by vote of members who
are at least at the Influencing or Government Member level) which it
recommends to the DTC and AB. OMG members who are at least at the Domain
Contributing Member (DCM) level then vote to recommend adoption. The
Architecture Board (AB) review normally precedes the DTC vote. The final step is
to forward the proposal to the OMG Board of Directors (BoD) for final approval.
Adopted specifications are then available for use by OMG members and nonmembers alike.
Following the conventions established by the other OMG task forces,
CORBAmed will use a three step process for handling submissions. This
process can be altered by consensus of CORBAmed.
8.2.1 Submissions
OMG members who are at the least at the DCM level can submit a proposed
specification in response to an RFP. Submitters must send a Letter of Intent
(LOI) to the OMG declaring their commitment to commercialise the technology. If
an organisation is not at the DCM level, they may upgrade their membership to
either DCM (or Contributing Member) prior to submission. Groups of DCM
and/or Platform Contributing Members may submit in teams, representing multivendor alliances and external consensus. Other organisations, which are not cosubmitters, may be identified in the proposal as supporters of a technology.
The RFP will establish a submission deadline for the full technology
specifications.
8.2.2 Revised Submissions
There will be a subsequent deadline for revised submissions. This revision
process encourages mergers of submissions. An organisation must have
submitted an initial submission in order to participate in a revised submission. For
revised submissions, a date by which a working implementation will exist is
required.
8.2.3 Specification Selection
After revised submissions are received, the CORBAmed will select (through
evaluation) a single specification for each RFP item. Specifications may be
conditionally accepted subject to minor changes to be made by the submitter. In
most cases, the CORBAmed will establish a revision process to improve
specifications in terms of clarity or correctness. Major changes to selected
specifications will only take place during a later RFP or RFC-driven enhancement
cycle.
Page 49 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
A specification selected by CORBAmed is then endorsed by the Architecture
Board, Domain Technical Committee and Board of Directors.
The CORBAmed RFP process will typically follow the timetable shown below:
Day
Event / Activity
RFP Review (“Three week rule”)
Vote by CORBAmed to issue RFP
0
AB and DTC votes to issue RFP
Preparation of submissions
60
LOI to submit to RFP due
90
Voting registration for CORBAmed members closed
120
Submissions due
Preliminary evaluations by CORBAmed and
preparation of revised submissions
240
Revised submissions due
Specification selection by CORBAmed
300
CORBAmed votes to select specifications
Review by AB and DTC (“Three week rule”)
AB and DTC votes to recommend specification
BoD review
360
BoD votes on specification adoption
TYPICAL RFP Process Timetable
Duration
21 days
120 days
120 days
60 days
21 days
Please note that duration noted above is approximate. The exact schedule (with
specific dates) for each RFP will be established on an RFP-by-RFP basis and
documented in the RFPs.
Page 50 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
8.3 Explanation of the OMG RFC Process
The OMG Request for Comment (RFC) process is a fast track adoption process
that uses an industry comment period. The RFC process includes the following
steps:
 The OMG RFC process starts with an unsolicited technology proposal
submitted by one or more OMG members who are at least at the Domain
Contributing Member (DCM) level to the CORBAmed. If an organisation is
not at the DCM level, they may upgrade their membership to DCM (or
Contributing Member) at any time prior to submission.
 A presentation and vote on the RFC can be scheduled for a particular
CORBAmed meeting by one of the CORBAmed co-chairs. The technology
proposal should be available to CORBAmed members three weeks prior to
this meeting. At the meeting, the role of the submitters is to convince the
CORBAmed to recommend the proposal for OMG review. A CORBAmed
member must be at least at the Influencing or Government Member level in
order to vote.
 After the CORBAmed recommendation, the Architecture Board and Domain
Technical Committee votes to release the RFC, starting the public comment
period. DTC members must be at least at the DCM level of membership in
order to vote.
 The RFC comment period is 90 days. Any OMG member or non-member
may comment. OMG staff can stop the RFC process if they determine that
significant negative comment has been received.
 After the comment period, the AB and DTC vote for technology adoption. A
DTC member must be at least at the DCM level in order to vote.
The final step is OMG Board of Directors (BoD) approval.
CORBAmed encourages the use of the RFC process because it consumes fewer
resources than a comparable RFP process. CORBAmed offers the following
guidance to potential submitters:
 The submitters should be confident that the proposal will survive the RFC
period without significant comment.
 If there is an external industry group that covers the proposal’s technology
area, it would be highly desirable if the submission represents an industry
consensus from the external group.
 The submitters should consider soliciting feedback from CORBAmed prior to
submission. Most potential submitters give a presentation to CORBAmed and
disseminate a pre-submission draft of the specification for review. The early
review can surface potential problem areas. This optional step can greatly
enhance the chances of successful technology adoption.
Page 51 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
The following timetable shows a typical schedule of events for a CORBAmed
RFC process. The duration is approximate. Exact schedules (with specific dates)
are established for each RFC.
Day
0
90
120
Event / Activity
Formal submission of full specification for review by
CORBAmed, AB and DTC (“Three week rule”).
Vote by CORBAmed to issue RFC for OMG review
Vote by AB and DTC to release RFC for OMG
review
Review period – comments from industry
CORBAmed votes to recommend specification
AB and DTC votes to recommend specification
BoD review
BoD votes on specification adoption
TYPICAL RFC PROCESS TIMETABLE
Page 52 of 60
Duration
21 days
90 days
30 days
OMG CORBAmed Roadmap – Version 2.0 (draft)
9
Appendices
9.1 Appendix A: Healthcare DTF Three-Year Plan
This appendix summarises the Healthcare Domain Task Force activity for the
three years commencing 1999.
1999
2000
2001
Roadmap version 1.0 released
Roadmap version 2.0 –
incorporation of CORBAmed
Service-based Architecture for
Healthcare.
CORBAmed Toolkit 2.0
release
Complete
Roadmap version 3.0
CORBAmed Toolkit 1.0
released
Person Identification Service
Implementations
Terminology Query Service
Implementations
Clinical Observation Access
Service (COAS) Technology
Adopted
Resource Access Decision
(RAD) Technology Adopted
Summary List Information
Management Service (SLiMS)
RFP issued
CORBA/M RFI response
review
Pharmacy RFI issued and
responses evaluated
Pharmacy Disease
Management Service RFP
issued
Pharmacy Drug Therapy
Management Service RFP
issued
Card Management Service
RFP issued
CORBAmed Toolkit 3.0
release
Complete
Clinical Observation Revision
Task Force
Complete
Resource Access Decision
(RAD) Revision Task Force
Clinical Image Access Service
(CIAS) Technology Adoption
Medical Transcription
Management (MTM)
Technology Adoption
Order Management Service
RFP issued
Health Information Locator
Service (HILS) RFP issued
Complete
Clinical Image Access Service
(CIAS) Revision Task Force
Medical Transcription
Management (MTM) Revision
Task Force
Order Management Service
Technology Adoption
Health Information Locator
Service (HILS) Technology
Adoption
Summary List Information
Management Service (SLiMS)
Technology Adoption
CORBA/M RFP issued
Pharmacy Disease
Management Service RFP
Technology Adoption
Pharmacy Drug Therapy
Management Service RFP
Technology Adoption
Card Management Service
Technology Adoption
Healthcare Data Interpretation
Facility Technology Adoption
Page 53 of 60
Healthcare Data Interpretation
Facility Revision Task Force
OMG CORBAmed Roadmap – Version 2.0 (draft)
Healthcare Administrative
Logistic Financial and
Enterprise Management
(HALFEM) RFI response
review
Healthcare Administrative
Logistic Financial and
Enterprise Management series
of RFP’s issued:
Encounter Management RFP
Enterprise Management RFP
Financial Services including:
Enrolment Management
Service RFP
Eligibility Service (US specific)
RFP (?)
Charge Capture Management
Service RFP
Authorization Management
Service RFP
Referral Management Service
RFP
Claims Management Service
RFP
Remittance Management
Service RFP
Credential Verification
Authority Management Service
RFP issued
Laboratory Information Access
Service RFP issued
Medical Device Information
Access Service RFP issued
Point of Care Information
Access Service RFP issued
Authoring Management
Service (XML) RFP issued
Other RFI and RFP issuance
as the requirement of the
industry dictate. Decision
Support and Security
workgroups continually
formulate requirements for the
issuance of further RFP and
Technology Adoption.
Table 8. CORBAmed Three-Year Plan
Page 54 of 60
HALFEM Technology
Adoptions
OMG CORBAmed Roadmap – Version 2.0 (draft)
9.2
Appendix B: Acronyms and Abbreviations
AB
Architecture Board
BoD
Board of Directors
BODTF
Business Object Domain Task Force
DCM
Domain Contributing Member
DTC
Domain Technical Committee
DTF
Domain Task Force
HcM
Healthcare Model
IDL
Interface Definition Language
ISO
International Organisation for Standardisation
LOI
Letter of Intent
PTC
Platform Technical Committee
RFC
Request for Comment
RFI
Request for Information
RFP
Request for Proposal
SIG
Special Interest Group
Page 55 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
9.3
Appendix C: References
[ISO 94]
International Organisation for Standardisation. ISO 10301-11:1994.
[ISO 96]
International Organisation for Standardisation. “Interface Definition
Language (IDL) Binding to the Standard Data Access Interface (SDAI)
Specification”. ISO 10303-26. 1996.
[OMG 94]
Object Management Group. Policies and Procedures of the OMG
Technical Committee, Document Number 1994/94-04-14. Framingham, MA:
Object Management Group, 1994.
[OMG 95]
Object Management Group. Object Management Architecture
Guide, Version 3.0. Framingham, MA: Object Management Group, 1995.
[OMG CF 95] Object Management Group. Common Facilities Roadmap, Revision
3.2. Document Number 1995/95-01-32. Framingham, MA: Object Management
Group, 1995.
Page 56 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
9.4 Appendix D: Contacts
RFI1 – CORBAmed RFI
??
RFI2 - Clinical Observation Access Service (COAS)
Tim Brinson - Protocol Systems - tim@protocol.com
RFI3 - Clinical Decision Support
Dave Kilman – Theragraphics - dave@theragraphics.com
RFI4a Health Level 7 (HL7)
??
RFI4b Lifesciences
??
RFI5 – CORBA/Mumps Interoperability (CORBA/M)
??
RFI7 – Healthcare, Administrative, Logistical, and Financial Encounter
Management (HALFEM)
Eric Butler - BHS - Ericb@baptisthealth.net
RFP1 – Patient Identification Service (PIDS)
Tom Culpepper - 3M - tcculpepper@wpmail.code3.com
RFP2 – Lexicon Query Service (LQS)
Tom Culpepper - 3M - tcculpepper@wpmail.code3.com
RFP3 – Pharmacy Interaction Facility
Erick Hagstrom – Envoy - mailto:Erick.Hagstrom@envoy.com
RFP4 – Clinical Observation Access Service (COAS)
Tom Culpepper - 3M - tcculpepper@wpmail.code3.com
RFP5 – Healthcare Resource Access Control (HRAC)
Konstantin Beznosov - BHS - beznosov@baptisthealth.net
RFP6 – Healthcare Data Interpretation Facility (HDIF)
Dave Kilman - Theragrapics - dave@theragraphics.com
RFP7 – Clinical Image Access Service (CIAS)
Yassar alSafadi - Philips Research - yha@philabs.research.philips.com
Page 57 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
9.5
Appendix E: CORBAmed Mission and Goals
CORBAmed is the Healthcare Domain Task Force of the OMG, the Object
Management Group, a non-profit international organisation based near Boston,
and indented to the promotion of Object Oriented methodologies. The main
product of the OMG is the CORBA standard, "Common Request Broker
Architecture." The CORBA architecture has a broad range of applications in
many application domains. Task Forces deal with the specific aspect of various
application domains, who have common interest in the same interface
technologies. Task Forces are specialised in various domains as Electronic
Commerce, Manufacturing, etc... and CORBAmed in health care applications.
CORBAmed defines standardised interfaces to many healthcare "Object
Oriented Services," across most usual platforms, and available in the public
domain. CORBAmed is important for health care organisations and end users,
because it provides compatibility to a much wider range of software components.
It is important for software providers because it provide access to a much larger
market for specialised services.
Mission
 To improve the quality of care and reduce costs by use of CORBA
technologies for interoperability throughout the global healthcare community
 To utilise the OMG technology adoption process to standardise interfaces for
healthcare objects
 To communicate the requirements of the healthcare industry to the Platform
Technical Committee
 To assist and advise the Liaison Subcommittee regarding the relationship
with healthcare standards organisations and consortia.
Goals
 To educate both the system developers and the user community in the health
care industry
 To issue RFIs and RFPs related to the healthcare industry based on CORBA
technologies
 To evaluate RFI and RFP responses and RFCs for recommended adoption
by the Domain Technical Committee.
The CORBAmed Task Force
The Healthcare systems of the developed world are at a critical point. Dramatic
changes in the way healthcare agencies and medical professionals work together
are
Page 58 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
required to retain positive cash flows while maintaining high standards of patient
care. The problems and concerns of every healthcare organisation are well
known:
Competitive Pricing has become a pressing reality with new business
practices being instituted by insurance companies and reductions in
government insurance programs.
Ubiquitous Lifetime Records are required now that patients obtain
services from many different locations within any given healthcare
organisation.
Lack of Computing Interoperability presents serious issues for hospitals
using varied devices, instruments and systems that collect and maintain
patient information.
Times and technologies have changed and the successful healthcare
organisation will be the one that can address these issues while also keeping in
mind the need for patient record confidentiality. And the Object Management
Group, in conjunction with concerned technologists in the Healthcare industry,
has forged an alliance to address these very issues. With the formation of OMG's
CORBAmed Task Force, the computer industry has taken a stand. The
CORBAmed objective is to improve Healthcare delivery by:






Promoting interoperability among healthcare devices, instruments and
information systems using CORBA technology.
Expanding the awareness and use of CORBA technologies by healthcare
organisations to ensure industry interoperability.
Improving the quality of care and reducing costs through the use of CORBA
Supporting the reliable and secure sharing of medical information among
healthcare organisations.
Using the OMG technology adoption process to standardise interfaces for
healthcare objects.
Working with international standards organisations to develop and promote
interoperability in the healthcare industry.
You are invited to join this dedicated group in their mission to solve the critical
problems facing Healthcare IT professionals. Meetings are being held to discuss
a range of topics in an open and productive forum. Find out how you can help
drive the changes that will allow your organisation to stay competitive in an
increasingly complex market. You'll learn how OMG's CORBA specification can
help solve the problems of interoperability and security.
OMG and CORBAmed invite you to join them in their mission of bringing true
interoperability to the healthcare industry. CORBAmed meets in conjunction with
scheduled OMG Technical Committee meetings.
Page 59 of 60
OMG CORBAmed Roadmap – Version 2.0 (draft)
9.6
Appendix F – OMG Background
The Object Management Group (OMG) was founded in May 1989 by eight
companies: 3Com Corporation, American Airlines, Canon, Inc., Data General,
Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems and
Unisys Corporation. In October 1989, OMG began independent operations as a
non-profit corporation. Through the OMG's commitment to developing technically
excellent, commercially viable and vendor independent specifications for the
software industry, the consortium now includes over 800 members. As OMG
moves forward in establishing CORBA as the "Middleware that's Everywhere"
through its world-wide standard specifications: CORBA/IIOP, Object Services,
Internet Facilities and Domain Interface specifications. OMG is headquartered in
Framingham, Massachusetts, USA, with international marketing partners in the
UK, Germany, Japan, India and Australia.
OMG was formed to create a component-based software marketplace by
hastening the introduction of standardised object software. The organisation’s
charter includes the establishment of industry guidelines and detailed object
management specifications to provide a common framework for application
development. Conformance to these specifications will make it possible to
develop a heterogeneous computing environment across all major hardware
platforms and operating systems. Implementations of OMG specifications can be
found on over 50 operating systems across the world today. OMG's series of
specifications detail the necessary standard interfaces for Distributed Object
Computing. Its widely popular Internet protocol IIOP (Internet Inter-ORB Protocol)
is being used as the infrastructure for technology companies like Netscape,
Oracle, Sun, IBM and hundreds of others. These specifications are used worldwide to develop and deploy distributed applications for Manufacturing, Finance,
Telecoms, Electronic Commerce, Realtime systems and Health Care.
OMG defines object management as software development that models the real
world through representation of "objects." These objects are the encapsulation of
the attributes, relationships and methods of software identifiable program
components. A key benefit of an object-oriented system is its ability to expand in
functionality by extending existing components and adding new objects to the
system. Object management results in faster application development, easier
maintenance, enormous scalability and reusable software.
The acceptance and use of object-oriented software is widespread and growing.
Virtually every major provider and user of computer systems in the world is either
using or planning to implement object-oriented tools and applications. Within the
next three to five years, revenue from the sale of object-oriented software is
projected to exceed three billion dollars.
Find out more via http://www.omg.org.
Page 60 of 60