1. 6/4/2016 8:05 PM Healthcare Services Specification Project Decision Support Service (DSS) Overview and Areas of Active Discussion HL7 Clinical Decision Support Technical Committee HL7 Service Oriented Architecture Special Interest Group OMG Healthcare Domain Task Force Prepared by Kensaku Kawamoto, Duke University HL7 Clinical Decision Support Technical Committee HL7 Service Oriented Architecture Special Interest Group OMG Healthcare Domain Task Force Prepared by Kensaku Kawamoto, Duke University January 2006

2. Page 2 History Based on Web service approach to clinical decision support developed at Duke University 1 Project initiated within HL7 Clinical Decision Support (CDS) Technical Committee (TC) in Sept. 2005 Joint project between HL7 CDS TC and Healthcare Services Specification Project (HSSP) 1 Kawamoto K and Lobach DF. Design, implementation, use, and preliminary evaluation of SEBASTIAN, a standards- based Web service for clinical decision support. Proc AMIA Symp. 2005:380-384.

3. Page 3 Business Purpose Clinical decision support systems (CDSS) have been shown to significantly improve care quality However, CDSS use is quite limited, due in part to cost and difficulty of implementing effective CDS capabilities CDS capabilities can be more easily implemented using services that provide required functionality, e.g. –Record Locate and Update Service  to retrieve required data –Decision Support Service  to draw conclusions about patient –CIS Action Brokering Service  to translate conclusions into CIS actions DSS purpose: to reduce cost and complexity of CDSS design, implementation, and maintenance

4. Page 4 Functional Capabilities DSS provider = guardian of CDS knowledge modules A DSS evaluates patient data using knowledge modules and returns machine-interpretable conclusions Sample Evaluation InputSample Evaluation Output Medication ID, age, gender, weight, serum creatinine Recommended max/min doses, adjusted for renal clearance Age, gender, co-morbidities, chief complaint Admission order set in HL7 format Age, gender, co-morbidities, past care procedures Recommended health maintenance procedures (e.g. immunizations) Insurance provider, data relevant to prescription Prior authorization to prescribe medication Operations provided to meet supplemental information needs (e.g. identification of relevant knowledge modules)

5. Page 5 Scope of Specification Work DSS functional requirements Service payloads as necessary Conformance profiles

6. Page 6 Benefits of Standard DSS providers (e.g. knowledge vendors, government) –Expansion of potential client base –Scalable deployment architecture –Minimal restrictions on how underlying knowledge is represented DSS consumers (e.g. CIS vendors, healthcare institutions) –Ability to easily integrate CDS capabilities into applications –Access to multiple knowledge bases through single interface

7. Page 7 Core Service Operations Decision Support Service Service Client 1. Evaluate Patient Modules to use, required data, (eval. time) Knowledge module evaluation results 2. Find Knowledge Modules Search criteria Modules meeting criteria 3. Describe Knowledge Module Module of interest, sections of interest Description of module sections 4. Get Data Requirements Modules of interest, data avail. to client, (eval. time) Data requirements, whether avail. data sufficient

8. Page 8 Areas of Active Discussion How to distribute specification work between HL7 and OMG How to make service extensible and future-proof How to constrain service to enable interoperable use How to specify information payloads

9. Page 9 Questions? If you have any questions, or if you would like to contribute to the DSS specification, please contact: Kensaku Kawamoto Project Lead, DSS Project M.D.-Ph.D. candidate Division of Clinical Informatics Department of Community and Family Medicine Duke University kawam001@mc.duke.edu (919) 684-2340