Alan Honey Kaiser Permanente

1. May 2007 Healthcare Services Specification Project (HSSP)HL7 Services Oriented Architecture SIGEntity Identification Service (EIS) RFP Discussion (May 2007 WGM) Alan Honey Kaiser Permanente

2. Introduction • The purpose of this presentation is to give background and overview of the Entity Identification Service (EIS) RFP. • This will cover: • Background • Service Functional Model (HL7 DSTU ) • OMG RFP Process • EIS RFP Specifics • The full RFP document is available at: • http://hssp-eis.wikispaces.com/

3. Background • Under a joint agreement between HL7 and OMG, the Healthcare Services Specification Project (HSSP) has been chartered to provide a mechanism to develop standard specifications for healthcare services. • The first three services through the pipeline are: CDS (Clinical Decision Support), RLUS (Retrieve, Locate, Update Service) and EIS (Entity Identification Service) • All three passed ballot as DSTUs in the September ballot cycle. The EIS SFM (Service Functional Model) was subsequently approved by the HL7 board as an HL7 DSTU in December 2006.

4. EIS SFM • The EIS SFM (Service Functional Model) was approved as an HL7 DSTU in December 2006, after ballot in the September ballot cycle. • This provides a business level (or conceptual specification) of a set of capabilities that should be provided by an Entity Identification Service • Copes with different entity types (people, patients, providers, devices etc) and multiple domains (national, regional, inter and intra organization) of use. • Provides a flexible approach to metadata that allows dynamic definition of a set of traits that can be used to identify entities • The OMG RFP requests production of the technical specification that provides the capabilities expressed in the SFM

5. EIS SFM Capabilities Summary • The following capabilities are defined in the EIS SFM • Metadata Interface (allows dynamic management of entity types, traits and domains) • Entity Management Interface (manages entity information) • Create Entities and update associated trait values • Merge/Unmerge, Link/Unlink entities • Query Interface • Find candidate entities based on combinations of values (e.g. for person, name, address, telephone number) • List supported metadata and profiles • Notifications of changes to entity trait values • Semantic and Functional Profiles provide the means to control variation and bind to existing semantic standards (e.g. HL7 domain models)

6. OMG RFP Process • Development and Issuance of RFP (Complete 12/06) • RFPs drafted and approved by Healthcare Domain Task Force (HDTF) and OMG Architecture Board (AB) • Approved and issued by OMG Technical Committee • Letter of Intent (LOI) (3/31/07) – 6 LOIs received. • Letter of Intent (LOI) must be signed by an officer of the organization which intends to respond to the RFP, confirming the organization’s willingness to comply with OMG’s terms and conditions, and commercial availability requirements. • In order to respond to an RFP the respondent must be an OMG member. • Voter Registration (Closes 9/21/07) • Interested OMG members, other than Trial, Press and Analyst members may participate in specification selection votes in the HDTF. They must register by xx/xx. Member organizations that have submitted an LOI are automatically registered to vote. • Initial Submissions (Due 09/04/07) • Initial Submissions are due by a specified deadline. Submitters normally present their proposals at the first meeting of the TF after the deadline. Initial Submissions are expected to be complete enough to provide insight on the technical directions and content of the proposals. • Revision Phase • During this time submitters have the opportunity to revise their Submissions, if they so choose.

7. OMG RFP Process • Revised Submissions (Due 11/19/07) – Pending Submitters timeline • Submitters normally present their proposals at the next meeting of the TF (may be more than one revised submission period) • Selection Votes • A selection vote is taken. The AB reviews the proposal and then moves the voting process into the issuing Technology Committee. • An eight-week voting period ensues in which the TC votes to recommend adoption to the OMG Board of Directors (BoD). The final vote is taken by the BoD and is based on technical merit as well as business qualifications. The resulting draft standard is called the Adopted Specification. • Business Committee Questionnaire • The submitting members need to submit their response to the BoD Business Committee Questionnaire [BCQ] detailing how they plan to make use of and/or make the resulting standard available in products. If no organization commits to make use of the standard, then the BoD will typically not act on the recommendation to adopt the standard. • Finalization • A Finalization Task Force (FTF) is chartered by the TC that issued the RFP, to prepare an adopted submission for publishing as a formal, publicly available specification. • The FTF must also provide evidence of the existence of one or more prototype implementations. The parent TC acts on the recommendation and recommends adoption to the BoD. OMG Technical Editors produce the Formal Published Specification document based on this Available Specification. • Revision • A Revision Task Force (RTF) is normally chartered by a TC, after the FTF completes its work, to manage issues filed against the Available Specification by implementers and users. The output of the RTF is a revised specification reflecting minor technical changes.

