The Web of Data is a global data space based on open standards. However, it is still far from reality found in websites: unstructured and disconnected data focused on human understanding. This work aims to mitigate this problem for a portion of data in the health area, data about medical doctors and health facilities. Thus, this paper presents an application ontology designed to accurately represent such data and some examples of instances and queries, which can be used on the development of applications in order to provide precise information for Brazilian citizens.
This work presents an application ontology designed to accurately represent data of medical doctors and health facilities of Brazilian municipalities. Instances of the ontology classes were created following LD principles and will become available through a public repository. Some examples of queries that a SW application could perform to aid citizens to access these semantically structured data are presented. Then, final considerations are provided about the use of the SW technologies in the development of applications to allow access to such data.
Application ontologies describe concepts of a domain and specific tasks for implementing
systems, the practical part [
Thereafter, searches were performed in the DAML (http://www.daml.org/) and Schemapedia (http://schemapedia.com/) repositories, in order to locate validated ontologies that could be integrated to this work by reusing their terms. None of them completely met the work needs, possibly because it is a very specific theme. In this ontology version some terms and resources provided by FOAF (http://xmlns.com/foaf/spec), Geonames (http://www.geonames.org/) and DBpedia (http://dbpedia.org/) regarding to cities were used. Thus, the ontology contains internal terms, data, and references to resources from other repositories.
The ontology was constructed using the OWL 2 DL language, with 98 classes and 656 axioms identified by the prefix med. Figure 1 depicts the main classes of the ontology. Vertices are classes and edges are relationships between classes. Dashed arrows represent object properties while continuous arrows represent subclasses.
The class med:MedicalDoctor describes a medical doctor, defined as a subclass of foaf:Person and as an equivalent class to dbo:Medician class. The class med:CRM represents a CRM (registry at the Regional Council of Medicine), defined as a subclass of the class foaf:Document. med:MedicalSpecialty represents a medical specialty and has medical specialties as subclasses, such as med:Dermatology. med:SurgicalSpecialty describes a surgical specialty, defined as subclass of med:MedicalSpecialty, and has surgical specialties as subclasses, such as med:SpineSurgery. The subclasses of med:MedicalSpecialty and med:SurgicalSpecialty allow answers for the CQ1. The classes med:Clinic, med:Practice, dbo:Hospital, med:HealthCenter and med:FirstAidStation describe workplaces of a doctor, answering the CQ2. Finally, the class med:MedicalProcedure represents a medical procedure that a doctor can perform.
The datatype property foaf:name describes the name of something, dbo:address represents the address of a place, dbo:date corresponds to the date of some event, dbo:status is used to represent the status of a CRM (active, inactive, etc.), med:UF represents the Unity of Federation in which it was issued, and dbo:number describes the number. The object property med:HasCRM relates a medical doctor to a CRM and is characterized as inverse functional, which guarantees that an instance of the class CRM relates with a single instance of the class med:MedicalDoctor. Regarding the CQ3, the answer is “Yes, it is possible.”, but a CRM must be associated with only one doctor. The property med:WorkplaceOf relates a person (foaf:Person) to his/her workplace (dbo:Place) and has an inverse property, the med:WorksAt, where the domain and range are reversed. Likewise, med:PerformedBy also has an inverse property called med:Perfoms. This property represents a medical procedure (med:MedicalProcedure) performed by a medical doctor (med:MedicalDoctor). The property med:HasExpertise indicates that a doctor has an expertise (med:MedicalSpecialty) and med:HasSpecialty relates a health unit to a medical specialty.
Restrictions work as basis for the inferences made by the reasoner, defining which features an instance must have to belong to a certain class. For example, an individual is associated to med:MedicalDoctor class when he/she has at least one CRM and has expertise on at least one medical specialty. Regarding CQ4, the answer is “Yes, it’s possible”, so no restrictions were made to constrain the number of specialties associated to a doctor. Another example of restriction specified for the classes med:Clinic, med:Practice, dbo:Hospital, med:HealthCenter and med:FirstAidStation is that these health facilities shall have at least one medical specialty.
The instances were created according to information extracted manually from websites of Brazilian private health plans and data sources of the Brazilian government. The main data sources used were: Unimed Medical Guide (http://www.unimed.coop.br/) - where were extracted the medical doctors names, number of CRM and specializations; Consulta CRM (http://www.consultacrm.com.br/) - where can be collected the remaining CRM data through an API; DATASUS (http://cnes.datasus.gov.br/) - where were extracted URIs of pages that describe each health facility; Website of Rio das Ostras prefecture (http://www.riodasostras.rj.gov.br) - where were collected the medical specialties provided by the health facilities; Geonames and DBPedia - where were collected URIs of resources that represent the cities of Rio das Ostras and Macaé focus of this work. For privacy reasons fictitious data were used in this section examples. Listing 1 shows an instance of med:MedicalDoctor, specifically the doctor “Sara de Sa”. The object properties #HasCRM (med:HasCRM) and #HasExpertise (med:HasExpertise) were defined as required conditions for association with the med:MedicalDoctor. The property #WorksAt (med:WorksAt) relates this instance to instances of health facilities in which the medical doctor provides services.
Listing 1. Example of instance of med:MedicalDoctor.
Listing 2 shows an instance of med:HealthCenter representing the Família Rocha Health Center. Note that the property med:WorkplaceOf) is inferred by the reasoner from its inverse property med:WorksAt. Also worth highlighting relationships with resources located in the external repository Geonames via foaf:based_near.
Listing 2. Example of instance of med:HealthCenter.
The following examples show some queries that a SW application could perform from the repository to present useful information for its users. For instance, consider that a woman wants to search for a female gynecologist. Queries like these help to answer the CQ5. The query in SPARQL and its result are shown in Figure 2. This query searches the name, the address and the phone of the medical doctor’s workplace. It searches an individual of the type “medical doctor”, whose sex is female, i.e., whose sex is related to the string “FEMININO” by dbo:sex and whose medical specialization is related, by the property med:HasExpertise, to the instance med:REC_Ginecologia_e_Obstetricia. The workplace, represented by ?health_unit, is associated to name, address and phone by the properties foaf:name, dbo:address and foaf:phone, respectively. The FILTER clause attends an application specification of returning only health facilities of the type med:Clinic or med:HealthCenter.
Suppose now a search for hospitals that perform general surgery near Rio das Ostras city. Figure 3 shows this query that could answer the CQ6.
Such query returns an individual related to the individual
med:REC_Cirurgia_Geral by the property med:HasSpecialty. It shows a link between a
resources of the DBpedia and of the local repository by the property foaf:based_near.
According to the LD recommendations, links with other repositories allow applications
to obtain useful information following these links [
Many ontologies and vocabularies are available for the health area, such as OMRSE [Brochhausen, et al., s.d.] and those stored in the OBO-Foundry repository [Ashburner, et al., s.d.]. However, most of them describe information that is not provided in this work, like diseases and human body anatomy. The ontology SNOMED CT [IHTSDO, s.d] and the upper ontology UMBEL [Bergman, M. K. & Giasson, F., s.d.] specify terms relating to medical specialties and health facilities. Specifying the relationship between the terms of the proposed ontology and the terms of these ontologies is an ongoing work. Future works include: the development of an application to provide access to the semantically structured data about medical doctors and health facilities and the creation of a repository with data obtained from municipalities, in order to allow the interoperability of information between medical and government institutions and the data management to support the decision-making. “Linked