| | How can others contact you? | Areas you / your company are working on | Code is open or planned to be open? | | Current issues / challenges / questions | Available tools / solutions |
Pablo Pazos | CaboLabs (Uruguay) | pablo.pazos@cabolabs.com / @ppazos | Data Repositories, Web Services / APIs / Data Communication, OPT processing tools | Yes | We have a production-ready foss CDR called EHRServer and it's SaaS CloudEHRServer, now on version 0.9.5. The roadmap is on my github under milestones.
Have clients of the EHRServer REST API written in PHP, Groovy and JavaScript. Need some maintenance. And planned to create a .Net client.
Also have command line tools to generate UI and XML data instances from an OPT. It is the openEHR-OPT project in my github.
Currently I'm building an app the store psychotherapy notes for my wife, and this will use the EHRServer as backend.
I'm planning on developing a demographic server that complements the EHRServer, because it doesn't store any personal identification data. It will be a small MPI that implements the openEHR demographic model.
Another tool I want to build and have a working prototype is a multi-platform GUI generator tool. Basically to generate declarative GUI definitions that can be processed and rendered on web browsers, Java desktop apps, android, ios, .net desktop and web, etc. I have the design of what I call "UITemplate" that uses OPTs adding GUI metadata, a generator takes instances of that model and a technology specific set of mapping rules, and generates the same UI on different target technologies. Then projects can grab the UIs generated and integrate them into real projects. A second step would be to provide a tool that does that integration automatically, and even binds the UI with the logic that process and validates the data entered on the UI. This is something I been postponing since I don't have much resources to support this development. | For the EHRServer many requested to add support for AQL. I'm not good with grammar processors and parsers so it is difficult to me to implement that without having an AQL parser already built in Java. I hope someone has released that component. Asked on the lists some time ago and didn't have much feedback.
Create client libraries for the EHRServer API in other technologies I'm not used to work on. Like .Net, Ruby, Python, etc. Hopefully someone in the community works on those areas and wants to use the EHRServer to build apps, maybe can help me on creating those client libraries. | EHRServer is ready. It is based on openEHR 1.0.2, uses only OPTs (no ADL).
On my github account I have:
+ cabolabs-ehrserver-groovy: EHRServer client lib in Groovy
+ openEHR-OPT: command line tool that generates GUI and XML data instances from OPTs, also includes OPT parsing and caching in memory for quick reference (this is currently used by the EHRServer)
+ EHRClientPHP: EHRServer client lib in PHP
+ cabolabs-emrapp: sample EMR app with complete clinician flow that stores data in the EHRServer
+ EHRCommitter: sample data record and commit to the EHRServer, UIs are dynamically generated and loaded with sample data, good to test the EHRServer with new data structures
+ cabolabs-ehrserver-js: EHRServer client lib in JavaScript
+ openEHR-skeleton: full stack application that shows how to implement openEHR in different software layers (ui, logic, persistence, etc.), created for my openEHR Hack Week Workshop.
+ openEHR-ADL: lib that allows loading ADL from disk, parsing and memory cache for quick reference, used by the early stages of the EHRServer
+ cabolabs-emr-framework: generic GUI only frameworks that shows full clinical flows on a usability focused design, can be used as reference by any EMR.
+ open-ehr-gen-framework: full stack app that generates UI from ADL (forms), validates data entered automatically using constraints in ADL, stores in a generic DB. Add more ADLs, you will get a different app without writing any source code.
archetype-flattener: test tool for resolving SLOTs on archetypes and and up with on ADL
+ openehr-uitemplates: prototype of the multi-platform GUI generator
|
Koray Atalag | University of Auckland and The Clinician Ltd. (New Zealand) | koray.atalag@gmail.com; Twitter/Skype/GitHub: atalagk | Data Repositories, Web Services / APIs / Data Communication, Integration / Migration / ETL, Ontology based data discovery and linkages | Yes | 1) GastrOS - open source endoscopy reporting application (http://gastros.codeplex.com)
2) We're building a framework (open source software & libraries) to link semantically annotated (using ontologies) computational physiology models with relevant clinical data (openEHR based and with comprehensive terminology bindings)
3) In our company we have a platform for Patient Reported Outcome Measures (PROMs). We're working on a light openEHR based EMR backend to which we are planning to bind data elements of clinical significance. We are also developing an eDischarge solution which will also have an openEHR based back end. We're looking at open source CDR options. | Order of significance/desparation!
1) Concrete methodology for terminology bindings (including being able to manage both post-coordinated and EQL SNOMED CT)
2) Modelling and Education programmes should step up - urgently need high quality free primers / training materials & certification
3) Newer and more functional modelling tools | GastrOS - open source endoscopy reporting application (http://gastros.codeplex.com) |
Pieter Bos | Nedap Healthcare, The Netherlands | Pieter.bos@nedap.com | Data Repositories, Web Services / APIs / Data Communication, Library to work with ADL/AOM/RM | Yes | Library released and actively being developed, other products in development, nearing pilot projects at customers. The library is open, rest is closed source. | We work with ADL 2 only. This means modeling tools are not mature enough for all features and we do quite a lot of the modeling by hand with a text editor. We are interested in better modeling tools.
We use the rules section of archetypes and it looks like not many others do. The spec is not complete in this aspect, but is very usable and we think it's a great addition to OpenEHR. Also the flattener specification does not specify how to flatten archetypes with rules. This means there will be different implementations from different vendors.
Since our library is open source, third party contributors are very welcome.
We have done much work to ensure compliance of our tools with the standard and we know the ADL grammar is compliant. But we do not know for sure if everything we do is actually compliant with the standard. | We work with the latest openEHR specs only. We released an openEHR library called Archie at https://gitHub.com/nedap/Archie. Archie is a library for building openEHR tools and systems. It has many of the functionalities of the java reference implementation, but for ADL 2 and with some different implementation choices. It currently consists of:
- an ADL and ODIN parser and serializer
- an AOM implementation
- a RM implementation
- a flattener and operational template generator (not the same as an opt version 1.4!)
- a rule evaluator for the rules section of archetypes that allows for score calculation, extra validations and automatically setting existence of fields based on input
- xml and json serializers and parsers for both the AOM and RM
- full APath and XPath query support in both RM and AOM. XSLT transformations are possible.
- tools to create and edit RM objects and obtain information about the RM models
And probably still a bit more that I forgot to list now. It's available under the Apache 2 license so it should be possible to integrate in any other project. Contributions are welcome - Marand already has contributed an ADL/ODIN serializer. It's built with ease of use and performance in mind.
We develop this as part of an EHR that integrates with our existing traditional EHR and other software for the Dutch care market. This consists of an EHR repository, a front end and a part that integrates with our existing systems. The EHR repository can run standalone. The first part of our EHR is nearing completion and pilot projects at several customers are being started. |
Seung-Jong Yu | InfoClinic / South Korea | info@infoclinic.co seungjong.yu@gmail.com | Terminology Server & Service | No | InfoClinic is a SNOMED CT Affiliate and only specialized SNOMED CT vendor in Asia.
The name of product is InfoClinic's STOM Solution and you can use it for free.
Products are
1) To support SNOMED CT & LOINC Browser (http://term.infoclinic.co)
2) To support various Terminology Services(RESTful) including composition grammar and expression constraint language(ECL) of SNOMED CT (http:/api.infoclinic.co)
3) To support OAuth2 (you can find Request in info clinic homepage, http://infoclinic.co)
Products will
1) support additional tools (Editors for Concept, Description, Reference set & Mapping)
2) support services for EHR (openEHR, HL7 FHIR, etc)
3) support additional terminologies
4) support Terminology Management (Team management, Concept creation & review, Terminology version & release)
5) support Cloud services | Browser & APIs work well now but is not steady maintained & updated because InfoClinic is one-person company. | |
Ian McNicoll | Operon UK | ian@operon.systems | Modeling tools (ADL, OPT, terminologies, GDL, other), Web Services / APIs / Data Communication, Integration / Migration / ETL, Asset package management (like NPM/Maven for archetypes/ templates etc) | Yes | Beind developed | 1. need FHIR integration 2. need new ADL1.4+ tools urgently 3. Local asset package/repo management tooling 4. need Published openEHR Rest APIs and JSON formats | Fist draft of HAPI-FHIR UK profiles available in a few weeks |
Jan-Marc Verlinden | MEDrecord, the Netherlands | jan-marc@medrecord.io | Modeling tools (ADL, OPT, terminologies, GDL, other), Data Repositories, Web Services / APIs / Data Communication, Integration / Migration / ETL | Yes | We provide the entire openEHR based stack for storing and retrieving archtypes data. | One of our main challenges is that a lot in the openEHR specs are still left open. Also there is no proper reference implementation that could be useful. Maybe it would be an idea that one complete open source stack could be funded by the openEHR foundation. | API platform, Formbuilder, Careplan builder |
Arthur Bezerra Nunes | IFCE | arthurbezerra92@gmail.com | Web Services / APIs / Data Communication, Integration / Migration / ETL | Yes | | | |
Birger Haarbrandt | Hannover Medical School | birger.haarbrandt@plri.de | Integration / Migration / ETL | Yes | At Hannover Medical School, we are building smaller tools to improve the handling of openEHR data and to conduct some reseach.
(1) Based on the webtemplates of Think!EHR, my colleague developed a tool that allows to dynamically map data from an ordered relational database table to a composition. For example, it uses rules to create a new sub-tree (e.g. history object) when defined values change. As the main parts of the tool depend on Microsoft SSIS, the re-use of this version is questionable. It complements our data integration approach for complex documents which uses TDS and Altova Mapforce.
(2) I prototyped the automated transformation of openEHR data to i2b2/tranSMART (PMID: 27507090). As it was mainly intended to investigate the capabilities of openEHR to allow such transformations, the tool is still a prototype which uses flattened archetypes instead of OPTs and depends on our local openEHR implementation used in the HaMSTR project. However, I aim to revise the tool and offer a version that will be based on OPT and the API of Think!EHR. | It would be good if the openEHR REST API (http://www.openehr.org/releases/ITS/latest/ehr_restapi.html) would quickly become stable. This would facilitate the potential re-use of our tools throughout the community. | We are currently working with version 1.0.1. I will provide an update when we have been able to release something that is actually useful for the community. |
Tony Shannon | Ripple Foundation | tony.shannon@ripple.foundation | Data Repositories, Web Services / APIs / Data Communication, UI Framework | Yes | 3 key components of open source stack already built | "We have supported the crafting of 3 key open source solutions that we believe are needed in healthcare.
1) UX/UI Framework (aka PulseTile) - aimed as generic healthcare application support
2) Middleware Integration Framework (aka QEWD)- aimed at supporting the typical integration challenges in healthcare
3) Enterprise Clinical Data Repository-(aka EtherCIS) aimed at supporting both structured & unstructured data at scale , inc openEHR compliance
We have built them as separate components but aimed to be useful together, as part of our ""showcase stack"".
See here for more details. http://ripple.foundation/
We will be making a more public announcement shortly but these tools are now about ready for wider review..each are still in their early stages but are pretty capable already." | "1) UX/UI Framework (aka PulseTile) - aimed as generic healthcare application support- developed in AngularJS (ReactJS version in development)
https://github.com/PulseTile/PulseTile
2) QEWDjs - Middleware Integration Framework - built on NodeJS
https://github.com/robtweed/qewd
https://github.com/RippleOSI/Ripple-Qewd
3) EtherCIS
https://github.com/ethercis/ethercis All have been publicly released under an Apache 2 license.
As a combined stack the aim is to offer a complete stack from UI frontend to middleware to data repository that is open source and openEHR compliant.
The easiest way to explore is to spin up the stack with the installer here;
https://github.com/RippleOSI/Ripple-Qewd
More details to follow in due course." |
Debbie Tarenskeen | HAN University of Applied Sciences | debbie.tarenskeen@han.nl | Modeling tools (ADL, OPT, terminologies, GDL, other), Data Repositories, Web Services / APIs / Data Communication, Information Technology Bachelor study | Yes | | | |
CDS? | Cambio/Sweden | models@cambiocds.com | Modeling tools (ADL, OPT, terminologies, GDL, other), Web Services / APIs / Data Communication, Integration / Migration / ETL | Yes | GDL editor (developed), GDL2 editor (under development), Knowledge Manager (developed), Dashboard studies (developed) | Developing CDS modeling tools and support for both openEHR archetypes and FHIR resources (using CDS hooks) | GDL editor (sourceforge.net) based on GDL 1.0 |
| | | | | | | |
| | | | | | | |
| | | | | | | |