1. Introduction:Thanks for taking the time to review the RLUS RFPDocument. Please use the appropriate peer review form foryour comments and questions. The Peer Review is scheduledfor 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 correlationsare noted in the table below.Section in this Document Section in the RLS RFP Draft Document1 6 1.1 6.1 Appendix A Appendix A These sections are the only sections that the HSSP mayrevise in the OMGs RFP process. The rest of the OMG RFPboilerplate should therefore be taken as out of scope for thisreview. 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.

2. Please direct questions or comments to the list or to myself. Thanks John 3. 1.0Specific Requirements on Proposals< Notes to RFP Editors:(1) Chapters 1 to 5 are designed to be independent of particular RFP contentand should not normally need to be changed or extended. Chapter 6 shouldcontain all information specific to this RFP. Additional chapters beyondChapter 6 may be added if required, for example, if each distinct RFP item ismore clearly covered separately.(2) The red text within angle brackets below is provided for guidance andshould be deleted from the RFP, as should these notes. >Note: The text below was taken from the HL7 Retrieve, Locate, and UpdateService (RLUS) Service Functional Model (SFM) Section 1.1.1. Context Relation of this RFP to the HL7 ANSI RLUS Draft Standard for Trial Use (DSTU) 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 organizations.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 4. 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.1Problem Statement< Note to RFP Editors: Describe the nature of the problem or need that thisRFP is addressing. Include contextual information that will help theunderstanding 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- 5. 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 thisspecification which must be supported in order to claim conformance to theprofile. 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 semanticprofiles taken together to give a complete coherent set of capabilities againstwhich 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 IHEs XDS) or only the Location profile. However, any instance of RLUS must support at least one of the functional profiles defined below.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 profiles. 1.1.1SFM 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 servicegroupings necessary for minimal maintenance functionality. Location This profile allows consumers of the service to obtain the metadatapointing to resources and assets within a steward organization. Retrieval - allows resources to be retrieved. Updating - allows underlying repositories to be managed and adjusted accordingto well-defined informational constraints 6. Decision Support allow functionally and semantically rich interactions,including nested queries, query by alternate semantic signifier, and describenested 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.2Profiles 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 instances 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 implementation. 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.3Implementable 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 involving RLUS. 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 7. subscribes to the HSSPs 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 business needs.1.1.4Semantic 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 bemade that it delineates specifically the semantic signifiers by which responses will bedelivered that it supports nested queries of one semantic signifier from within anothersemantic signifier Thus, semantic transformation or adaptation may happen within the requestors domain, the responders domain, or be included in the RLUS implementation, depending on agreements between trading partners and deployment context. 1.1.5RLUS 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. 8. [TODO: Need model Dumpout] 9. 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 specification must: 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 industry. 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 facilities. >ReferenceDescription Relationship to RLUSCOAS The OMG ClinicalRLUS is to supersede the COASObservation Access Servicespecification. Among other issues,(COAS) provides a the absence of an informationmechanism to allow for themodel and accepted industryretrieval of [clinical] content constructs inhibited marketplacevia a set of establishedadoption of COAS. RLUS isinterfaces. Effectively, COAS explicitly requiring support for HL7provides a generic retrievalsemantic content, while leaving 10. capability and is independent open the possibility to support otherof information model. information models.The computational aspects ofCOAS were analysed and havebeen considered during thedevelopment of this RFP.HILS The Healthcare InformationThe core functionality of HILS hasLocation Service was an RFP been included within the scope ofto address the ability to RLUS. One of the reasons that thediscover and locate location capability has beenhealthcare information within included as an integral componentor across Enterprises. HILS of RLUS was a result of HILSwas issued as an OMG RFP, experiences that demonstrated thatbut never completed the the consideration of locationstandards cycle.apart from retrieval createdtremendously difficult scopechallenges between RFPs. OMG Person The Person Identification The RLUS specification does not Identification Service provides theaddress identity management as Service (PIDS) functional capability to create part of its functionality, and is Specificationand manage patient identities,intended to defer to identity Version 1.1, April and is a CORBA IDLservices (such as would be provided 2001 specification.by PIDS-compliant software) forthese functions.Worth noting is that the PIDSspecification is being revised toaddress shortcomings, with anEntity Identification Servicespecification emerging. In otherwords, RLUS was designed withPIDS/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 11. ApplicableDescriptionRelationshipNotes Standard HL7 CDA The HL7The HL7 CDAHL7 DefinedSpecification may be used Clincalas a structure for the Document payload definition of Architecture RLUS-retrieved results. In is a other words, theparameters on the RLUSservice interface may useCDA-conformantrepresentations as thestructure and semantic ofthe data it is managing. HL7 EHR The HL7See Appendix A of theHL7 Electronic SFM. Health Record HL7 Version 3The HL7 Reference HL7 ReferenceInformation Model Informationprovides the underpinning Model (HL7 for the information V3 RIM)semantics that are used inHL7-conformance profilesof the RLUS specification.For these profiles, the RIMand other RIM-derivedinformation modelsidentify the data elements,data types, structure, andunderlying terminologiesfor payload crossing theRLUS service interfaces.See Appendix B of theSFM for the RIM, andSection 4.3.1.3.2 for theRIM class representationsof the RLUS metadataelements. IHE XDSRelevant External Work -PDF CrossIHE XDS is an example of Enterprise an RLUS compliant Document interface that conforms to Exchange an RLUS HL7 CDALocation and Retrieval 12. Profile. The scope ofRLUS is more generalized,and assumes moregeneralized standards forinformation and dataexchange. LocalizedRelevant External Work - HL7 InformationThe HL7 Organizations Model (LIM)Template Special InterestGroup has undertaken toprovide for description andlocalization of informationmodels. LIMs provide away to communicate theinformational semantics ofan RLUS instance totrading partners. See HL7Templates below. UniversalRelevant External Work - Uddi.org Description, UDDI provides a platform Discovery, and for Discovery and IntegrationDescription of Services,and helped to broadlydefine the business needsfor true automated service-to-service RLUSinteractions. The UDDIspecification informs theRLUS SFM in its notion oftopologies and in itsdesign for automateddiscovery and description.Thus, it definedappropriate functionalboundaries andexpectations withoutcreating a normativeconcept.This specification willlikely take on addedimportance in the OMGprocess. World Wide The W3Cs URIW3C Webspecification is important Consortiums in identifying objects on Universalthe Internet, and contains a 13. Resourcethorough treatment of the Identifierunderlying issues of (URI) identification and location. It is related to, but not the same as, the IETFs scheme of Universal Resource Naming. URIs deprecates the popular concept of Universal Resource Locations (URLs), in that a URL is an informal concept within URIs. Specifically, URLs identify a resource using its primary access mechanism (Hypertext 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 ahttp://hssp.wikispaces.com Service Specification 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.5Mandatory Requirements< Note to RFP Editors: Describe the requirements that proposals must satisfyi.e. for which proposals must specify an implementable solution. Avoidrequirements that unnecessarily constrain viable solutions or implementationapproaches.Mandatory requirements should be stated using phrases such as: 14. 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 services). 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 Board. 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 representation syntax. RFPs should typically require submitted data models to be expressed using one of the following OMG modeling languages: UML, CWM, MOF. 3. Language Specification 15. The abstract syntax of a language shall be specified as a MOF-compliantmetamodel 4. Mapping Specifications A transformation model and/or textual correspondence description is required. 5. Network Protocol Specifications Its 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, 5.3.3) 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 unsupported capabilities.Note: This means that submissions must define a solution that covers the Inputs,Outputs, Pre-conditions, Invariants, Post-conditions and Exception Conditions asspecified in the HL7 RLUS SFM Section 5 Capability descriptions for each 16. capability supported. If these are not met, then any changes must be explained andjustified as to why and how the function is covered. 6. Submissions shall include support for the specific semantic profile defined in theHL7 RLUS SFM, i.e. the HL7-CDAr1 profile as part of one or more overridingconformance profiles. 7. Submissions must be capable of supporting other HL7 Semantic Profiles, andtheir 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 tothe Semantic Signifier at design and run time. Note: This should include resolution of all relevant open questions associatedwith included operations within sections 5 and 9 of the SFM identified asissues for RFP Submitters. (SFM Ref: Sections 5 and 9) Some are identifiedelsewhere 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 criteria. 1.6Optional Requirements< Note to RFP Editors: Make requests for optional features which proposalsmay satisfy. While the satisfaction of requests is desirable (and will be takeninto account in evaluating the submissions), proposals are not required tosatisfy them, i.e. specify an implementable solution.Requests should be stated using phrases such as:Proposals may provide..., orProposals may support the ability to...> 1. Submissions may define PSMsforplatforms additionaltoWSDL/SOAP/XML/HTTP. If submissions include these extra PSMs, the impactto client implementation should be enumerated for both positive and negativeimpacts. 2. Submissions may define and support additional semantic, functional andconformance profiles (e.g. Lab Orders, Continuity of Care Records, Care RecordSummaries) 17. 3. Submissions may define Conformance Profiles that do not include HL7-specificSemantic profiles. One possible example is OpenEHR GOM-based profiles andArchetype-based Semantic Signifiers. 4. Submissions may include the definition of a non-mandatory Conformance Profile. 5. Submissions may provide recommendations for additional HL7 SemanticProfiles, 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, bothmandatory and optional. 8. Submissions may support non-entity identified query capabilities (populationlevel queries).1.7Issues 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... , orProposals shall include information on..., orProposals 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 specificationhowever they may impact parts of the normative specification. (Place thediscussion in Part I of the submission.) 1. Submitters shall identify relevant HITSP use cases and standards and discuss therelationship to this specification. If there is divergence between PIM-supportedfunctionality and PSM-supported functionality with respect to the HITSP usecases and standards, this should be explained in rigorous detail. 2. Submitters shall explain how the specification addresses any information contentthat is not explicitly specified in the HL7 RLUS SFM. 3. If applicable, submitters shall discuss how non-HL7 semantic signifiers will berepresented. 4. Submitters shall discuss if and how any information constructs in the specificationrelate to the HL7 Reference Information Model (RIM). This includes optional andmandatory components. 5. Submitters will discuss how constraints will be addressed on Semantic Signifiers,regardless of the Semantic Profiles supported, and the formalisms used forconstraint representation. 6. Submitters will discuss the formalisms used for Semantic Signifier representationif they are differentiated in implementation from the constraints on SemanticSignifiers. 7. Submitters shall discuss if and how the use cases in HL7 RLUS SFM section 3are addressed by the submission. 18. 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 specification. 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 more information. 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.8Evaluation Criteria< Note to RFP Editors: Conformance to the mandatory requirements along withconsideration of the optional requirements and issues to be discussed, areimplied evaluation criteria. RFP authors should describe any additional criteriathat submitters should be aware of that will be applied during the evaluationprocess. > 1. Preference will be given to submissions that most closely align with the HL7RLUS SFM. 2. Preference will be given to submissions that support all of the operations definedin the HL7 RLUS SFM. 3. Preference will be given to submissions that most closely align to the principlescited in the HL7 RLUS SFM Section 4.1 (Service Definition Principles). 4. Preference will be given to submissions that most closely align to the principlescited in the HL7 RLUS SFM Section 8 (Information Model and SemanticBinding Approach) 5. Preference will be given to submissions that define profiles that support thefunctionality provided by IHE XDS Profiles 6. Preference will be given to submissions that support the extensibility inherent inthe HL7 RLUS SFM. In particular, a solution that supports multiple domains andsemantic signifiers will be given preference. 7. Preference will be given to submissions that demonstrate a loose coupling andinterchangeability between Semantic Profiles for a given RLUS instance. 19. 8. Preference will be given to submissions that support both HL7 and non-HL7Semantic Profiles. 9. Preference will be given to submissions that demonstrate an ability to simplify theact 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 Conformance Profile. 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.9Other information unique to this RFP< Note to RFP Editors: Include any further information pertinent to this RFPthat does not fit into the sections above, or which is intended to overridestatements 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 and is the name of the month spelled out; e.g., January.Event or ActivityActual DatePreparation of RFP by TFRFP placed on OMG document server 11/10/2006Approval of RFP by Architecture Board December 2006Review by TCTC votes to issue RFP December 2006LOI to submit to RFP due1/31/2007Initial Submissions due and placed on May 2007OMG document server (Three weekrule)Voter registration closes ??Initial Submission presentationsJune 2007Preliminary evaluation by TFJune 2007 20. Revised Submissions due and placed onAugust 2007 OMG document server (Three week rule) 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 thelist and brief description of chapters in Chapter 1. >Appendix A References and Glossary Specific tothis RFP A.1 References Specific to this RFP< Note to RFP Editors: Insert any references specific to this RFP that arereferred to in the Objective Section, Section 6 and any additional sections in thesame format as in Section B.1 and in alphabetical order in this section. >[RLUS-SFM] Retrieve, Locate, and Update Service Functional Model,http://www.omg.org/XXXl.htm[HL7] Health Level 7http://www.hl7.org/[HL7 V2.5] HL7 Messaging Standard: V 2.5http://www.hl7.org/[HL7 V3] HL7 Messaging Standard: V 3http://www.hl7.org/[HL7 RIM] HL7 Reference Information Modelhttp://www.hl7.org/ [SSDF] HSSP Service Specification Development Framework (SSDF).http://hssp.wikispaces.com/space/showimage/HSSP_Service_Specification_Development_Framework_v1-3.rtf 21. 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 definedwithin this specification which must be supported in order to claimconformance to the profile.o Semantic Profile: identification of a named set of informationdescriptions (semantic signifiers) that are supported by one or moreoperations. The Semantic Profile includes both the instances ofmeaningful information that is available through RLUS as well as thespecific formalisms that describe those instances.o Conformance Profile: this is a combination of a set of functional andsemantic profiles taken together to give a complete coherent set ofcapabilities against which conformance can be claimed. Should beversioned. 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 models. 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.