Introduction

The rapid development and use of various health information systems and networks raises the issue of semantic interoperability between heterogeneous health informatics applications. Semantic interoperability may be characterized as the capability of different software systems to share information and to have that information properly interpreted by the receiving system in the same sense as intended by the creators or maintainers of the transmitting system. It involves:

 the processing of the shared information in all systems so that it is consistent with the intended meaning of this information;  the encoding of queries and presentation of information so that it conforms to the intended meaning regardless of the source of information. Standardization and utilization of semantic technologies are indicated as most effective instruments for providing and maintaining interoperability in information systems and especially in healthcare information systems.

Semantic technologies or Semantic Web technologies such as Linked Data, Resource Description Framework (RDF/RDFS), SPARQL and different kinds of domain ontologies are increasingly being used in the health informatics community to respond to the knowledge integration and semantic interoperability needs [1]. In particular, semantic repositories can be used to achieve various goals, such as ability of managing large volumes of heterogeneous data, signifi cant analytical power that is based on abilities of interlinking long-chain evidences, effective data interoperability.

According to [2], "a repository (also referred to as a data repository or digital data repository) is a searchable and queryable interfacing entity that is able to store, manage, maintain, and curate data/digital objects". A repository is a managed location where digital data objects are registered, permanently stored, made accessible and retrievable, and curated [3]. Repositories preserve, manage, and provide access to many types of digital resources, available in a variety of formats. Resources in online data repositories are curated to provide their search, discovery, and reuse.

This paper aims to present some results achieved in the development of a pilot version of semantic repository for clinical data received in formats used by the information system of the Bulgarian National Health Insurance Fund (NHIF).

Key features of a semantic repository for clinical data

Semantic repositories are software systems similar to database management systems (DBMSs). They allow the storage, retrieval and management of structured or semi-structured data. The main differences between semantic repositories and traditional DBMSs can be summarized as follows:

 the data in the semantic repositories are presented in RDF format and ontologies are used as data schemas that allow for automatic analysis and formal reasoning;  the physical data model is fl exible and schema independent, which simplifi es the integration of additional knowledge and schemas, in particular the integration of relevant subject ontologies.

The minimum functionality of a software system that plays the role of a semantic repository of clinical data should include:

 reading XML documents, validating them and presenting them as RDF documents in different formats;  loading RDF documents into the semantic repository;  retrieving particular documents, specifi ed by fl exible queries;  providing an interface that allows defi ning and executing SPARQL queries to the system;  adding a single document or a set of documents to the semantic repository. The addition of documents should be implemented in compliance with the requirement of sustainability over time, and assistance that unplanned interruption of the system operation should not cause loss of information;  editing existing documents and loading their modifi ed versions to the repository;  retrieving the entire document set so that it can be easily integrated with different external systems using various RDF formats.

In addition to meeting these general requirements, a semantic repository of clinical data oriented to real-world practical applications should also provide  maintaining an interface to the corresponding core information system while maintaining the ability to handle documents in real time;  identifying ways to connect the system to other (external) systems, in particular with appropriate graph or relational databases;  developing additional systems to provide means of visualizing the documents used by the core system.

Fully to exploit the capabilities of a semantic repository, and in particular a semantic repository for electronic patient records, it should include multiple domain ontologies of various types. First, appropriate subject ontologies describing socially signifi cant diseases, their diagnosis, planning of appropriate therapy, etc. should be selected or in some cases developed especially for this purpose. The inclusion of such ontologies enables the development of semantically interoperable information systems, decision support systems, data mining systems, and other types of intelligent software systems in the healthcare domain.

System design

As a part of the work on the more general task of defi ning and analyzing key requirements for clinical data processing and data exchange systems, a project has been developed and a pilot version 0of a semantic repository for outpatient sheets has been implemented, which covers all functionalities mentioned above. The project is oriented towards solving the following specifi c tasks:

 providing a convenient application interface, enabling opportunities for working with documents in real time;  determining a technology of connecting the system with other (external) systemsgraph or relational databases;  development of an additional system that can provide means for visualization of the documents with which the main system works.

