Object Management Group€¦ · Web view250 First Avenue, Suite 201 Needham, MA 02494, USA. Telephone: +1-781 444 0404. Facsimile: +1-781 444 0320. The CORBAmed Roadmap. CORBAmed:

OMG CORBAmed Roadmap – Version 2.0 (draft)

Object Management Group250 First Avenue, Suite 201Needham, MA 02494, USA

Telephone: +1-781 444 0404Facsimile: +1-781 444 0320

The CORBAmed Roadmap

CORBAmed: The OMG Healthcare Domain Task Force

OMG Document Number CORBAmed/2000-05-01http://www.omg.org/docs/corbamed/2000-05-01.doc

Version 2.0 (draft)21 May 2000

1 of 60

http://www.omg.org/docs/corbamed/00-xx-xx.doc


Revision History & Document Evolution PlanningVersion Release Date Description0.1 November 8,

1998Reviewed by Roadmap Working Group prior to Burlingame Technical Meeting.

1.0 December 14, 1998

1.0a December 18, 1998

Updated CHST to version 3.0.Incorporate changes suggested by Erick Hagstrom

1.0b Washington DC Meeting, January 13, 1999

To be voted by CORBAmed plenary to be an official document

2.0 Post Denver Meeting, March 2000

Replaced CHST with the CORBAmed Service-based Architecture for Healthcare, updated lists of adopted technologies and technologies undergoing adoption. Also general editing and improvement.

2 of 60


Table of Contents

1 EXECUTIVE SUMMARY......................................................................................5

2 Introduction..................................................................................................82.1 CORBAmed Roadmap Charter..................................................................82.2 Intended Audience......................................................................................82.3 Purpose of the CORBAmed Roadmap.......................................................92.4 Liaison Activity............................................................................................92.5 Domain Architecture...................................................................................9

3 Business Case............................................................................................103.1 The State of Healthcare Informatics.........................................................103.2 The Distributed Object World in Healthcare.............................................113.3 Breadth of Applicability.............................................................................143.4 Return on Investment of using CORBAmed.............................................14

4 Adopted Specifications and Specification Development (RFPs)...........154.1 Introduction...............................................................................................154.2 Specific Work Items..................................................................................154.3 Deliverables..............................................................................................154.4 OMG/CORBAmed Specifications Scorecard............................................164.5 Adopted Specifications.............................................................................17

4.5.1 Person Identification Service (PIDS).................................................174.5.2 Terminology Query Services (TQS)..................................................184.5.3 Healthcare Resource Access Decision (RAD)...................................194.5.4 Clinical Observations Access Service (COAS)..................................204.5.5 Clinical Image Access Service (CIAS)...............................................20

4.6 Current Work Items...................................................................................224.6.1 Healthcare Information Locator Service (HILS) RFP.........................224.6.2 Summary List Information Management (SLiMS) RFP......................224.6.3 Medical Transcription Document Management (MTM) RFP.............224.6.4 Healthcare Data Interpretation Facility (HDIF) RFP..........................23

5 Requirements Elaboration (Requests for Information - RFIs)................245.1 Introduction...............................................................................................245.2 Specific Work Items..................................................................................245.3 Deliverables..............................................................................................245.4 Past Work Items.......................................................................................25

5.4.1 The CORBAmed RFI.........................................................................255.4.2 CORBA and HL7 - Approaches and Considerations RFI..................265.4.3 Lifesciences RFI................................................................................275.4.4 CORBA/M Interoperability RFI..........................................................285.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


6.1 Introduction...............................................................................................316.2 Charter for SeRAH....................................................................................316.3 Structure of SeRAH..................................................................................316.4 The CORBAmed Service-based Architecture for Healthcare (SeRAH)....33

6.4.1 SeRAH Part1: The CORBAmed Applications Template....................336.4.1.1 Provider View – Direct Service Provision...........................................................................336.4.1.2 Clinical Systems Developer’s View....................................................................................346.4.1.3 Provider View – Billing.......................................................................................................356.4.1.4 Payer View.........................................................................................................................35

