100 likes | 206 Views
May 2006. HSSP Retrieve, Locate, and Update Service (RLUS) Functional Model Overview and Areas of Active Discussion. HL7 Service Oriented Architecture Special Interest Group OMG Healthcare Domain Task Force Prepared by John Koisch, OCTL Consulting jkoisch@octlconsulting.com. Context.
E N D
May 2006 HSSP Retrieve, Locate, and Update Service (RLUS) Functional Model Overview and Areas of Active Discussion HL7 Service Oriented Architecture Special Interest Group OMG Healthcare Domain Task Force Prepared by John Koisch, OCTL Consulting jkoisch@octlconsulting.com
Context • The Retrieve, Locate and Update Service (RLUS) SFM provides a set of functional behaviors through which information systems can manage information. • Many existing technical standards that need unification, healthcare applicability, or semantics • IHE XDS, UDDI, ebXML, OMG COAS • RLUS explicitly occupies the service space • “…Independent of but compatible with underlying structures, including local security implementations, data models, or delivery mechanisms.”
Business Purpose • Within a mobile society, it is natural to consider that patients be mobile and their medical information be decentralized • RLUS encompasses common business practices (resource search, resource retrieval, &c.) that are a part of most business scenarios in healthcare • As a service specification, it complements existing applications and structures. Figure 1: Possible Application Stack including RLUS (Informative only)
RLUS Scope and Conformance • RLUS uses two dimensions to characterize standards for conformance: • Interfaces • Location • Retrieval • Updating • Semantics • HL7’s RIM • OpenEHR’s GOM / ADL • Others • Conformance is driven by guaranteeing semantic / behavior combinations through service interfaces • RLUS HL7 Locate profile • RLUS ADL Updating profile
Functional Dimensions • Interfaces • Locate by some parameter • f (patientId) = [List of EMRs available] • Locate “nested” information • f (patientId, [RMIM x]) = [List of x available] • Retrieve • Retrieve and Transform • Update
Core Service Operations Functional Interface Function Call Locate Information by Parameter RLUS Service Client FindProblemListLocations(_patientID, “problemList”) List of Information Locations [ProblemList Locations] Retrieve Information By Parameter GetProblemList(PBL001, PBL001Req) Parameterized Information [PBL001] Update Resource UpdateResource(_resourceID, [resource], _versionInformation) Acknowledgement
Scope of Specification Work • RLUS functional specification (HL7) • Business Cases and requirements • Interface Definitions • Conformance Profiles (Interfaces + Semantics) • RLUS technical requirements (OMG) • Administrative interfaces • Technical requirements (performance, scalability, extensibility) • Platform Bindings (WSDL, CORBA, &c.)
Benefits of Standards • Service standards provide the foundation for service agreements between trading partners • “RLUS HL7 Locate” is testable and measurable • Functional standards provide foundations that support business cases and functional component interactions • They provide a “territory” for the technical specifications to “map” against
Areas of Active Discussion • How to distribute specification work between HL7 and OMG • How to make service extensible and future-proof • How to relate to existing implementations (IHE XDS, eg) • How to constrain service to enable interoperable use • How to specify information payloads
Questions? • If you have any questions, or if you would like to contribute to the DSS specification, please contact: John J. Koisch Project Lead, RLUS Project Co-Chair, HL7 SOA SIG (HSSP Project) Chief Architect, OCTL Consulting jkoisch@octlconsulting.com (253) 223.4344