Kensaku Kawamoto M.D.-Ph.D. candidate Duke University kawam001@mc.duke

1. January 11, 2006 Healthcare Services Specification Project Decision Support Service (DSS) Overview and Outstanding Issues Kensaku Kawamoto M.D.-Ph.D. candidate Duke University kawam001@mc.duke.edu

2. Agenda • Healthcare Services Specification Project (HSSP) • DSS Service Functional Model (SFM) • Outstanding Issues • Work Plan and Timeline

3. Agenda • Healthcare Services Specification Project (HSSP) • DSS Service Functional Model (SFM) • Outstanding Issues • Work Plan and Timeline

4. Healthcare Services Specification Project • Effort to create common service interface specifications for services important to Health IT • Joint project of HL7 and the Object Management Group (OMG) • OMG: vendor consortium producing specifications for interoperable enterprise applications; specified UML and CORBA • Current services • Entity Identification Service (EIS) • Record Location and Access Service (RLAS) • Common Terminology Service (CTS) – owned by Vocab TC • Decision Support Service (DSS) – owned by CDS TC

5. HSSP Process – HL7 • Identification of standardization candidates • Specification of Service Functional Model (SFM) • Use of Service Development Framework (SDF) & SFM template • Core SFM components: • Business case and business scenarios • Specification of service functionality • Specification of service payloads as necessary • Conformance profiles • Aspects not requiring specification by HL7 intentionally left for OMG to specify • Quality assurance by HSSP • Balloting as Draft Standard for Trial Use (DSTU)

6. HSSP Process – OMG • Coordinated by Healthcare Domain Task Force (DTF) • HL7 SFM used as basis for Request for Proposal (RFP) • Request for specification of a platform-independent model (PIM) and at least one platform-specific model (PSM) (e.g. SOAP/XML) conforming to SFM requirements • Letters of intent to specify and implement within 12 mo.  initial specifications  single revised specification based on merged efforts • Approval by Healthcare DTF  Architectural Board  Technology Committee  Board of Directors • Specification not adopted unless at least one implementation available commercially

7. Agenda • Healthcare Services Specification Project (HSSP) • DSS Service Functional Model (SFM) • Outstanding Issues • Work Plan and Timeline

8. DSS SFM – 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

9. DSS SFM – Functional Capabilities • DSS provider = guardian of CDS knowledge modules • A DSS evaluates patient data using knowledge modules and returns machine-interpretable conclusions • Operations provided to meet supplemental information needs (e.g. identification of relevant knowledge modules)

10. DSS SFM – Scope of Specification Work • DSS functional requirements • Service payloads as necessary • Conformance profiles

11. DSS SFM – 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

12. DSS SFM – Service Operations 1. Evaluate Patient Decision Support Service Service Client 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 *Version management operations intentionally left for OMG to specify

13. Agenda • Healthcare Services Specification Project (HSSP) • DSS Service Functional Model (SFM) • Outstanding Issues • Work Plan and Timeline

14. Summary of Outstanding Issues • What to specify in HL7 and what to leave for OMG • How to make service extensible and future-proof • How to constrain service to enable interoperable use • How to specify information payloads

15. Roles of HL7 & OMG in Specification Work • Rules of thumb • Specify business requirements at HL7, specify technical requirements at OMG • Specify within HL7 if important to HL7 community that something is specified within HL7 • Specify minimal amount as possible within HL7, leave everything else to OMG to specify • Examples • Important to CDS TC what meta-data are associated with a knowledge module  specify within HL7 • Not important to CDS TC how knowledge module search criteria are specified or how such criteria are aggregated  leave for OMG

16. Extensibility to Future-Proof Service • Service payloads requiring high degree of extensibility • Knowledge module data requirements • Knowledge module evaluation results • Service payloads not requiring extension (?) • Knowledge module meta-data / search criteria • Strategy for allowing content to be extended • Establish repository of information models (e.g. RMIMs similar to Patient Care TC’s Care Record Query RMIM; specializations of a generic DSS knowledge module Entity) • Specify information payloads by calling out to repository contents • Questions • Who maintains the information model repository, and how? • How do others search and use the repository?

17. Care Record Query RMIM (Patient Care TC)

18. Document Query RMIM (Medical Records TC)

19. Potential DSS KM Data Requirements / Queries

20. Constraining Service for Interoperability • Generic standards require constraints to achieve semantic interoperability • E.g. XML, SOAP, RIM, etc. • DSS examples of issue • Want to allow flexibility in the data required by DSS modules, but want consistency in how common data requirements are specified • Want to allow flexibility in the patient evaluation inputs and outputs, but want consistency when similar CDS capabilities are provided • Potential solution: use of profiles • Profile = any constraint pattern placed on DSS providers or on individual knowledge modules that profess to support the profile

21. Sample Profiles • Profiles applying to individual knowledge modules (KMs) • “Drug dosing KM profile” • KM requires med. ID, age, gender, weight, serum creatinine • KM returns min and max doses adjusted for renal clearance • “Health maintenance procedure KM profile” • KM returns whether health maintenance procedure (e.g. mammogram) due; date last done; date procedure next due • “Basic data requirement KM profile” • KM requires only demographic data and core, simplified Act data • Profiles applying to a service • “Basic medication DSS profile”  DSS contains KMs implementing “Drug dosing KM profile,” “Drug-allergy KM profile,” & “Drug-drug interaction KM profile”

22. Specification of Service Payloads • Specification needs • DSS KM meta-data • DSS KM evaluation results • DSS KM data requirements (intended to be passable to RLAS to request record query) • Client data availability (intended to be compatible with what is returned by RLAS to describe supported queries) • Possible specification needs • Communication of DSS KM evaluation results • Response to communication of DSS KM evaluation results • Questions • How should we go about specifying these information models? • Which TCs/SIGs should manage this process?

23. Agenda • Healthcare Services Specification Project (HSSP) • DSS Service Functional Model (SFM) • Outstanding Issues • Work Plan and Timeline

24. Work Plan and Timeline • Desired timeline • 6/06: post RFI and scope statement to HL7 HQ • 7/06: issue SFM as CDS TC DSTU ballot • 9/06 (Boca Raton): committee ballot reconciliation • 11/06: issue SFM as HL7 membership DSTU ballot • 11/06: prepare OMG RFP based on SFM • Late 2007/early 2008: OMG specification adopted, commercial products available • Work plan to realize timeline • Modeling of relevant information constructs • Establishment of mechanism for calling out to HL7 information constructs