Hi Bert, The idea is to validate the data by using an integrity constraint validator such as http://clarkparsia.com/pellet/icv/. I just implemented a little proof of concept so far (successfully, a blood pressure value that was out of range). Others have done something similar: http://www.biomedcentral.com/content/pdf/2041-1480-2-2.pdf
Best, Kathrin Op 8/8/13 3:33 PM, Bert Verhees schreef: > That is very interesting, Kathrin, > > Do you also have a way to validate the data? > > Thanks > Bert > > > > On 08/08/2013 12:46 PM, Kathrin Dentler wrote: >> Dear David, >> >> Just because the proposed options both don't seem ideal at first >> sight, I would like to mention that I made good experiences working >> with an OWL representation of archetypes [1]. It took around two >> weeks until I could query my self-generated archetyped patient data. >> OWL can be queried with SPARQL based on graph patterns. >> >> The example archetypes, patient data and queries are online: >> http://www.few.vu.nl/~kdr250/archetypes/index.html >> >> However, there are some issues: >> >> 1) I stored the data as instances of archetypes, not as instances of >> the reference model. This seems most intuitive to me, but there might >> be some implications that I'm unaware of. >> >> 2) The ADL2OWL translator (originally developed by Leonardo Lezcano) >> is not feature-complete yet. For example, terminology bindings are >> not implemented yet. But Leonardo and me would be happy to share what >> we have so far, based on an appropriate open source license. It's >> written in Java. >> >> Best, >> Kathrin >> >> >> [1] >> http://www.few.vu.nl/~kdr250/publications/KR4HC2012-Semantic-Integration-Archetypes.pdf >> >> >> >>> What you need to store are instances of the reference model. That is >>> generic, it does not have fields like you mention. Those fields are >>> defined in archetypes. >>> That is why I advised you yesterday, take a good look at the >>> reference model. There is a good Java-version of it, written by Rong >>> Chen. >>> Then take a good look at the archetypes at the CKM: >>> http://www.openehr.org/ckm/ >>> You need to understand the match between them, the documentation >>> must help you. You must understand the documentation also. >>> >>> However, the documentation is more about the medical meaning of the >>> generic reference model. >>> But for you, when developing most important is to understand the >>> technical match, that is why the Java-code <--> archetypes match is >>> good for you to understand.. >>> >>> Don't do anything else before you understand this part completely. >>> You don't need to memorize it all, just understand. Memorizing comes >>> automatically when working with it. >>> Take your time, give yourself a week or more to do so. That is quite >>> normal amount of time. >>> >>> When you have good understanding of the match between the >>> Java-reference-model code, the documentation and the archetypes on CKM. >>> >>> Then come back to this list, and we can discuss how to proceed. >>> >>> Seref advises against building a kernel on your own, except when you >>> do it for academic exercise. >>> I disagree with him. I think it is quite doable, but it is not a >>> small thing to do. >>> But with good help and not being afraid to ask, it can be done, and >>> quite good. But it will take a year or more. >>> Do you have so much time? You will really need it. >>> >>> Pablo advises you to use a relational database. >>> I don't think that is suitable for a good working kernel, because >>> you cannot run path-based queries against it, but for a start it >>> might work. >> > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- Kathrin Dentler AI Department | Department of Medical Informatics Faculty of Sciences | Academic Medical Center Vrije Universiteit | Universiteit van Amsterdam k.dentler at vu.nl | k.dentler at amc.uva.nl http://www.few.vu.nl/~kdr250/