6.4.2 SeRAH Part2: The Reference Architecture.......................................36

7 OMG Support..............................................................................................477.1 Introduction...............................................................................................477.2 Specific Work Items..................................................................................477.3 Deliverables..............................................................................................47

8 OMG Policy and Procedure.......................................................................488.1 Explanation of the OMG RFI Process.......................................................488.2 Explanation of the OMG RFP Process.....................................................49

8.2.1 Submissions......................................................................................498.2.2 Revised Submissions........................................................................498.2.3 Specification Selection......................................................................49

8.3 Explanation of the OMG RFC Process.....................................................51

9 Appendices.................................................................................................539.1 Appendix A: Healthcare DTF Three-Year Plan.........................................539.2 Appendix B: Acronyms and Abbreviations................................................559.3 Appendix C: References...........................................................................569.4 Appendix D: Contacts...............................................................................579.5 Appendix E: CORBAmed Mission and Goals...........................................589.6 Appendix F – OMG Background...............................................................60

4 of 60


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


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 guidance. This logical representation is based on the ISO Reference Model

6 of 60


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


2 Introduction

2.1 CORBAmed Roadmap CharterIn 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 AudienceThere 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


2.3 Purpose of the CORBAmed RoadmapThe 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 ActivityCORBAmed 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 ArchitectureThis document, including the CORBAmed Service-based Architecture for Healthcare is intended to be a step upon the path to create a Domain Architecture for Healthcare. Whilst it is already clear what such a Domain

9 of 60


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 InformaticsTo 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: managed care directly challenges this assumption which is one likely reason why

10 of 60


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 HealthcareThe 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 the early 1990s produced a similar effect (although these have been partially

11 of 60


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.

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) Scheduling

12 of 60

Workflow Mgmt

Healthcare Record

Scheduling Person Id

Access Control

Order entry

PACS radiology PACS

cardiology

Lab.

PharmacyOrder entry

MPI

Billing

Departmental View Enterprise View

Figure – The changing paradigm of Health Informatics

Present Future


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. Healthcare Financial Services

The present work of CORBAmed is related to many of these business areas.

13 of 60


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 ApplicabilityThe 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. 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.

2. CORBAmed services do not force users to adapt to software that is designed for administrative and commercial methods that are different from their own.

3. 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


4 Adopted Specifications and Specification Development (RFPs)

4.1 IntroductionThe 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


4.4 OMG/CORBAmed Specifications ScorecardThe 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.

3M Care Innovation (Enterprise Master Person Index)Care Data Systems (Correlation Channel)Protocol Systems (Acuity®)

Terminology Query Service (TQS)

Adopted Service used to access terminological information for use in mediation, presentation and dynamic discovery.

3M Care Innovation (Health Data Dictionary bundled with their CDR)

Resource Access Decision (RAD)

Adopted Service used to obtain authorisation decisions and administrating access decision policies for medical information.

Care Data Systems(In progress)2AB/DASCOM(In progress)

Clinical Observation Access Service (COAS)

Adopted Service used to retrieve clinical information about a person.

3M Care Innovation Clinical Data Repository(In Progress)

Clinical Image Access Service (CIAS)

Adopted Service used to retrieve and manage images.

Health Information Locator Service (HILS)

Current Work Item – RFP Issued

Service that will be used to locate medical information.

Summary List Management Service (SLiMS)


Service used to manage medical summary lists.

Medical Transcription Document Management (MTM)


Service to transcribe clinical information.

Healthcare Data Intpretation Facility (HDIF)


Component of clinical decision support.

Order Management Service (OMS)

Current Work Item – RFP Issue planned

Serviced used to mange orders within a medical environment.

16 of 60

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


Enterprise Master Person Indexxxxxxxxxxx3M Care Innovation 575 West Murray BoulevardMurray, UT 84123-4611+1 801 265 [email protected]

