There is quite a bit of interest in the UK in adapting the US-based
SMART platform www.smartplatforms.org for UK use. One aspect of SMART
involves the definition of a fairly simple API which serves RDF graphs
of archetype like objects e.g Blood pressure, allergy. The SMART guys
are aware of openEHR and have been quite support of it in the CIMI
work, and I understand that they do not see the clinical content
definitions underpinning the APIs as core business.
It seems to me that there is an interesting possibility of using
openEHR archetypes (probably templated) to define the clinical content
which is to be expressed as RDF graphs. This will give a much more
adaptable and extensible approach + better model governance etc.
It seems to me that the key requirement is to be able to create a
run-time artefact, in the same way that we create Template data schema
but to output RDF rather than XSD. Is this correct and if so, does
anyone have any experience with this?
The other interesting aspect is that because the SMART API returns
mostly ENTRY-level components, these need to be wrapped in some
COMPOSITION level metadata. Does it make sense that we actually return
very lean EHR Extracts?
Hi Ian,
I certainly need to take a look at the SMART work before commenting further, but I’d personally focus on going from XSD to RDF.
I know that it sends a chill down the spine to hear XSD as an anchoring modeling formalism, especially if you are an object oriented person, but it is the most accessible, most tool and framework rich formalism we have at hand.
If you go to RDF without XSD as the intermediate output, I’ll ask: from what computable form you are going to go to RDF? Code? That’d be a nightmare to share among systems.
I can’t easily get my head around the XSD ↔ RDF pipeline at the moment, but I’d go into this kind of work with all the tools I have at hand, and I have a hell a lot more tools in XSD space. (actually I’m going to be using EMF, but that is a different conversation)
actually, OPTs are not XSDs, they are an XML instance object serialisation of the AOM XSD. I.e. all OPTs obey the one XSD. I must admit it seems more obvious to me to go from OPT either in its XML or any other faithful serialised form (ADL, dADL, JSON, YAML) to RDF than anything else… - thomas
That is exactly what I’m talking about. If you go with ADL, dADL, JSON, YAML, which you are free to do of course, you’ll have difficulty in sharing/replicating that implementation.
Sorry, I’m writing these in the middle of a horribly busy day, so I did not go into details, but we’re talking about tooling here, to be used with and possibly without human intervention (runtime), and all I’m saying is, if I were to do such tooling, I’d do it with XML.
Here in Amsterdam we are working on expressing archetypes as OWL graphs, and actually I think that it would be ideal to host them under the openEHR domain in future.
We transform archetypes from ADL to OWL, with the work of Catalina Costa from Medical University of Graz (previously in Universidad de Murcia) and Leonardo Lezcano from the Universidad de Alcalá as a starting point. Please consult our paper [1] that has been accepted for the KR4HC workshop for details. It is not yet camera ready, but it gives an overview of some advantages of representing archetypes in OWL.
Currently Alberto Maldonado from IBIME, Technical University of Valencia, is doing a research visit in our group. He is working on generating OWL data (individuals) that are compliant with the OWL representation of archetypes from both legacy XML data and archetype compliant XML EHR extracts. The idea is to have normalized clinical data expressed in OWL in order to ease its reuse in clinical research (mainly clinical trials) and quality measurement.
This is very exciting news and I look forward to catching up on this area. It has been attempted on a few occasions, I believe as the OWL tooling improves we are likely to see benefits.
Interesting work, and nice to see many OWL/archetype-experts working together!
Are you planning to design any transformations of AQL-queries to SPARQL that matches your instance data format? (If so, we have a REST-based framework with a dedicated spot to put that translator in.)
It would be very nice to see openEHR collaborating in these semantic metadata models.
Now I’m taking a course on semantic data integration, and it seems with a little effort on the openEHR side we can generate other models that we can query or reason over them.
Recently I started to do some tests on rule definition and execution for CDS, maybe RDF + OWL + bla bla can complement openEHR in that area, since openEHR right now doesn’t have a clear way of defining rules over a set of archetypes & data sets (compositions, entries or extracts).
Maybe when I get more immersed into RDF, RDF-S, SPARQL, etc. I can help in some way.