Introduction:


       Thanks for taking the time to review the RLUS RFP
       Document. Please use the appropriate peer ...
Please direct questions or comments to the list or to myself.


Thanks


John
1.0      Specific Requirements on Proposals
         < Notes to RFP Editors:
         (1) Chapters 1 to 5 are designed to ...
and optional requirements expressed in the RFP while leaving design flexibility to the
submitters and implementation flexi...
oriented layer to expose those healthcare assets and resources within an organization that
are needed to meet business or ...
 Decision Support – allow functionally and semantically rich interactions,
     including nested queries, query by altern...
subscribes to the HSSP’s profiling mechanism to allow for strong conformance assertions
to be made, inclusive of informati...
[TODO: Need model Dumpout]
1.2       Scope of Proposals Sought
< Note to RFP Editors: Describe the composition and main characteristics of the soluti...
capability and is independent     open the possibility to support other
                     of information model.        ...
Applicable      Description    Relationship              Notes
Standard
HL7 CDA         The HL7        The HL7 CDA        ...
Profile. The scope of
                 RLUS is more generalized,
                 and assumes more
                 genera...
Resource                        thorough treatment of the
Identifier                      underlying issues of
(URI)      ...
“Proposals shall provide...”, or
“Proposals shall support the ability to...”
Describe any modeling-related requirements.
S...
The abstract syntax of a language shall be specified as a MOF-compliant
         metamodel
        4. Mapping Specificatio...
capability supported. If these are not met, then any changes must be explained and
         justified as to why and how th...
3. Submissions may define Conformance Profiles that do not include HL7-specific
         Semantic profiles. One possible e...
8. Submitters shall discuss implications of the PSM on deployment topology,
          preferably including UML Deployment ...
8. Preference will be given to submissions that support both HL7 and non-HL7
         Semantic Profiles.
      9. Preferen...
Revised Submissions due and placed on      August 2007
OMG document server (“Three week
rule”)
Revised Submission presenta...
A.2 Glossary Specific to this RFP
< Note to RFP Editors: Insert any glossary items specific to this RFP that are
used in S...
RFPSection6_20060926_0005.doc
Upcoming SlideShare
Loading in …5
×

RFPSection6_20060926_0005.doc

423 views

Published on

Published in: Health & Medicine, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
423
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

RFPSection6_20060926_0005.doc

  1. 1. Introduction: 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 1 6 1.1 6.1 … … 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 review. 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. 2. Please direct questions or comments to the list or to myself. Thanks John
  3. 3. 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 (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. 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.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-
  5. 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 this specification which must be supported in order to claim conformance to the profile.  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 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.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
  6. 6.  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 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.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 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. 7. 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 business needs. 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 made  that it delineates specifically the semantic signifiers by which responses will be delivered  that it supports nested queries of one semantic signifier from within another semantic signifier 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.
  8. 8. [TODO: Need model Dumpout]
  9. 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. > 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
  10. 10. 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 these functions. 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
  11. 11. Applicable Description Relationship Notes Standard 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 CDA-conformant representations as the structure and semantic of the data it is managing. HL7 EHR The HL7 See Appendix A of the HL7 Electronic SFM. Health Record 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 HL7-conformance profiles of the RLUS specification. For these profiles, the RIM and other RIM-derived information models identify the data elements, data types, structure, and underlying terminologies for payload crossing the RLUS service interfaces. See Appendix B of the SFM for the RIM, and Section 4.3.1.3.2 for the RIM class representations of the RLUS metadata elements. 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
  12. 12. Profile. The scope of RLUS is more generalized, and assumes more generalized standards for information and data exchange. 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 Templates below. 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- to-service RLUS 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 appropriate functional boundaries and expectations without creating a normative concept. This specification will likely take on added importance in the OMG process. World Wide The W3C’s URI W3C Web specification is important Consortium’s in identifying objects on Universal the Internet, and contains a
  13. 13. 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 Resource Naming. URI’s deprecates the popular concept of Universal Resource Locations (URL’s), in that a URL is an informal concept within URI’s. Specifically, URL’s 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 a http://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.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 approaches. Mandatory requirements should be stated using phrases such as:
  14. 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. 15. The abstract syntax of a language shall be specified as a MOF-compliant metamodel 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, 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 as specified in the HL7 RLUS SFM Section 5 Capability descriptions for each
  16. 16. 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 conformance profiles. 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 criteria. 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 impacts. 2. Submissions may define and support additional semantic, functional and conformance profiles (e.g. Lab Orders, Continuity of Care Records, Care Record Summaries)
  17. 17. 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 level queries). 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 represented. 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 mandatory components. 5. Submitters will discuss how constraints will be addressed on Semantic Signifiers, regardless of the Semantic Profiles supported, and the formalisms used for constraint representation. 6. Submitters will discuss the formalisms used for Semantic Signifier representation if they are differentiated in implementation from the constraints on Semantic Signifiers. 7. Submitters shall discuss if and how the use cases in HL7 RLUS SFM section 3 are addressed by the submission.
  18. 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.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 process. > 1. Preference will be given to submissions that most closely align with the HL7 RLUS SFM. 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 Binding Approach”) 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.
  19. 19. 8. Preference will be given to submissions that support both HL7 and non-HL7 Semantic Profiles. 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 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.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 rule”) Voter registration closes ?? Initial Submission presentations June 2007 Preliminary evaluation by TF June 2007
  20. 20. Revised Submissions due and placed on August 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 the list and brief description of chapters in Chapter 1. > Appendix A References and Glossary Specific to this RFP 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, http://www.omg.org/XXXl.htm [HL7] Health Level 7 http://www.hl7.org/ [HL7 V2.5] HL7 Messaging Standard: V 2.5 http://www.hl7.org/ [HL7 V3] HL7 Messaging Standard: V 3 http://www.hl7.org/ [HL7 RIM] HL7 Reference Information Model http://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. 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 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 versioned. 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.

×