Correlation ChannelJon FarmerCare Data Systems, Inc.3500 Deepwoon LaneLambertville, MI 48144+1 734 856 [email protected]

Acuity®Steven TuftyProtocol Systems, Inc.8500 SW Creekside PlaceBeaverton, OR 97008-7107+1 503 526 [email protected]

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 machine-readable 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

mailto:[email protected]




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 Dictionaryxxxxxxxxxx3M Care Innovation 575 West Murray BoulevardMurray, UT 84123-4611+1 801 265 [email protected]

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 FarmerCare Data Systems, Inc.3500 Deepwoon LaneLambertville, MI 48144+1 734 856 [email protected]

Page 19 of 60




xxxxxxxxxxx2AB/DASCOMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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:

xxxxxxxxxx3M Care Innovation 575 West Murray BoulevardMurray, UT 84123-4611+1 801 265 [email protected]

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, image-related 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 HuPhilips Research345 Scarborough Road

Page 20 of 60



Briarcliff Manor, NY 10510 USA+1 914 945 [email protected]@philabs.research.philips.com

Christian ZapfSiemens Health ServicesHenkestr. 127D-91052 Erlangen, Germany+49 91 31 84 [email protected]

Page 21 of 60





4.6 Current Work ItemsThe principal work items in this focus activity are related to the issuance and evaluation of RFPs.

4.6.1 Healthcare Information Locator Service (HILS) RFPThe 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) RFPThis 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) RFPThe management of documents throughout an organization requires tightintegration and strong communication among multiple entities.Historically, manual interfaces, proprietary interfaces, and HL7 (HealthLevel 7) messaging have met these needs. However, these solutionshave only been partial, and are proving inadequate in today's complexhealthcare environments. Standardized object interfaces promise toprovide a solution which not only preserves the current modes ofdocument management, but also provides a solid, long-term technical

Page 22 of 60

http://www.omg.org/docs/corbamed/99-03-27.doc



framework to build the next generation of healthcare informationsystems.

This RFP solicits proposals for document management facilitiescompatible with the COAS (CORBAmed Clinical Observation AccessService). Such facilities will provide mechanisms to access medicaldocuments and related meta-data in a manner that supports theworkflow 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) RFPThis 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.


Page 23 of 60


http://www.omg.org/docs/corbamed/98-04-03.pdf


5 Requirements Elaboration (Requests for Information - RFIs)

5.1 IntroductionThe 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 ItemsWork 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 DeliverablesAnticipated 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


5.4 Past Work ItemsThis 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 RFISummary 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


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 RFISummaryCORBAmed 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


http://www.omg.org/docs/corbamed/98-01-05.rtf : Hewlett-Packard Response to the HL7 RFI

5.4.3 Lifesciences RFI SummaryCORBAmed 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


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 RFISummaryCORBAmed 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


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 Multi-Programming 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)

SummaryCORBAmed 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


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

http://www.omg.org/docs/corbamed/99-02-03.rtf

6 CORBAmed Service-based Reference Architecture for Healthcare (SeRAH)

6.1 IntroductionThe 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 SeRAHSeRAH 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


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


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 ProvisionHere, 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.


Resource Access ControlServiceHealth

InformationLocatorService

Terminology Query

Service

Clinical Image

AccessService

PersonIdentification

Service

Clinical Observation

Access Service

Order EntryService

Order Management

Service

Medical Transcription

Service

Summary List Management

Service

Person Demographic

Service

Party Management

FacilityHealthcare

RelationshipService

Provider View – Direct Service Provision

Charge Capture

ManagementService

EligibilityService

LEGEND

Adopted

RFP

Pre-RFP

RFI


6.4.1.2 Clinical Systems Developer’s ViewHere 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.


Resource Access ControlService

HealthInformation

LocatorService

Terminology Query

Service

Clinical Image

AccessService


Service

Clinical Observation

Access Service

Order EntryService

Order Management

Service

Person Demographic

Service

Party Management

Facility

Healthcare Relationship

Service


