RE: Syntax for including archetypes in SLOTs, regardless of version

Hi everyone, In our modelling, it is safe to assume that the latest version of an archetype is the best candidate on offer for anyone using an archetype and filling a SLOT for the first time. Options for use of previous versions may be useful for implementers who have older versions in their cu

Re: openEHR on FHIR and vice versa

A library of mappings sounds like a great idea, another type of artifact for the CKM maybe? I believe the LinkEHR mapper has the ability of constructing such mappings in a processable format that can be shared. Diego? :) On Tue, Dec 18, 2018 at 7:04 PM Heath Frankel < heath.fran...@oceanhealthsys

Re: openEHR on FHIR and vice versa

Transformation programs generated with LinkEHR are pure XQuery, and you are the one who decides the license of that output program. So nothing stops you in that regard. XQuery can output json too btw Regards El mar., 18 dic. 2018 a las 23:04, Heath Frankel (< heath.fran...@oceanhealthsystems.com>

Re: openEHR on FHIR and vice versa

Although I will add, and I think someone has already suggested this, at least we only have to do this mapping once for each FHIR resource. So as a openEHR/FHIR community we should aim for a set of templates, as Thomas indicated, a set of FHIR extensions, and a library of mappings and transforms.

Re: openEHR on FHIR and vice versa

Thanks Pablo, I second that. Regards Heath _ From: Pablo Pazos mailto:pablo.pa...@cabolabs.com>> Sent: Wednesday, December 19, 2018 3:36 am Subject: Re: openEHR on FHIR and vice versa To: For openEHR technical discussions mailto:openehr-technical@lists.openehr.org>>

AW: AW: Syntax for including archetypes in SLOTs, regardless of version

Von: openEHR-technical Im Auftrag von Thomas Beale Gesendet: Dienstag, 18. Dezember 2018 18:39 An: openehr-technical@lists.openehr.org Betreff: Re: AW: Syntax for including archetypes in SLOTs, regardless of version The example below openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\

Re: openEHR on FHIR and vice versa

On Tue, Dec 18, 2018 at 2:50 PM Thomas Beale wrote: > > On 18/12/2018 17:04, Pablo Pazos wrote: > > Yes, in fact the closest we can get to automatic transformations is just > defining the mappings between openEHR classes and the correspondent FHIR > resources, and feed that to a system that, for

Re: openEHR on FHIR and vice versa

On 18/12/2018 17:04, Pablo Pazos wrote: Yes, in fact the closest we can get to automatic transformations is just defining the mappings between openEHR classes and the correspondent FHIR resources, and feed that to a system that, for a specific openEHR instance, provides a mapper user with cons

Re: AW: Syntax for including archetypes in SLOTs, regardless of version

On 18/12/2018 16:48, Sebastian Garde wrote: Hi Silje, hi Thomas, hi all, Whether the CKM validation errors from below are correct or bogus boils down to my question from before whether it is valid or not to just leave the version part out completely. In my understanding the regex needs to

Re: openEHR on FHIR and vice versa

Yes, in fact the closest we can get to automatic transformations is just defining the mappings between openEHR classes and the correspondent FHIR resources, and feed that to a system that, for a specific openEHR instance, provides a mapper user with constrained options of FHIR resources to choose f

AW: Syntax for including archetypes in SLOTs, regardless of version

Hi Silje, hi Thomas, hi all, Whether the CKM validation errors from below are correct or bogus boils down to my question from before whether it is valid or not to just leave the version part out completely. In my understanding the regex needs to be fully matched which means you cannot just leav

RE: Syntax for including archetypes in SLOTs, regardless of version

Thanks Thomas, The idea here is that we (likely in 99% of the cases) do want to include any version of the archetype, so the .v[0-2] variant isn’t relevant. The reason for this is that even though an archetype will have breaking changes from one major version to the next, the clinical concept w

Re: Syntax for including archetypes in SLOTs, regardless of version

For reference, these are the various regexes I use in the ADL workbench . ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http

Re: Syntax for including archetypes in SLOTs, regardless of version

On Tue, Dec 18, 2018 at 01:17:38PM +0100, Karsten Hilbert wrote: > > In other words, add a pattern to catch “any single (possibly double) digit > > version number” (?). > > \d{1,2} Ah, sorry, was misled by *number*. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___

Re: Syntax for including archetypes in SLOTs, regardless of version

Silje, just as a technical note, the proper regex for including openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. is openEHR-EHR-OBSERVATION\.body_mas

Re: Syntax for including archetypes in SLOTs, regardless of version

On Tue, Dec 18, 2018 at 12:09:56PM +, Bakke, Silje Ljosland wrote: > In other words, add a pattern to catch “any single (possibly double) digit > version number” (?). \d{1,2} Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B ___

RE: Syntax for including archetypes in SLOTs, regardless of version

v[0-9][0-9] would also include v00-v09, which we don’t want. Regards, Silje From: openEHR-technical On Behalf Of Anastasiou A. Sent: Tuesday, December 18, 2018 1:04 PM To: For openEHR technical discussions Subject: RE: Syntax for including archetypes in SLOTs, regardless of version Hi Silje

RE: Syntax for including archetypes in SLOTs, regardless of version

Hi Silje I may not have got this right, but why not “v[0-9][0-9]?” (or, not care about what follows “body_mass_index”) ? In other words, add a pattern to catch “any single (possibly double) digit version number” (?). This looks like a straightforward case of “constrain to openEHR-EHR-OBSERVAT

Syntax for including archetypes in SLOTs, regardless of version

Hi, Sebastian Garde and I had a brainstorm a while ago about how to handle inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be noted explicitly (whether because of tooling or the specificat

Re: Better definition of 'system_id' attribute in openEHR sytems

Hi Thomas, This is an excellent description and is inline with our implementation. Regards Heath From: 3003270n behalf of Sent: Monday, November 26, 2018 11:43 pm To: Openehr-Technical Subject: Better definition of 'system_id' attribute in openEHR sytems Fol

Re: openEHR on FHIR and vice versa

I agree Pablo and we have to remember that the number of high-quality, truly interoperable FHIR profiles is going to be very small for a long time. @Dileep V S - we have started to put FHIR bindings in CKM archetypes but in practice, the FHIR-openEHR mappings will between local FHIR profiles and