Terminology and code system services in Finland CTS

1. Terminology and code system services in Finland + CTS HL7 WGM meeting, Noordwijkerhout, May 2005 Juha Mykkänen (includes material from various other people) University of Kuopio, HIS R & D Unit Finland SerAPI project – www.centek.fi/serapi

2. 2 This presentation Overview of two terminology-related developments in Finland national code server API interfaces for centralized terminology services (CodeAPI) Relation to CTS and future

3. 3 Recent developments in Finnish healthcare IT National project for health reform started in 2002 has strong NHII component focuses in achieving interoperable EPR/EHR systems, HL7 CDA has a strong role other IT components: code service, security, identification, regional systems, archives… project schedule: till the end of 2007 Many R & D activities, including National Technology Agency TEKES FinnWell-programme Regional systems and projects, now related to the two above

4. 4

5. National Code Server (note: no speaker affiliation, thanks to Matti Ojala/Stakes, Timo Pessi/Datawell and Jari Lehtonen/Stakes)

6. 6 National code server: background and status part of National Health Project (Ministry of Social Affairs and Health) subproject in National Research and Development Centre for Welfare and Health (STAKES) 2003-2004 Purpose: national digital updating and distribution system for terms, glossaries, classifications and related codes Running since 2004 at: http://koodistopalvelu.stakes.fi now 20 code systems in production environment e.g. ICD-10, Medical procedures, Lab test and physiotherapy nomenclatures, several HL7 2.3 classifications etc.

7. 7 Why code server? 1. Makes glossaries, classifications and codes better available and updated; 2. Improves cooperation and boosts productivity in the social and health care service chains, compilation of statistics, monitoring, planning and sharing of information systems; 3. Enables crossing of boundaries between sectors, service providers, units and information systems; 4. Enhances electronic service production in the social and health care sector; 5. Supports the creation of new operating models in the social and health care sector; 6. Supports information system developers in the social and health care system who need classifications, codes, glossaries or data on organization units; 7. Helps in developing electronic processes in the social and health care service system, putting functions online or reaching out digitally to new interest groups and user groups; 8. Helps in harmonizing information structures using classifications, codes, glossaries or organization unit data in social and health care sector information systems; 9. Creates a foundation for the development of information management tools for instance with keywords; 10. Links the national code service to international code servers.

8. 8 CodeServer - description CodeServer is used to create, save and update code sets and to publish them for health professionals and information systems CodeServer is browser-based - distributed maintenance to various organizations responsible of different code sets Modifications are in one location, which eases the maintenance and improves information quality Code set transformations between different systems Includes interfaces to distribute codes to external systems

9. 9 Provided functionality Creation, copying and modification of code sets Search and browse Code set versioning Validity time definitions Documentation and tracking of changes Support for multiple languages Support for hierarchical organizations and classifications Definition of mappings, links and synonyms Support for local elements XML/SOAP interfaces for direct integration to other IS Exporting functionality, web publishing, e.g. Ecomed, Excel, SAS, XML formats File import for code set producers

10. 10 Codeset export / import interfaces XML messages for transferring codes from national server to regional or local applications available through HL7 Finland other direction also planned e.g. for organizational units use SOAP envelope same way as CDA (R1 and R2) adapters in Finland dataset (reference elements) major uses: import all / new or changed codes for a given code system

11. 11 Example <!DOCTYPE document (View Source for full doctype...)> <document> <header>Stakes koodistopalvelin ohjelmisto: Datawell: CodeServer x.x 22.09.2003</header> <body> <termSystem id="1.2.246.537.6.1.1996" language="fi" createDate="1996-10-01" beginDate="1996-10-01" expirationDate="2005-12-31" lastModifedDate="20030915" lastModifedBy="Stakes"> <atribute type="longname" dataType="ST" language="fi">ICD 10 1996</atribute> <atribute type="maintainer" dataType="ST" language="fi">Stakes</atribute> <termItemEntry id="C00-D00" language="fi" createDate="1996-10-01" beginDate="1996-10-01" expirationDate="2005-12-31" lastModifedDate="2003-09-15" lastModifedBy="Stakes"> <atribute type="shortname" dataType="ST" language="fi" createDate="1996-10-01" beginDate="1996-10-01" expirationDate="2005-12-31" lastModifedDate="2003-09-15" lastModifedBy="Stakes">kasvaimet</atribute> <atribute type="hierarchylevel" dataType="ST">4</atribute> </termItemEntry> …

