Most advanced Electronic Healthcare Records architectures represent clinical knowledge by means of archetypes. Consequently, guaranteeing the correctness and consistency of such archetypes becomes crucial for the success of those architectures. In this work, we present a method that uses OWL and reasoners for evaluating the consistency of the archetypes. This method has been validated through its application to the openEHR archetype repository, which is the largest available one nowadays. The results of this validation are also reported in this study.
Archetype-based EHR domain knowledge plays a
fundamental role for the achievement of semantic interoperability in
healthcare [
In this work, an OWL-based representation of archetypes that makes it possible to accomplish validation and quality assurance requirements is presented. The methods for checking the consistency of archetypes will be supported by reasoners, which will be in charge of helping to identify the wrong de nitions in the archetypes.
Archetypes are detailed and domain-speci c de nitions of clinical concepts in the form of structured and constrained combinations of the entities of the reference model. The ISO EN 13606 and openEHR communities specify them using the Archetype De nition Language (ADL). Next, an excerpt of the de nition of an openEHR archetype for working with check lists in healthcare is shown.
-- A health oriented check list EVALUATION[at0000] matches { data matches { -- Tree ITEM_TREE[at0001] matches { items cardinality matches {0..*; unordered} matches { -- Question group CLUSTER[at0002] occurrences matches {1..*} matches { items cardinality matches {0..*; unordered} matches { -- Question CLUSTER[at0003] occurrences matches {1..*} matches { items cardinality matches {1..2; ordered} matches {
ELEMENT[at0004] occurrences matches {1..*} matches {*} -- A comment on the answer ELEMENT[at0005] occurrences matches {0..1} matches { value matches {
DV_TEXT matches {*} }
} } ...
Concepts in archetypes are identi ed by an id (e.g., at0003) and characterized by their occurrences, that is, the number of instances that can be part of the association to which they belong. Multivalued attributes may be restricted in di erent ways: cardinality, order and uniqueness (unique) of the instances. Finally, an archetype can be de ned as the specialization of another one.
In order to check the correctness of the clinical archetypes based on OWL reasoning, we should be capable of representing archetypes in OWL. As it has been mentioned, archetypes are built by de ning restrictions over the entities of the EHR reference model, usually expressed in UML. Therefore, an OWL-based representation of the reference model is needed. Otherwise, the validation of the archetypes would not be possible. This is not a di cult step since this representation can be obtained by applying the following simple rules: (1) UML classes are transformed into OWL classes; (2) attributes are represented as OWL properties and a SubClassOf axiom is included in the class in which it has been de ned; (3) inheritance relations are transformed into SubClassOf axioms and sibling classes are de ned disjoint; and (4) multivalued attributes are represented by means of a class which makes use of properties for de ning the order, repetitions, cardinality and range of the values of the instances.
An archetype de nes a clinical concept by constraining an entity of the reference model. Such concept represents a specialization of that reference model's entity. Those restrictions are applied to the attributes de ned for each entity: range, cardinality, and so on. In this way, each restricted entity is de ned by means of an OWL class which contains the de nition of the corresponding constraints. Most constraints are applied to multivalued attributes. These constraints are de ned over the collection class that represents the range of the property. This is the case of the attribute items of CLUSTER[at0003] that is shown next.
EquivalentTo: ARCHETYPED_CLASS and id value "at0003" and CLUSTER and op_items only COLLECTION_CLUSTER_at0003_items
EquivalentTo: COLLECTION and id value "COLLECTION_CLUSTER_at0003_items" and elements min 1 ITEM and elements max 2 ITEM and elements min 1 ELEMENT_at0004 and elements max 1 ELEMENT_at0005 and ordered value true and unique value false In case of de ning an archetype that specializes another one, its de nition includes an additional annotation in each class. That annotation indicates the name of the class in the parent archetype that is being specialized, if any. This annotation will then be used in the consistency checking process.
An archetype is consistent if its set of constraints de ned over both the reference model and the parent archetype are valid. The following types of errors can be identi ed: incorrect restrictions and incorrect specializations. In this work, such inconsistencies are detected by using a strategy based on OWL reasoners. In the rst case, if a class is not consistent with respect to the reference model, the reasoner will nd that class unsatis able. Specialization errors requires the processing of the reasoner results. In this way, a specialization is wrong if the reasoner cannot infer a subsumption relation.
In order to provide detailed information about the causes of the inconsistency, support classes, that allow the isolation of each archetype constraint, are de ned. For instance, a class is generated for de ning the constraint of maximum cardinality for the attribute items of CLUSTER_at0003. The de nition of these classes for the specialized archetype would be similar, except for the addition of the corresponding annotation to de ne its parent archetype.
Class: MAX_CARDINALITY_COLLECTION_CLUSTER_at0003_items EquivalentTo: MAX_CARDINALITY and id value "COLLECTION_CLUSTER_at0003_items" and max_cardinality_value only xsd:int[ <= 2 ]
The OWL-based method for checking the consistency of archetypes has been implemented in the tool Archeck that is available at http://miuras.inf.um.es/archeck. The tool has been implemented in Java and makes use of the openEHR Java tools. Ontologies are processed with the OWL API and we have used Pellet and Fact++ for the reasoning. Our experimental validation has used the archetypes available in the openEHR repository. The validation of this repository has reported that 14 over 931 archetypes are inconsistent. In terms of reasoning time, the results obtained with Fact++ are better than with Pellet. The complete results of this experiment are available at the referred website.
This work proposes a representation of ADL clinical archetypes as OWL classes in order to check the correctness of their de nitions by using OWL reasoners. The approach has been implemented in the Archeck tool and has been validated using the openEHR archetype repository. The tool has proved to be useful since a number of archetypes have been found inconsistent in that repository and the validation errors have been reported. Archeck will also be deployed as a web service in order to integrate the validation process in other tools.