The structure of the repository management system of is shown in Fig. 1. It consists of a number of packages:

 The Commands package is the main entry point for working with the system. It implements the commands that the system can execute from the command line.  The Converter package implements a library that takes care of working with fi les in XML, XSD and RDF formats, defi ning methods for transformations between XML fi les and sets of RDF triples. The library also supports operations that can retrieve subsets of triples of an RDF graph. The structures in this package are used by both the Commands and the Server package.  The Server package contains two main parts: an implementation of a REST API server, which defi nes the operations that can be performed with the content of the semantic repository, and a number of static fi les, which are Swagger documentation of the API server. In this way, a convenient user interface is supported to manipulate the stored resources.

 The Settings package contains a description of the system settings.  The Data Store object is a folder with the data fi les stored by the system.

To provide the functionalities of the system, the following workfl ows are implemented in a dynamic way:  "XML" → "python dictionary" -converts XML messages to serialized python format in the form of dictionaries;  "python dictionary" → "RDF graph" -converts python dictionaries to RDF graphs;  "RDF graph" → "RDF subgraph" -constructs an RDF граф according to a set of criteria. They are designed to implement the main functionalities of the system in the form of consecutive steps, passing through the selected intermediate serialized python format.

For example, for the purpose of document transformation in the "XML" → "python dictionary" direction, the XmlParser class is used, which has the following methods: constructor Reads an XML element in a dictionary structure Builds an XML element as a dictionary structure Builds an XML string from a dictionary structure Validates an XML string Validates the content of an XML fi le Converts an XML string to a dictionary structure Converts an XML fi le to a dictionary structure Gets the value of a dictionary element and for the transformation of a document in the direction "python dictionary" → "RDF graph", the RdfBuilder class is applicable with the following methods:

__init__(self, namespace, identifi ers) get_child_value(name, children) parse_uri(self, uri) get_children_signature(item) get_node(self, item, parent) parse(self, item, parent, graph) parse(self, data, parent, graph)

constructor Gets the value of a list element given by its name Converts a URI to node name and identifi er Gets the cryptographic signature of the adjacent elements of the node Gets the URIRef of a graph node from its own dictionary and the parent structures of the dictionary Converts the elements at a given level in a graph and adds URIRefs to the graph Converts a dictionary structure and loads it into an RDF graph Thus, the transformation in the "XML" → "RDF graph" direction is performed in two steps using the XmlParser and RdfBuilder classes, respectively.

Data fl ow and document representation

The input data with which the system works are documents -anonymized monthly reports to the NHIF of doctors (general practitioners and specialists) for their outpatient activities. They are automatically transformed into the XML format of the NHIF for an outpatient list [4] and its equivalent RDF graphs in various serialized RDF formats [5]: N-Triple, N3, RDF / XML. In this way, the repository, and in particular the data from the outpatient sheets in it can be used for creating different types of semantically compatible healthcare information systems.

The overall data fl ow in the system is shown in Fig. 2. The generated RDF graphs are stored as fi les that describe an individual doctor as a "central point" and present multiple reports and outpatient sheets that are associated with this doctor (Fig. 3). Means for defi ning and executing the main types of SPARQL queries [6] (SELECT, CONSTRUCT, ASK, DESCRIBE) to the contents of the repository are supported. Fig. 4 shows the results of the execution of the following exemplary CONSTRUCT query: This query is intended to construct the set of available RDF triples, which integrates the outpatient sheets containing a primary or secondary diagnosis with a code beginning with E03.

Conclusion

This paper discusses the concept and the design of a semantic repository for clinical data of patients, obtained from periodically received documents -monthly reports of doctors, providers of outpatient care. The presented pilot version of the semantic repository is ready for use. It can be integrated into various types of intelligent software systems, such as:

 information systems in the fi eld of healthcare;  software systems for data analysis and knowledge discovery in medical research data;  healthcare decision support systems.

One of the next goals of our study is the development of an intelligent decision support system. It is designed to assist physicians in diagnosing and recommending treatment and diet plans for patients ill or prone to type 2 diabetes -a socially signifi cant disease that affects a high percentage of the world's population (8.5% in the adult population according to World Health Organization 2016 data [7]). The analysis of the information about freely available medical ontologies indicates that among the most appropriate ontologies for the purposes of this study is the combination of DDO and DMTO [8]. DDO 1 is an ontology for diagnosis of diabetes including knowledge about symptoms, lab tests, drugs, complications, etc. DMTO2 is an ontology for creating customized treatment plans for type 2 diabetic patients. DMTO extends the DDO ontology by adding treatment classes and axioms to the existing diagnosis part. For this purpose, it is planned to develop a software module designed to read anonymized patient data from the repository and automatically create on their basis instances of appropriate classes of DMTO.