8. EIS RFP Details • Mandatory Requirements • Provide a Platform-Independent Model (PIM) expressed using UML. • Present a PSM for WSDL with a SOAP/HTTP binding. • Define operations that provide all capabilities defined in sections 5 of the SFM (Metadata management optional) • Support the “HL7-V3-RIM-V2.14-Patient” Semantic profile and all Functional Profiles identified in Section 6 of the SFM. • Justify deviations from the normative sections of the SFM (specifically sections 5 and 6) • Describe behavior of all included operations. Resolve open questions associated with included operations within sections 5 and 10 of the SFM. • Identify level of support for the Service Metadata interface (section 5.2) in the SFM. • Define operations that support variability in Entity Type as described in the SFM. • Provide a run time query for which conformance profiles are supported. • Define how to uniquely identify entities. This must include both user-defined and system defined options, which must be able to be configurable by systems administrators. • Define values, associated meaning and allowable actions on “Status” attributes for entities and metadata objects (e.g. pending, active, deprecated, marked for deletion).

9. EIS RFP Specifics • Mandatory Requirements (cont) • If supported, define impact of status changes on metadata objects. • Identify limitations on whether only Traits with appropriate Status (e.g. “active”) should be able to be assigned to entities • Do not preclude the use of EIS instances in simple and distributed (hierarchic and peer-to-peer) topologies. • Identify and describe PSM-specific technical conformance criteria. • Provide a means for authorized roles to retrieve entities that have an “inactive” status. • Optional Requirements • Define PSMs for platforms additional to the Mandatory Requirements • Define and support Semantic, Functional and Conformance Profiles additional to those defined in the Mandatory Requirements (e.g. Providers, HL7 V2 Patient information, Medical Devices). • Include behavior that provides some level of automated implicit linking capabilities. • Include additional operations specific to an Entity Type (e.g. findPersonByTrait). • Provide a run time interface to define and maintain which conformance profiles are supported by an EIS instance.

10. EIS RFP Specifics • Items for Discussion • Identify relevant HITSP use cases and standards and discuss the relationship to the specification. • Explain how the specification addresses any information content that is not explicitly specified in the SFM. • Discuss if and how information constructs in the specification relate to the HL7 Reference Information Model (RIM) • Discuss if and how the use cases in SFM section 3 are addressed by the submission. • Discuss implications of the PSM on deployment topology, preferably including UML Deployment diagrams • Discuss issues relating to service description and discovery. • Discuss how the submission relates to the IHE PIX and PDQ Profiles. • Discuss approach taken to federation, including how the submission could be deployed to support a National context (such as the US National Health Information Network - NHIN). • Discuss the approach to defining and testing conformance assertions.

11. EIS RFP Specifics • Evaluation Criteria • Preference will be given to submissions that most closely align with the SFM. • Preference will be given to submissions that support all of the operations defined in the SFM. • Preference will be given to submissions that most closely align to the principles cited in the SFM Section 4.1 (“Service Definition Principles”). • Preference will be given to submissions that most closely align to the principles cited in the SFM Section 9 (“Information Model and Semantic Binding Approach”) • Preference will be given to submissions that define profiles that support the functionality provided by IHE PIX and PDQ Profiles • Preference will be given to submissions that support the extensibility inherent in the SFM. In particular, a solution that supports multiple domains and entity types and extensible trait sets will be given preference. • Preference will be given to submissions that support both hierarchic and lateral (peer-to-peer) distributed topologies for handling of multiple Entity Domains.

12. Discussion / QuestionsFor further details, see:http://hssp-eis.wikispaces.com/