HSSP DSS Project Team Presented by Kensaku Kawamoto, MD, PhD

1. January 2009 Healthcare Services Specification Project Decision Support Service (DSS)Update for CDS TC, HL7 WGM, Orlando, FL HSSP DSS Project Team Presented by Kensaku Kawamoto, MD, PhD Assistant Professor, Duke University Division of Clinical Informatics kawam001@mc.duke.edu

2. Disclosures • The parties involved in the OMG DSS specification process, including myself, have financial interests in the DSS • I am a co-owner of Kedasys LLC, which holds IP rights to a CDS technology known as SEBASTIAN. A patent application on the SEBASTIAN technology has been filed. • Kedasys is working with Religent, Inc., in the context of an NLM STTR grant to commercial the SEBASTIAN technology. • Myself and Duke University may benefit financially if products utilizing SEBASTIAN are commercially successful. • SEBASTIAN may provide its capabilities through an HSSP Decision Support Service interface. • The other vendors participating in the OMG DSS specification process are planning to offer commercial implementations of the HSSP Decision Support Service as well. • SEBASTIAN represents just one of potentially many approaches for instantiating a DSS. • The OMG process requires any IP necessary for implementing the DSS specification to be made available for free or on reasonable and non-discriminatory terms.

3. Brief Review • Decision Support Service (DSS): part of HL7-OMG Healthcare Services Specification Project (HSSP) • HL7 defines Service Functional Model (SFM) • OMG defines technical specification based on SFM • 2 services have completed full process (RLUS & EIS) • DSS functionality • Takes patient data as the input and returns patient-specific inferences as the output • Generates inferences using knowledge modules • HL7 DSS SFM adopted as DSTU in Sept 2006 cycle

4. Project Update • OMG technical specification undergoing active work • dbMotion of Israel taking the lead on specification • other contributors to the submission: Religent, Software Partners, 88solutions • Primary work products: detailed UML technical specification and XML Web services specification • Target OMG specification completion of June 2009

5. Agenda • Review of major decisions made to date • Discussion of outstanding questions • In particular, need for coordination across HSSP services on semantic signifiers

6. Agenda • Review of major decisions made to date • General directions & specification principles • Specific modeling decisions & changes • Discussion of outstanding questions

7. General Specification Principles • Focus on infrastructure • Rationale: infrastructure needed first and foremost; semantics being defined elsewhere and not yet adopted (e.g., vMR, PHER immunization forecasting messaging, Infobutton) • Specify semantic profiles as appropriate, e.g., for immunization CDS • Standardize when necessary, but do not standardize when unnecessary and may constrain desired implementation flexibility • E.g., allow vendor-specific representations for intermediate state of iterative interactions

8. KM Life Cycle Model Note: red arrows represent new KM version • 2006 dbMotion Ltd.

9. Explicit Support for Iterative Interactions • E.g., KM for identifying need for mammogram • 4 data requirements defined: age, gender, past mammogram history, past mastectomy history • Initial set of data required for evaluation identified in KM • E.g., age and gender • If conclusion reached with initial data  result returned • E.g., patient is male and does not need mammogram • If conclusion not reached with initial data  • intermediate state data + additional data need returned • E.g., [intermediate state data], provide mammogram and mastectomy history data • Final result returned after intermediate state data + additional required data provided

10. Multiple Other Enhancements/Specifications • All enhancements/specifications consistent with intent of original HL7 SFM • E.g., use of OIDs to identify business object owners • E.g., KM evaluation result represented by 1…* semantic signifiers, rather than 1 and only 1 signifier

11. Agenda • Review of major decisions made to date • Discussion of outstanding questions • Mechanism for specifying semantics (implem. guides?) • Common semantic signifier service • Relationship to other HL7 work efforts • Relationship to relevant external efforts

12. Mechanism for Specifying Semantics • True interoperability requires use of common semantics • Initial step in HL7 is development of appropriate RMIMs with relevant actors (e.g., between a “CDS system” and a “CDS client system”) • Possible approaches to specifying use of RMIMs in DSS and other HSSP services: • Semantic profiles adopted in HL7 • Semantic profiles defined outside of HL7 (e.g., X12, NHS, etc.) • Implementation guides adopted in HL7

13. Common Semantic Signifier Service • Needed by many HSSP services (e.g., RLUS, EIS, DSS) • Potential for duplication/divergence of effort • E.g., transformation instructions for display purposes (e.g., XSLT for XML) in RLUS OMG specification, but not needed for DSS • Possible routes at specification • Formal HSSP process • HL7 implementation guide • Coordination among existing efforts • Desire for shared approach, and possibly shared repository

14. Relationship to other HL7 Work Efforts • Arden Syntax • DSS interface? • vMR • Specify semantics within DSS? • GELLO • Specify DSS data requirements and/or logic? • Domain-specific CDS messages (e.g., vaccine forecast, genomics) • Basis of DSS profile or implementation guide? • Infobutton standard, version 2 • DSS profile or implementation guide? (active work)

15. Relationship to Relevant External Efforts • HITSP • IHE • CCHIT • Others?

16. Next Steps • Continue OMG DSS specification • Establish approach(es) to semantic profiling • Define semantic profiles • Establish common approach to semantic signifiers • Harmonize effort with other HL7 initiatives • Interface with relevant external efforts