12. CodeAPI interfaces shared services for applications using code systems

13. 13 Background: PlugIT project To find solutions to the integration problems, we established an applied research project that had three kinds of participants: researchers, software professionals from companies, and healthcare professionals from hospital districts and cities. Most of the major software companies developing applications for healthcare participated. 84% of the funding came from the National Technology Agency TEKES, the rest from the companies and hospitals. It was the biggest Software Engineering research project in TEKES, with a budget of 2 million euros and lasting for three years. PlugIT aimed at three types of results: Firstly, interface standards that can be taken into use by the companies in their products. Secondly, methods that can be used by new integration projects after PlugIT. And finally, a centre of expertise, a group of experienced applied researchers that can work on new projects to support the software companies and the healthcare institutions.To find solutions to the integration problems, we established an applied research project that had three kinds of participants: researchers, software professionals from companies, and healthcare professionals from hospital districts and cities. Most of the major software companies developing applications for healthcare participated. 84% of the funding came from the National Technology Agency TEKES, the rest from the companies and hospitals. It was the biggest Software Engineering research project in TEKES, with a budget of 2 million euros and lasting for three years. PlugIT aimed at three types of results: Firstly, interface standards that can be taken into use by the companies in their products. Secondly, methods that can be used by new integration projects after PlugIT. And finally, a centre of expertise, a group of experienced applied researchers that can work on new projects to support the software companies and the healthcare institutions.

