Thanks for taking the time to review the RLUS RFP
Document. Please use the appropriate peer review form for
your comments and questions. The Peer Review is scheduled
for November 2, 2006 during the RLUS Telcon (1330 EST),
and will last for 2 hours.
The following sections are taken from the RLUS RFP Draft
(filename: RLUS_RFP_20060926_0004.doc). The correlations
are noted in the table below.
Section in this Document Section in the RLS RFP Draft Document
Appendix A Appendix A
These sections are the only sections that the HSSP may
revise in the OMG’s RFP process. The rest of the OMG RFP
boilerplate should therefore be taken as out of scope for this
I have left the boilerplate instructions in these sections in their
original red italics for informational purposes. This will be removed
before the RFP is submitted.
Please direct questions or comments to the list or to myself.
1.0 Specific Requirements on Proposals
< Notes to RFP Editors:
(1) Chapters 1 to 5 are designed to be independent of particular RFP content
and should not normally need to be changed or extended. Chapter 6 should
contain all information specific to this RFP. Additional chapters beyond
Chapter 6 may be added if required, for example, if each distinct RFP item is
more clearly covered separately.
(2) The red text within angle brackets below is provided for guidance and
should be deleted from the RFP, as should these notes. >
Note: The text below was taken from the HL7 Retrieve, Locate, and Update
Service (RLUS) Service Functional Model (SFM) Section 1.1.1.
Context – Relation of this RFP to the HL7 ANSI RLUS Draft Standard for Trial Use
The Healthcare Services Specification Project (HSSP) [http://hssp.wikispaces.com] is a
joint endeavor between Health Level Seven (HL7) [http://www.hl7.org] and the Object
Management Group (OMG) [http://www.omg.org]. The HSSP was chartered at the
January 2005 HL7 meeting under the Electronic Health Records Technical Committee,
and the project was subsequently validated by the Board of Directors of both
The HSSP has several objectives. These objectives include the following:
- To stimulate the adoption and use of standardized “plug-and-play” services by
healthcare software product vendors
- To facilitate the development of a set of implementable interface standards
supporting agreed-upon services specifications to form the basis for provider
purchasing and procurement decisions.
- To complement and not conflict with existing HL7 work products and activities,
leveraging content and lessons learned from elsewhere within the organization.
Within the process, HL7 has primary responsibility for (1) identifying and prioritizing
services as candidates for standardization; (2) specifying the functional requirements and
conformance criteria for these services in the form of Service Functional Model (SFM)
specifications such as this document; and (3) adopting these SFMs as balloted HL7
standards. These activities are coordinated by the HL7 Services Oriented Architecture
SIG in collaboration with other HL7 committees, which currently include the Vocabulary
Technical Committee (TC) and the Clinical Decision Support TC.
Based on the HL7 SFMs, OMG will develop “Requests for Proposals” (RFPs) that are
the basis of the OMG standardization process. This process allows vendors and other
submitters (known as “RFP Submitters”) to propose solutions that satisfy the mandatory
and optional requirements expressed in the RFP while leaving design flexibility to the
submitters and implementation flexibility to the users of the standard. HL7 members will
be involved in the RFP creation and evaluation process.
It is important to note that the HL7 SFMs will focus on specifying the functional
requirements of a service, while OMG specifications will focus on specifying the
technical interface requirements of a service. In many cases, SFMs will also describe an
overall coherent set of functional capabilities. These capabilities may be specialized or
subdivided from both functional and informational (semantic) perspectives to provide
specific “profiles” that may be used as the basis for the OMG RFPs and/or implemented.
Note also that the full functional specification for this service has been defined, balloted,
and approved as an ANSI standard within HL7. This is the “Retrieve, Locate, and Update
Service” Service Functional Model, which achieved DSTU (Draft Standard for Trial Use)
status in the September 2006 ballot.
1.1 Problem Statement
< Note to RFP Editors: Describe the nature of the problem or need that this
RFP is addressing. Include contextual information that will help the
understanding of the reader. >
Note: The text below was taken from the HL7 RLUS Service Functional Model (SFM)
section 2.1.1. See the Objectives section of this RFP document for an explanation of the
relationship between the HL7 SFM and this RFP.
The Retrieve, Location, and Updating Service (RLUS) provides a set of interfaces
through which information systems can access and manage information. RLUS allows
health data to be located, accessed and updated regardless of underlying data structures,
security concerns, or delivery mechanisms.
RLUS explicitly occupies the service space within an information processing
environment. It is independent of but compatible with underlying structures, including
local security implementations, data models, or delivery mechanisms. By separating and
exposing those aspects of resources that facilitate inter-organization work flows in a
service layer, this specification abstracts the problem of interoperability away from
underlying systems. It is this abstraction and reconfiguration that allows interoperability
and system durability independent of burdensome technology integration.
Note: The following is based on Sections 2.1.2 and 2.3 of the HL7 RLUS SFM, and
references the HSSP SSDF..
The Retrieve, Location, and Updating Service (RLUS) functional model specification
seeks to define, at a service level, appropriate interfaces to locate, retrieve, and update
resources among and between healthcare organizations. It is not intended to replace
existing systems or implementations, but to create an interface standard for a service-
oriented layer to expose those healthcare assets and resources within an organization that
are needed to meet business or medical needs while at the same time allowing for
integration into a more extensive service-oriented architecture.
A set of profiles may be defined for RLUS that cover specific functions, semantic
information and overall conformance. The SSDF explains in detail the meaning of each
of these types of profile. In brief, they are as follows:
Functional Profile: a named list of a subset of the operations defined within this
specification which must be supported in order to claim conformance to the
Semantic Profile: identification of a named set of information descriptions
(semantic signifiers) that are supported by one or more operations.
Conformance Profile: this is a combination of a set of functional and semantic
profiles taken together to give a complete coherent set of capabilities against
which conformance may be asserted.
Due to the fact that RLUS represents generic functional capability, none of the specific
functional profiles are intrinsically mandatory, and should not be considered essential
except in the context of RFP submissions. For example, an RLUS instance could support
only the Retrieval profile (similar to part of IHE’s XDS) or only the Location profile.
However, any instance of RLUS must support at least one of the functional profiles
Semantic operations are defined in specific profiles only insofar as the discovery and
description of the semantics underlying an RLUS implementation enable the business
scenario. By design, RLUS interfaces are loosely coupled with the informational qualities
that they expose, though this support is enabled through the mandatory interfaces within
1.1.1 SFM Defined Profiles
Note: The following is based on Sections 2.3 and 6 of the RLUS SFM.
In order to provide for the maximum implementation flexibility, the SFM defines several
enumerated functional profiles for RLUS. These profiles identify a subset of the RLUS
available functionality as pertinent to a specific context.
Administrative – The interfaces contained in this profile define the service
groupings necessary for minimal maintenance functionality.
Location – This profile allows consumers of the service to obtain the metadata
pointing to resources and assets within a steward organization.
Retrieval - allows resources to be retrieved.
Updating - allows underlying repositories to be managed and adjusted according
to well-defined informational constraints
Decision Support – allow functionally and semantically rich interactions,
including nested queries, query by alternate semantic signifier, and describe
nested semantic structures within resources
The SFM normatively defines only one semantic profile: Clinical Document
Architecture, Release 1. As with the functional profiles, this semantic profile is
intrinsically (technically) optional except with respect to RFP submissions. RLUS could
expose varied other informational structures to address business needs, though the CDA
semantics are applicable to all Functional Profiles above.
1.1.2 Profiles in the Deployment Context
Note: The following is based on Sections 2.4 of the RLUS SFM.
RLUS is explicitly an interface specification, not an implementation specification. As
such, it is intended to be an interoperability mechanism between organizations. There is
nothing inherent in the specification that precludes its use within a single organization,
allowing a standardized method of record registry, location, and access. Thus locally,
RLUS can be used to expose one or many internal registries or repositories, can work in
multiple different deployment topologies, and can be used to support different types of
information. These are all deployment decisions and deployment context sensitive.
By the same token, functional and semantic profiles are considered deployment context
sensitive, but their inclusion as components of an RLUS instance, and that instance’s
ability to assert conformance against those profiles, is mandatory as outlined above. It is
essential for interoperability that these notions find a run time expression in a given
For Functional Profiles and their related operations, this is well handled by various
standards. For example, a WSDL implementation of RLUS would include a functional
prescription that is well understood by clients for implementation.
However, Semantic Profiles demonstrate another order of complexity altogether,
especially in semantically ambiguous environments such as those demonstrated in
heterogeneous healthcare contexts. Syntactic expressions of data are necessary but not
sufficient for the majority of complex interoperability scenarios.
1.1.3 Implementable Semantic Profiles
Note: the following is based on Section 2.4.2 of the RLUS SFM
Semantic Profiles include the concepts of both expressed data models (models that are
expressed in data that is actually transmitted “on the wire”) and the formalisms that
describe them. In the SFM, these Semantic Signifiers occupy a strict conceptual space in
interoperability scenarios. As conceptually rich abstractions of data, Semantic Signifiers
provide for facilitating a meaningful interchange of information between transactions
Semantic Signifiers within the base specification are expressed as a data type allowing
for platform-level binding of RLUS while keeping open a construct allowing for
scalability, extensibility, and diversity of semantic information. Additionally, RLUS
subscribes to the HSSP’s profiling mechanism to allow for strong conformance assertions
to be made, inclusive of informational semantics and designated semantic signifiers. This
approach allows RLUS to carry payloads that have been standardized by other
specifications or groups (e.g., HL7 v3).
At run-time, a semantic signifier is the mechanism for realizing semantic profiles. This
element may be an HL7 artifact, a locally published template, a nationally published
template, a published XML schema, or to an agreed upon set of values. It may be passed
by reference or by value, as both satisfy the functional requirements and meet the
1.1.4 Semantic Signifiers as Mechanisms for Interoperability
It is vital that a deployed RLUS can describe information about the semantic profile or
profiles that it supports. Depending on the functional profile supported in a deployment,
this could include:
that it delineates specifically the semantic signifiers by which queries may be
that it delineates specifically the semantic signifiers by which responses will be
that it supports nested queries of one semantic signifier from within another
Thus, semantic transformation or adaptation may happen within the requestor’s domain,
the responder’s domain, or be included in the RLUS implementation, depending on
agreements between trading partners and deployment context.
1.1.5 RLUS Meta-model for Technical Clarification
The following meta-model is included for clarification of the above concepts. Among
other things, it demonstrates the expression of profiles and run-time expressed semantic
constructs as an essential interoperability construct in semantically rich environments.
1.2 Scope of Proposals Sought
< Note to RFP Editors: Describe the composition and main characteristics of the solution
for which proposals are being sought.
Submissions to this RFP must conform to the meta-model above. That is, any
allow for expressable Functional, Semantic, and Conformance Profiles
allow for conformance to be asserted and tested against these profiles.
tie transmitted data to the data model, express the data model using some
formalism, and group those models under a Semantic Profile.
Include at least one fully enumerated Conformance Profile.
Implementations should be intentionally loosely coupled to their semantics. Thus
two service instances should be functionally identical, but semantically diverse,
thus demonstrating extensibility.
While RLUS is a foundational component of any SOA and could be applied to a
number of specific domains, specifications should be focused on the healthcare
Qualitatively, the specification should simplify the implementation of interoperability
between organizations or systems through explicit use of services expressing a chosen
Conformance Profile. This means that the usage of the specification should minimize and
qualify the actions taken by members of organizations in the plan, design,
implementation, testing, and maintenance of one or more RLUS service instances.
1.3 Relationship to Existing OMG Specifications
< Note to RFP Editors: Describe the possible relationships that proposals may
have to existing OMG specifications in terms of potential reuse of models,
mappings, interfaces, and potential dependencies on pervasive services and
Reference Description Relationship to RLUS
COAS The OMG Clinical RLUS is to supersede the COAS
Observation Access Service specification. Among other issues,
(COAS) provides a the absence of an information
mechanism to allow for the model and accepted industry
retrieval of [clinical] content constructs inhibited marketplace
via a set of established adoption of COAS. RLUS is
interfaces. Effectively, COAS explicitly requiring support for HL7
provides a generic retrieval semantic content, while leaving
capability and is independent open the possibility to support other
of information model. information models.
The computational aspects of
COAS were analysed and have
been considered during the
development of this RFP.
HILS The Healthcare Information The core functionality of HILS has
Location Service was an RFP been included within the scope of
to address the ability to RLUS. One of the reasons that the
discover and “locate” location capability has been
healthcare information within included as an integral component
or across Enterprises. HILS of RLUS was a result of HILS
was issued as an OMG RFP, experiences that demonstrated that
but never completed the the consideration of “location”
standards cycle. apart from retrieval created
tremendously difficult scope
challenges between RFPs.
OMG Person The Person Identification The RLUS specification does not
Identification Service provides the address identity management as
Service (PIDS) functional capability to create part of its functionality, and is
Specification and manage patient identities, intended to defer to identity
Version 1.1, April and is a CORBA IDL services (such as would be provided
2001 specification. by PIDS-compliant software) for
Worth noting is that the PIDS
specification is being revised to
address shortcomings, with an
“Entity Identification Service”
specification emerging. In other
words, RLUS was designed with
PIDS/EIS deployments in mind.
1.4 Related Activities, Documents and Standards
< Note to RFP Editors: List documents, URLs, standards, etc. that are relevant
to the problem and the proposals being sought. Also describe any known
overlaps with specification activities or specifications, competing or
complementary, from other standards bodies. >
Note: Following is subset of Appendix A (Section 11) of the HL7 RLUS SFM not
pertaining to OMG specifications
Applicable Description Relationship Notes
HL7 CDA The HL7 The HL7 CDA HL7
Defined Specification may be used
Clincal as a structure for the
Document payload definition of
Architecture RLUS-retrieved results. In
is a other words, the
parameters on the RLUS
service interface may use
representations as the
structure and semantic of
the data it is managing.
HL7 EHR The HL7 See Appendix A of the HL7
HL7 Version 3 The HL7 Reference HL7
Reference Information Model
Information provides the underpinning
Model (HL7 for the information
V3 RIM) semantics that are used in
of the RLUS specification.
For these profiles, the RIM
and other RIM-derived
identify the data elements,
data types, structure, and
for payload crossing the
RLUS service interfaces.
See Appendix B of the
SFM for the RIM, and
Section 126.96.36.199.2 for the
RIM class representations
of the RLUS metadata
IHE XDS Relevant External Work - PDF
Cross IHE XDS is an example of
Enterprise an RLUS compliant
Document interface that conforms to
Exchange an RLUS HL7 CDA
Location and Retrieval
Profile. The scope of
RLUS is more generalized,
and assumes more
generalized standards for
information and data
Localized Relevant External Work - HL7
Information The HL7 Organizations
Model (LIM) Template Special Interest
Group has undertaken to
provide for description and
localization of information
models. LIMs provide a
way to communicate the
informational semantics of
an RLUS instance to
trading partners. See HL7
Universal Relevant External Work - Uddi.org
Description, UDDI provides a platform
Discovery, and for Discovery and
Integration Description of Services,
and helped to broadly
define the business needs
for true automated service-
interactions. The UDDI
specification informs the
RLUS SFM in its notion of
topologies and in its
design for automated
discovery and description.
Thus, it defined
creating a normative
This specification will
likely take on added
importance in the OMG
World Wide The W3C’s URI W3C
Web specification is important
Consortium’s in identifying objects on
Universal the Internet, and contains a
Resource thorough treatment of the
Identifier underlying issues of
(URI) identification and location.
It is related to, but not the
same as, the IETF’s
scheme of Universal
URI’s deprecates the
popular concept of
Locations (URL’s), in that
a URL is an informal
concept within URI’s.
identify a resource using
its primary access
Transfer Protocol (http)).
HL7 The HL7 Templates Special HL7
Templates Interest Group (Templates
SIG) is presently in the
process of harmonizing
requirements from among the
CEN, OpenEHR, and HL7
communities. Each of these
communities is using some
form of structure, constraint,
and semantic to do precisely
the types of representations
and uses that are expected
of RLUS semantic signifiers.
HSSP SSDF The HSSP specifies a http://hssp.wikispaces.com
Development Framework that
encompasses the process
whereby standards are
achieved. This framework
also defines the optimal
paths for conformance
profiling, including functional
and semantic roadmaps.
1.5 Mandatory Requirements
< Note to RFP Editors: Describe the requirements that proposals must satisfy
i.e. for which proposals must specify an implementable solution. Avoid
requirements that unnecessarily constrain viable solutions or implementation
Mandatory requirements should be stated using phrases such as:
“Proposals shall provide...”, or
“Proposals shall support the ability to...”
Describe any modeling-related requirements.
Some guidelines for modeling requirements:
A PIM and one or more PSMs may be required by the RFP. RFPs may call for
the specification of a PIM corresponding to one or more pre-existing PSMs, or
for one or more PSMs corresponding to a pre-existing PIM.
If an RFP requests a PIM, it shall state explicitly of what technology or
technologies the PIM shall be independent. For example, an RFP might state
that a PIM should be independent of programming languages, distributed
component middleware and messaging middleware. If an RFP requests a PSM,
it shall state explicitly to what technology or technologies the PSM shall be
specific, such as CORBA, XML, J2EE etc.
If it is anticipated that a related PIM, PSM or mapping will be requested by a
successor RFP, that fact should be mentioned.
MDA RFPs usually fall into one of these five categories:
1. Service specifications (Domain-specific, cross-domain or middleware
For RFPs for service specifications, “Platform” usually refers to middleware,
so “Platform Independent” means independent of middleware, and “Platform
Specific” means specific to a particular middleware platform. Such RFPs
should typically require that UML be used to specify any required PIMs.
Variance from this drafting guideline must be defended to the Architecture
Furthermore, such RFPs may require a submitted PSM to be expressed in a
UML profile or MOF-compliant language that is specific to the platform
concerned (e.g. for a CORBA-specific model, the UML profile for CORBA
[UMLC]). Alternatively, the RFP may require that the PSM be expressed in the
language that is native to the platform in question (e.g. IDL). If the RFP
requests both, it must make clear which one is to be normative.
2. Data Models
In pure data modeling a PIM is independent of a particular data representation
syntax, and a PSM is derived by mapping that PIM onto a particular data
RFPs should typically require submitted data models to be expressed using one
of the following OMG modeling languages: UML, CWM, MOF.
3. Language Specification
The abstract syntax of a language shall be specified as a MOF-compliant
4. Mapping Specifications
A transformation model and/or textual correspondence description is required.
5. Network Protocol Specifications
It’s possible to view a network transport layer as a platform, and therefore to
apply a PIM/PSM split to specifying a network protocol – for instance, one
could view GIOP as a PIM relative to transport, and IIOP as a PSM that
realizes this PIM for one specific transport layer protocol (TCP/IP). Where
possible, protocols should therefore be specified with an appropriate PIM/PSM
separation. The models may include the protocol data elements and sequences
of interactions as appropriate. >
Note - In addition to reviewing these requirements, it is strongly recommended that
submitters read and digest the balloted HL7 RLUS Service Functional Model (SFM) as
part of producing their responses to this RFP. Some of these requirements make explicit
references to sections within the SFM.
1. Submissions shall present a MDA-capable Platform-Independent Model (PIM)
expressed using UML.
2. Submissions shall present a Platform Specific Model for the WSDL / SOAP /
XML / HTTP platform.
3. Each Platform Specific Model shall define interfaces (e.g. using WSDL, SOAP)
and transport mechanisms (e.g. TCP/IP, HTTP) corresponding to the PIM.
4. Submissions shall define explicit operations that support all of the capabilities
defined in sections 5 of the SFM
Note: There is no mandate that the mapping of capabilities to operations has to be
1 to 1. Some examples are:
o in Section 5 of the HL7 RLUS SFM, “retrieve” functionality is intentionally
separated from the “locate” functionality. These may have to work in tandem
in an implementation for discrete data sets. (SFM Ref: Sections 5.3.1, 5.3.2,
o “Delete Resource” explicitly also removes the RLUS reference to that
resource (or makes it unavailable). This may involve the administrative
function “Delete an RLUS Entry,” but does not do so normatively. (SFM
Ref: 5.1.3, 5.3.6)
5. Submissions shall provide a justification for any deviations from the normative
sections of the HL7 RLUS SFM (specifically sections 5 and 6), including any
Note: This means that submissions must define a solution that covers the Inputs,
Outputs, Pre-conditions, Invariants, Post-conditions and Exception Conditions as
specified in the HL7 RLUS SFM Section 5 Capability descriptions for each
capability supported. If these are not met, then any changes must be explained and
justified as to why and how the function is covered.
6. Submissions shall include support for the specific semantic profile defined in the
HL7 RLUS SFM, i.e. the “HL7-CDAr1” profile as part of one or more overriding
7. Submissions must be capable of supporting other HL7 Semantic Profiles, and
their related Semantic Signifiers.
8. Submitters shall fully and explicitly describe behavior of all included operations.
Special note should be taken of the manner in which the PSM payload is bound to
the Semantic Signifier at design and run time.
Note: This should include resolution of all relevant open questions associated
with included operations within sections 5 and 9 of the SFM identified as
issues for RFP Submitters. (SFM Ref: Sections 5 and 9) Some are identified
elsewhere in this RFP as requiring explicit rationale.
9. Submissions shall provide a run time mechanism to define and maintain which
conformance profiles are supported by an RLUS instance. (SFM Ref 5.1.4)
10. Submissions shall include the capability to determine which “profiles” are
supported by a service instance.
11. Submissions shall not preclude the use of RLUS instances in simple and
distributed (explicitly hierarchic and lateral (peer-to-peer)) topologies. (SFM Ref:
Section 9.2, 9.7)
12. Submitters shall identify and describe PSM-specific technical conformance
1.6 Optional Requirements
< Note to RFP Editors: Make requests for optional features which proposals
may satisfy. While the satisfaction of requests is desirable (and will be taken
into account in evaluating the submissions), proposals are not required to
satisfy them, i.e. specify an implementable solution.
Requests should be stated using phrases such as:
“Proposals may provide...”, or
“Proposals may support the ability to...”>
1. Submissions may define PSMs for platforms additional to
WSDL/SOAP/XML/HTTP. If submissions include these extra PSMs, the impact
to client implementation should be enumerated for both positive and negative
2. Submissions may define and support additional semantic, functional and
conformance profiles (e.g. Lab Orders, Continuity of Care Records, Care Record
3. Submissions may define Conformance Profiles that do not include HL7-specific
Semantic profiles. One possible example is OpenEHR GOM-based profiles and
Archetype-based Semantic Signifiers.
4. Submissions may include the definition of a non-mandatory Conformance Profile.
5. Submissions may provide recommendations for additional HL7 Semantic
Profiles, both mandatory and optional.
6. Submissions may support Functional Profiles (and their requisite operations)
beyond the minimum profiles defined in Section 6.2 of the SFM.
7. Submitters may provide recommendations for additional Functional Profiles, both
mandatory and optional.
8. Submissions may support non-entity identified query capabilities (population
1.7 Issues to be discussed
< Note to RFP Editors: Describe the issues that proposals should discuss.
Issues to be discussed shall be stated in terms of phrases such as:
“Proposals shall discuss how... ”, or
“Proposals shall include information on...”, or
“Proposals shall provide the design rationale for...”.>
These issues will be considered during the evaluation period for submissions.
The discussion items should not be part of the proposed normative specification
however they may impact parts of the normative specification. (Place the
discussion in Part I of the submission.)
1. Submitters shall identify relevant HITSP use cases and standards and discuss the
relationship to this specification. If there is divergence between PIM-supported
functionality and PSM-supported functionality with respect to the HITSP use
cases and standards, this should be explained in rigorous detail.
2. Submitters shall explain how the specification addresses any information content
that is not explicitly specified in the HL7 RLUS SFM.
3. If applicable, submitters shall discuss how non-HL7 semantic signifiers will be
4. Submitters shall discuss if and how any information constructs in the specification
relate to the HL7 Reference Information Model (RIM). This includes optional and
5. Submitters will discuss how constraints will be addressed on Semantic Signifiers,
regardless of the Semantic Profiles supported, and the formalisms used for
6. Submitters will discuss the formalisms used for Semantic Signifier representation
if they are differentiated in implementation from the constraints on Semantic
7. Submitters shall discuss if and how the use cases in HL7 RLUS SFM section 3
are addressed by the submission.
8. Submitters shall discuss implications of the PSM on deployment topology,
preferably including UML Deployment or Composite diagrams
9. The RFP submitter should discuss issues relating to service description and
discovery per Section 9.1, 9.2, 9.7.1 of the SFM.
10. RFP Submitters should discuss how their submission relates to the IHE XDS
11. If applicable, RFP Submitters will discuss the levels of support for non-entity
identified (population-level) query capabilities.
12. RFP Submitters shall discuss how to define and test conformance assertions.
(SFM Ref 5.1.4, 6)
13. RFP Submitters shall discuss the approach taken to federation. See Section 9.7 for
Note: Specific consideration should be paid the difference in federating and the
potential for connecting peer instances of RLUS. It would be appropriate to
specify deployment considerations for each type of model, as well as optimal
deployment environments (SFM Refs: Sections 9.7)
1.8 Evaluation Criteria
< Note to RFP Editors: Conformance to the mandatory requirements along with
consideration of the optional requirements and issues to be discussed, are
implied evaluation criteria. RFP authors should describe any additional criteria
that submitters should be aware of that will be applied during the evaluation
1. Preference will be given to submissions that most closely align with the HL7
2. Preference will be given to submissions that support all of the operations defined
in the HL7 RLUS SFM.
3. Preference will be given to submissions that most closely align to the principles
cited in the HL7 RLUS SFM Section 4.1 (“Service Definition Principles”).
4. Preference will be given to submissions that most closely align to the principles
cited in the HL7 RLUS SFM Section 8 (“Information Model and Semantic
5. Preference will be given to submissions that define profiles that support the
functionality provided by IHE XDS Profiles
6. Preference will be given to submissions that support the extensibility inherent in
the HL7 RLUS SFM. In particular, a solution that supports multiple domains and
semantic signifiers will be given preference.
7. Preference will be given to submissions that demonstrate a loose coupling and
interchangeability between Semantic Profiles for a given RLUS instance.
8. Preference will be given to submissions that support both HL7 and non-HL7
9. Preference will be given to submissions that demonstrate an ability to simplify the
act of federating (or forwarding) RLUS queries.
10. Preference will be given to submissions that support population-level queries,
either in an expressed unique Conformance Profile or as part of another
11. Preference will be given to submissions that support both hierarchic and lateral
(peer-to-peer) distributed topologies for handling of multiple RLUS Domains.
1.9 Other information unique to this RFP
< Note to RFP Editors: Include any further information pertinent to this RFP
that does not fit into the sections above, or which is intended to override
statements in the Chapters 1 to 5. >
1.10 RFP Timetable
The timetable for this RFP is given below. Note that the TF or its parent TC may, in
certain circumstances, extend deadlines while the RFP is running, or may elect to have
more than one Revised Submission step. The latest timetable can always be found at the
OMG Work In Progress page at http://www.omg.org/schedules/ under the item identified
by the name of this RFP. Note that “<month>” and “<approximate month>” is the name
of the month spelled out; e.g., January.
Event or Activity Actual Date
Preparation of RFP by TF
RFP placed on OMG document server 11/10/2006
Approval of RFP by Architecture Board December 2006
Review by TC
TC votes to issue RFP December 2006
LOI to submit to RFP due 1/31/2007
Initial Submissions due and placed on May 2007
OMG document server (“Three week
Voter registration closes ??
Initial Submission presentations June 2007
Preliminary evaluation by TF June 2007
Revised Submissions due and placed on August 2007
OMG document server (“Three week
Revised Submission presentations September 2007
Final evaluation and selection by TF December 2007
Recommendation to AB and TC
Approval by Architecture Board December 2007
Review by TC
TC votes to recommend specification
BoD votes to adopt specification
< Note to RFP Editors: Insert additional chapter if needed here and update the
list and brief description of chapters in Chapter 1. >
Appendix A References and Glossary Specific to
A.1 References Specific to this RFP
< Note to RFP Editors: Insert any references specific to this RFP that are
referred to in the Objective Section, Section 6 and any additional sections in the
same format as in Section B.1 and in alphabetical order in this section. >
[RLUS-SFM] Retrieve, Locate, and Update Service Functional Model,
[HL7] Health Level 7
[HL7 V2.5] HL7 Messaging Standard: V 2.5
[HL7 V3] HL7 Messaging Standard: V 3
[HL7 RIM] HL7 Reference Information Model
[SSDF] HSSP Service Specification Development Framework (SSDF).
A.2 Glossary Specific to this RFP
< Note to RFP Editors: Insert any glossary items specific to this RFP that are
used in Section 6 and any additional sections in the same format as in Section
B.2 and in alphabetical order in this section. >
Healthcare Services Specification Project (HSSP) - A joint effort between the
HL7 SOA SIG and OMG Healthcare Domain Task Force to produce standard
service definitions for Healthcare: http://hssp.wikispaces.com/
Profiles - These are a set of constraints or conditions that identify specific
functions, semantic information and overall conformance for services. The
HSSP SSDF explains in detail the meaning of each of these types of profile. In
brief, they are as follows:
o Functional Profile: a named list of a subset of the operations defined
within this specification which must be supported in order to claim
conformance to the profile.
o Semantic Profile: identification of a named set of information
descriptions (semantic signifiers) that are supported by one or more
operations. The Semantic Profile includes both the instances of
meaningful information that is available through RLUS as well as the
specific formalisms that describe those instances.
o Conformance Profile: this is a combination of a set of functional and
semantic profiles taken together to give a complete coherent set of
capabilities against which conformance can be claimed. Should be
Reference Information Model (RIM) - This is a model thast provides the
foundation for all HL7 content modeling. Classes are specialized by HL7
Domain Committees from a set of core foundation classes to create domain
Service Metadata - This is a set of data items that delineate the scope and
coverage of an instance of RLUS. This includes the Semantic Signifier used as a
query parameter as well as the Semantic Signifier used as the return type.