6.4.1.3 Provider View – BillingThis 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).

6.4.1.4 Payer ViewHere 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.



ServiceRemittance

ManagementService

Charge Capture

ManagementService

Person Demographic

Service

EligibilityService

Health Benefit Plan Management

Service

Enrolment Management

Service

Care Authorization Management

Service

Claims Management

Service

Resource Access ControlService


Service

Order EntryService

Charge Capture

ManagementService

Person Demographic

Service

Party Management

FacilityHealthcare

RelationshipService

EligibilityService

Terminology Query

Service

Claims Management

Service

Remittance Management

Service


6.4.2 SeRAH Part2: The Reference ArchitectureThis 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 Service-based Architecture for Healthcare (SeRAH).________________________________________________________________

Using a Taxonomy Matrix as a Communications InstrumentVersion 1.01

April 14, 2000

KENNETH S. RUBINOverview

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 project-level 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 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.

1 The RM-ODP standard can be found at the ISO website at http://www.iso.ch:8000/RM-ODP

2 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.


http://www.gcpr.gov/

http://www.iso.ch:8000/RM-ODP


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.

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

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.

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 7 http://www.imc.exec.nhs.uk/hcm/


http://www.imc.exec.nhs.uk/hcm/

http://www.hl7.org/

http://www.omg.org/homepages/corbamed

http://www.centc251.org/

RM-ODP Viewpoints

Con

text

s


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.

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 communications-gap 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. 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 RM-ODP viewpoints across the columns and three


Though RM-ODP provides perhaps the most generally-applicable and best starting-point for this approach, the Taxonomy Matrix itself is not contingent upon the RM-ODP.


“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 project-specific concerns. The default contexts on the matrix include:

Business Functional Context: Describes the business domain. This context has two sub-components: 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.

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 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];

8 “Reference Model of Open Distributed Processing: Introduction,” Raymond, Kerry, Centre for Information Technology Research, Undated, University of Queensland.


If completing such a cell adds no further value it is best avoided…Since this is a tool for under-standing, pragmatism should guide the level of

Since these contexts are not intended to be normative, some thought should be given in defining the best way to customize to meet


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.

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.

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 document that space. Once artefacts are identified and understandings gleaned, they must be documented in more formal deliverables. These may take the form of artefact description documents, contractual deliverables, and other products.

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”.

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 ApplicationGCPR Communications and scoping vehicle to assist in defining

work products and deliverablesOMG CORBAmed “Roadmap” to demonstrate how CORBAmed services

and interface specifications interrelate with healthcare information models

Veterans Health Administration

“Crosswalk” effort to understand the interrelationships of healthcare models available an approach to relate separate concerns in modeling activities

Good Electronic Health Record Initiative (GEHR)

HL7 Government Special Interest Group

HL7 Component-based Messaging Group

UK National Health Service

Application of the matrix is under consideration for applicability.

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.



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.; Addison-Wesley, 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.


http://www.iso.ch:8000/RM-ODP

http://www.gcpr.gov/


Comments can be directed to [email protected] and are welcomed.




Healthcare Standards Roadmap Matrix v2.0Viewpoint

Enterprise Technology Information Computational Engineering D

escr

ipti

on

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.

Structures, concepts, interaction rules, for the specification + functional decomposition into objects. Includes bindings, interface specifications, environment contract behaviour, and transparencies.

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.

Bus

ines

s Fu

ncti

onal

Con

text

9

Gra

nula

r (c

onte

nt)10

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

-HL7 Use Cases-COSMOS Model -FAM-A

Modeling FormalizationsUML, USDP products

Abs

trac

t(f

orm

)11

Representation of highly-granular components capable of encapsulating, transporting, and/or representing the content of information models

Should be suitable for a variety of technologies: in particular message-oriented middleware and distributed object technologies.

-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

t12

Common services Supporting the Reference Domain Specification.

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)

9 Documentation of the problem space, domain of interest, functional requirements etc.10.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).



Impl

emen

