Hey,
we (me and @yampeku) are close to release v1.0.0 of OMOCL + the mappings.
We both already reviewed the mappings and are currently preparing and updating the next release of Eos.
We would like to invite anyone interest to provide us reviews under:
Via github issues.
R
S
Please comment and critique every part from the mappings: paths, selected bindings, target OMOP tables… but also any additional element in the archetype that merits to be in a OMOP table that is feasible to be converted. If you let us know of an archetype+path that could be interesting to have we can discuss how it fits into OMOP. Feel free to use github issues for that
I’m interested in this. I’m talking to a party that’s interested in funding my time for this. It may take some time and risk.
Since omocl mappings require clinical interpretation, before adopting it to (international) CKM, it should be reviewed according to the CKM process for reviewing mappings. This process hasn’t been determined yet. So this will require some time too. It would help if CKM has a label for the review status of mappings (similar to labels for languages and the recently added term bindings).
Since there’s a lot of value in your mappings as is, I would suggest publishing them outside of CKM asap, with some description on the (impressive;)) accredition of the authors and reviewers.
Definitely. I don’t want to hijack the thread here, but in short: The yaml-based OMOP and FHIR mappings both now have the same metadata/version field which typically contains a Semantic Version.
With the forthcoming CKM release, we will extract this and display this together with an indication of the status that can be derived from this (for example: 0.0.1 → DRAFT, 1.0.0-alpha.1 → DRAFT, 1.0.0 → PUBLISHED, 1.0.1-alpha → REASSESS DRAFT). So if a draft mapping is uploaded to CKM, this is clearly displayed as such.
@yampeku maybe we adapt another version then, that fits into draft.
0.9 somewhat maybe.
Currently, me and diego did the reviews.
We have a bit of experience doing OMOP projects 
Personally I have been involved in 13 OMOP transformation projects, ranging from hospitals to biobank or multihospital enviorments. 9 of the projects also included capacitation and training to both IT staff and researchers in the organization. I’m part of VeraTech which is a certified EHDEN SME.
I also have other certifications related to the process, such as the SNOMED CT Foundation Course. I’ve also validated snomed bindings in CKM archetypes and commented the detected issues.
I have not been following on that, but for example generated mappings also comment on the detected issues (direct mapping from invalid binding vs correct binding)
I am also interested in this topic and reviewing it.
Sure the mappings can be found here:
in medical, for each of the openEHR archetypes there is file contained.
Each of this files contains the CDM table it is mapped to + the CDM fields and what openEHR path is used to populate them.
grammar: OMOCL/v1.0.0
type: model
metadata:
name: Procedure_v1
version: 1.0.0
spec: # OHDSI OMOP v5.4
system: OMOP
version: 5.4
openEhrConfig:
archetype: openEHR-EHR-ACTION.procedure.v1
mappings:
- type: "ProcedureOccurrence" # CDM TABLE
concept_id: # field name
alternatives:
- path: "description[at0001]/items[at0002]" # openEHR path
procedure_start_date:
alternatives:
- path: "description[at0001]/items[at0066]"
- path: "."
procedure_end_date:
optional: true
alternatives:
- path: "description[at0001]/items[at0060]"
if you have any questions or need an introduction let us know.
Take into account that codes are OMOP codes, Snomed (and Loinc) codes are as comments, but they might not be there. Will try to add comments with the snomed or loinc source of the code
Hi Severin, can we indeed have a meeting to have a discussion regarding this? I sent you an email already about it.