UK meeting on SMART platform and openEHR
Those who are UK-based might find this of interest + remote access may be available More details at http://handihealth.org/handi-smart-platform-and-openehr-meeting-11th-july HANDI ? SMART Platform and OpenEHR ? Meeting 11th July This meeting has been arranged at short notice to present these two open technologies and discuss how they might be used together to support the App ecosystem with a view to further work in the Autumn There will be the opportunity for remote participation ? Using NHS Social the new collaboration tool from www.tactix4.com. Details will be sent to those who register for remote participation. SMART Platform http://www.smartplatforms.org is a US Government funded open source initiative, spearheaded by Harvard Medical School, that provides a means by which EHR systems can be extended and accessed by third-party applications. SMART defines a set of technical and API standards that are independent of the underlying systems. ?SMART containers? have already been produced for a number of EHR and PHR, and an ecosystem of SMART apps that can access such EHRs is already beginning to develop in the US. OpenEHR www.openehr.org is a project of the not-for-profit OpenEHR foundation and is about creating specifications, open source software and tools for a health care interoperability platform. In the clinical space, it is about creating high-quality, re-usable clinical models of content and process ? known as archetypes ? along with formal interfaces to terminology. Systems based on OpenEHR which, draws heavily on the European standard CEN13606, have been implemented in a number of countries and OpenEHR?s standard for clinical models ADL has be adopted by CIMI http://www.openehr.org/326-OE.html?branch=1&language=1bringing together work in the HL7 and OpenEHR communities. Also look at openEHR Clinical Knowledge Manager at www.openehr.org/knowledge Those behind SMART and OpenEHR have had some previous discussions on possible opportunities for collaboration which HANDI is keen to accelerate. This meeting will include expert presentation of the two technologies and an opportunity to explore their further use in the UK and/or possible collaboration at a global level. = Sorry for cross-posting but I think this is of potential interest to both technical and clinical audiences. Ian -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org
SMART platform and RDF
Seref Arikan wrote: > 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? I assumed it would be from OPT (operational template). Peter
SMART platform and RDF
Dear all, 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. Best regards, Kathrin Dentler [1] http://www.few.vu.nl/~kdr250/prohealth12kr4hc_archetypes_owl.pdf Op 03-07-12 10:19, Ian McNicoll schreef: > 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? > > Ian > -- 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/
SMART platform and RDF
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. On Tue, Jul 3, 2012 at 9:58 AM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > On 03/07/2012 09:50, Seref Arikan wrote: > > Which I assume will be represented via XSD again, if multiple technologies > are to do the same thing in the same way. > * > * > > > 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 > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120703/39938e93/attachment-0001.html>
SMART platform and RDF
On 03/07/2012 09:50, Seref Arikan wrote: > Which I assume will be represented via XSD again, if multiple > technologies are to do the same thing in the same way. > * > * 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 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120703/29dd002b/attachment.html>
SMART platform and RDF
Which I assume will be represented via XSD again, if multiple technologies are to do the same thing in the same way. On Tue, Jul 3, 2012 at 9:48 AM, Peter Gummer < peter.gummer at oceaninformatics.com> wrote: > Seref Arikan wrote: > > > 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? > > > I assumed it would be from OPT (operational template). > > Peter > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120703/037af05f/attachment.html>
SMART platform and RDF
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) Regards Seref On Tue, Jul 3, 2012 at 9:19 AM, Ian McNicoll < Ian.McNicoll at oceaninformatics.com> wrote: > 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? > > Ian > > -- > Dr Ian McNicoll > office +44 (0)1536 414 994 > fax +44 (0)1536 516317 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian.mcnicoll at oceaninformatics.com > > Clinical Modelling Consultant, Ocean Informatics, UK > Director openEHR Foundation www.openehr.org/knowledge > Honorary Senior Research Associate, CHIME, UCL > SCIMP Working Group, NHS Scotland > BCS Primary Health Care www.phcsg.org > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120703/a06dfec9/attachment.html>
SMART platform and RDF
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? Ian -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org