tati

onC

onte

xt13

<su

btyp

e as

ne

eded

>

Requirements, scope, and objectives of an implementation.

Technology instances on which the implementation is to be based (e.g., COTS products, platform, etc.)

Logical Database DesignHL7 RIMs

Service Design Specifications (e.g., CORBAmed services)VHA Data Registry DesignHL7 MDF

GEHR KernelHL7 2.x messagesHL7 3.x messagesCORBAmed ServicesGCPR FrameworkCCOW Implementations

Space RM-ODP Viewpoints

13 Work products developed with the intention of building implementable systems. Draws from other contexts as scoped to address requirements for a targeted implementation



Taxonomy Reference Matrix v2.0Viewpoint

Enterprise Technology Information Computational Engineering D

escr

ipti

on

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).

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.

Defines the information and relationships, information semantics, and information processing requirements of the system. Includes static, dynamic, and invariant schemas.

Structures, concepts, interaction rules, for the specification/ functional decomposition into objects. Includes bindings, interface specification, transparencies, and environment contract behaviour.

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.

Bus

ines

s Fu

ncti

onal

C

onte

xtG

ranu

lar

(Con

tent

)

Describes purpose, scope, policy, etc., particularly org. issues.

Since the scope of the domain context is primarily content definition, there are no technology viewpoint constraints.

Information defined by, required of, or identified in the enterprise view. Includes entities, states, semantics, relations, etc.

Terminology to include concept formation, definition, system

Domain triggers, relationships, use cases pertaining to the healthcare business domain.

Work products in formal notation (UML, OCL, ASN1, etc.), formal models, diagrams, text.

Terminology including term & symbol specification, term-concept assignment

Abs

trac

t(Fo

rm)

Requirements of the representation format (evidentiality, currency, etc.)

(Draw from PRA definition, only more generalized)