14. 14 Shared terminologies and code systems for applications National Code server browser version in use, more code sets added to the service (including ISO OID provider identification) message definitions to transfer code sets to different systems PlugIT common service interfaces, one of which deals with code systems (CodeAPI) centralized functionality (and data), decrease overlapping functionality / maintenance / implementation application-oriented, ”user activity-related” API interface operations search, listing, browse operations on different levels (hierarchies, several languages etc.) different types of interfaces in above two services import code sets from centralized (e.g. national) service use (and possible refer to) codes from centralized (e.g. regional/organizational( service both available also through HL7 Finland

15. 15

16. 16 CodeAPI: Relation to other specifications Used Code transfer messages (HL7 Finland Open CDA project / national code server) information contents of the national code server enables conformance levels in CodeAPI same XML elements used where possible less coding especially in software which uses national code server and offers CodeAPI interfaces for local applications ”authorized” central code service (e.g. regional), specific operations for applications as readily-made services (search, list, browse, etc.) OMG Terminology Query Services (TQS) used as a functional basis; however, only subset of functionality needed in PlugIT + project decision not to use IDL (tool dependencies, technology transition) other PlugIT services (user, access rights, patient etc.) same technology and content conventions, no dependencies HL7 Common Terminology Services (CTS) found extremely useful, details follow

17. 17 CodeAPI specification v2.0 normative: 5-6, appendices 2-4 informative/background: 1-4,7, appendix 1 most suitable level for international harmonization: 3-4?

18. 18 Conformance levels v2.0 3 API interfaces: CodeService, Codeset, Code minimum level only the most necessary operations for centralized code set services for easy connectivity with existing applications: bind to code set, bind to code, list codes, minimum information content (code + designation), get designation by code, get code by designation ”base” in addition to minimum level search capabilities, metadata about supported code sets and services, administrative information about service and code sets ”multilingual” support for different languages in designations and other information ”hierarchy” ”status” by default, also local and ”removed” codes are also returned ”freeElements” in addition to minimum information, other available elements for code entries for different operations ”advSearch” more advanced search capabilities, substrings, keywords, search from arbitrary elements, multiple search keys etc. conformance levels can be used on service or code set levels

19. 19 Interfaces and operations v2.0 CodeService interface GetSupportedCodeSystems: base level GetSupportedServices: base level GetInfo: base level Codeset interface LookupCodesByDesignation: minimum level ListCodes: minimum level LookupCodes: base level GetSupportedCodesetServices: base level IsCodeValid: base level GetCodesetInfo: base level ListLanguages: multilingual GetHierarchyDepth: hierarchy GetCodes: freeElements GetSupportedAttributes: freeElements Code interface GetDesignation: minimum level GetParent: hierarchy GetHierarchyLevel: hierarchy GetStatus: status GetLocal: status LookupCompleteCodedConcept: freeElements LookupProperties: freeElements

20. 20 Content specifications How to connect a given code system to the interface where to get code, designation, language etc… content specification is separate from the interface, ideally one official authoritative content specification for each code set same interface for different code sets CodeAPI v2 ICD-10 content specification mapped to national code server data elements and format provided by the National Research and Development Centre for Welfare and Health (STAKES) additional content specifications e.g. for other code sets in the national service

21. 21 CodeAPI Example: search operation on mimimum level <?xml version=”1.0” encoding=”UTF-8”?> <request xmlns=”urn:plugit:CommonServices”> <interface>Codeset</interface> <method>LookupCodesByDesignation</method> <param> <termSystem id=”1.2.246.537.6.1.1996”</termSystem> <find> <matchText>lavantauti</matchText> </find> </param> </request> <?xml version=”1.0” encoding=”UTF-8”?> <response xmlns=”urn:plugit:CommonServices”> <term id=”A01.0”>Lavantauti</term> </response>

22. 22 CodeAPI Example: search operation (used levels: advanced search, freeElements, multiligual, status, hierarchy) <?xml version=”1.0” encoding=”UTF-8”?> <request xmlns=”urn:plugit:CommonServices”> <interface>Codeset</interface> <method>LookupCodeByDesignation</method> <param> <termSystem id=”1.2.246.537.6.1.1996”/> <find> <matchText language=”fi” partial=”2”>avantaut</matchText> <status>1</status> <local>0</local> <parentId>A00-A09</parentId> </find> <sortBy>id</sortBy> <display> <propertyCodeList> <property>shortname</property> </propertyCodeList> </display> </param> </request>

23. 23 HL7 CTS relationship CTS was ”discovered” when specifying version 2 of CodeAPI ? operation harmonization for CodeAPI v2 CTS: messaging API, Vocabulary API, IDL interfaces CTS reference model is more abstract than in CodeAPI interface technologies: CTS: IDL interfaces (with IDL? Java ?WSDL (rpc/encoded style over http) examples CodeAPI: XML-wrapped operations (over http) – WSDL available for other PlugIT common services CTS: no content specifications, recommendation to use HL7 ConceptProperty codeset

24. 24 Initial comparison / CTS / CodeAPI semantic correspondence to all operations in CTS Vocabulary API (except AreCodesRelated) can be found in CodeAPI operations national code server information has resulted in more specific (and numerous) operations and levels in CodeAPI than in CTS not many CTS Message API operations in CodeAPI (ValueSet, VocabularyDomain etc.), simple reference model and interfaces in CodeAPI – no mapping, code relationships etc. differences etc. whether to return only code id or also designations + elements for different conformance levels in CodeAPI hierarchy / local / status / etc. features as direct parameters in CodeAPI (can be used through reference model, relationships etc. in CTS?) direct use of national code server XML elements in CodeAPI IDL interfaces in CTS (+example of Java and WSDL), XML specifications in CodeAPI OID in code set identification in both specifications id value in code identification in both specifications (no CORBA-type object references etc.) CTS Conformance: runtime and browser separately for Message and Vocabulary API CodeAPI Conformance: several conformance levels for different functionalities

25. End of monologue

26. 26 Possibilities / discussion comparison of requirements for CTS II and CodeAPI (Finland) to find possible candidates for new features or needs (for CTS II Vocabulary API?) examples, use cases (or conformance levels) for CTS II Vocabulary API (see conformance levels in CodeAPI) – also discussed in CTS (to get new users up to speed) walkthrough of export / import interface of national code server link to infrastructure work in HL7/OMG Healthcare Services Specification Project note: both national code server and CodeAPI interface specifications are in Finnish but requirements, functionality and products are generic / international? SerAPI project (SOA / web services focus) participates in Service Specification Project, HL7 Finland (Common Services SIG)

27. 27 Dank u SerAPI project participants: National Technology Agency TEKES (grant no 40437 / 04), Medici Data Oy, Datawell Oy, Fujitsu Services Oy, Hospital district of Northern Savo, WM-data Oy, Commit; Oy, Intersystems B.V. Finland, Mediconsult Oy, Microsoft Oy, Oracle Finland Oy, Hospital District of Satakunta, Bea Systems Oy, Hospital District of Helsinki and Uusimaa, City of Kuopio, Kustannus Oy Duodecim, Mawell Oy