(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

Serv

ice

C

onte

xt

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.

Impl

emen

tat

ion

Subt

ype

as

need

ed

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

Space Scope RM-ODP Viewpoints





7 OMG Support

7.1 IntroductionThe 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 ItemsGeneral 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 DeliverablesAnticipated 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 51 of 60


8 OMG Policy and ProcedureThe 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 ProcessRequirements 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 DurationRFI review (“Three week rule”) 21 daysVote by CORBAmed to issue RFI

0 Vote by AB and DTC to issue RFIPreparation of submissions 120 days

120 Submissions dueReview of RFI responses by CORBAmed 30 days

150 Evaluation report by CORBAmedTYPICAL RFI PROCESS TIMETABLE

Page 52 of 60


8.2 Explanation of the OMG RFP ProcessThe 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 non-members 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 SubmissionsOMG 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 multi-vendor alliances and external consensus. Other organisations, which are not co-submitters, 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 SubmissionsThere 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 SelectionAfter 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 53 of 60


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 DurationRFP Review (“Three week rule”) 21 daysVote by CORBAmed to issue RFP

0 AB and DTC votes to issue RFPPreparation of submissions 120 days

60 LOI to submit to RFP due90 Voting registration for CORBAmed members closed120 Submissions due

Preliminary evaluations by CORBAmed and preparation of revised submissions

120 days

240 Revised submissions dueSpecification selection by CORBAmed 60 days

300 CORBAmed votes to select specificationsReview by AB and DTC (“Three week rule”) 21 daysAB and DTC votes to recommend specificationBoD review

360 BoD votes on specification adoptionTYPICAL RFP Process Timetable

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 54 of 60


8.3 Explanation of the OMG RFC ProcessThe 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 55 of 60


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 Event / Activity DurationFormal submission of full specification for review by CORBAmed, AB and DTC (“Three week rule”).

21 days

Vote by CORBAmed to issue RFC for OMG review0 Vote by AB and DTC to release RFC for OMG

reviewReview period – comments from industry 90 days

90 CORBAmed votes to recommend specificationAB and DTC votes to recommend specificationBoD review 30 days

120 BoD votes on specification adoption

TYPICAL RFC PROCESS TIMETABLE

Page 56 of 60


9 Appendices

9.1 Appendix A: Healthcare DTF Three-Year PlanThis 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.

Roadmap version 3.0

CORBAmed Toolkit 1.0 released

CORBAmed Toolkit 2.0 release

CORBAmed Toolkit 3.0 release

Person Identification Service Implementations

Complete

Terminology Query Service Implementations

Complete

Clinical Observation Access Service (COAS) Technology Adopted

Clinical Observation Revision Task Force

Complete

Resource Access Decision (RAD) Technology Adopted

Resource Access Decision (RAD) Revision Task Force

Complete

Clinical Image Access Service (CIAS) Technology Adoption

Clinical Image Access Service (CIAS) Revision Task Force

Medical Transcription Management (MTM) Technology Adoption

Medical Transcription Management (MTM) Revision Task Force

Order Management Service RFP issued

Order Management Service Technology Adoption

Health Information Locator Service (HILS) RFP issued

Health Information Locator Service (HILS) Technology Adoption

Summary List Information Management Service (SLiMS) RFP issued

Summary List Information Management Service (SLiMS) Technology Adoption

CORBA/M RFI response review

CORBA/M RFP issued

Pharmacy RFI issued and responses evaluatedPharmacy Disease Management Service RFP issued

Pharmacy Disease Management Service RFP Technology Adoption

Pharmacy Drug Therapy Management Service RFP issued

Pharmacy Drug Therapy Management Service RFP Technology Adoption

Card Management Service RFP issued

Card Management Service Technology AdoptionHealthcare Data Interpretation Facility Technology Adoption

Healthcare Data Interpretation Facility Revision Task Force

Healthcare Administrative Logistic Financial and

Healthcare Administrative Logistic Financial and

HALFEM Technology Adoptions

Page 57 of 60


Enterprise Management (HALFEM) RFI response review

Enterprise Management series of RFP’s issued:Encounter Management RFPEnterprise Management RFPFinancial Services including:Enrolment Management Service RFPEligibility Service (US specific) RFP (?)Charge Capture Management Service RFPAuthorization Management Service RFPReferral Management Service RFPClaims Management Service RFPRemittance Management Service RFP

Credential Verification Authority Management Service RFP issuedLaboratory Information Access Service RFP issuedMedical Device Information Access Service RFP issuedPoint of Care Information Access Service RFP issuedAuthoring Management Service (XML) RFP issuedOther 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 58 of 60


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 59 of 60


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 60 of 60


9.4 Appendix D: Contacts RFI1 – CORBAmed RFI

??RFI2 - Clinical Observation Access Service (COAS)

Tim Brinson - Protocol Systems - [email protected] RFI3 - Clinical Decision Support

Dave Kilman – Theragraphics - [email protected] 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 - [email protected]

RFP1 – Patient Identification Service (PIDS)Tom Culpepper - 3M - [email protected]

RFP2 – Lexicon Query Service (LQS) Tom Culpepper - 3M - [email protected]

RFP3 – Pharmacy Interaction Facility Erick Hagstrom – Envoy - mailto:[email protected]

RFP4 – Clinical Observation Access Service (COAS) Tom Culpepper - 3M - [email protected]

RFP5 – Healthcare Resource Access Control (HRAC) Konstantin Beznosov - BHS - [email protected]

RFP6 – Healthcare Data Interpretation Facility (HDIF) Dave Kilman - Theragrapics - [email protected]

RFP7 – Clinical Image Access Service (CIAS) Yassar alSafadi - Philips Research - [email protected]

Page 61 of 60












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 ForceThe 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 62 of 60


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 63 of 60


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 world-wide 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 64 of 60

Documents

Object Management Group€¦ · Web view250 First Avenue, Suite 201 Needham, MA 02494, USA. Telephone: +1-781 444 0404. Facsimile: +1-781 444 0320. The CORBAmed Roadmap. CORBAmed: