Hi all, I want to share something I’m working on, but don’t know if would be useful for others.
I’m exploring how to define openEHR REST API workflows without dealing with REST clients, SDKs or any code. A workflow would be a chain of actions that are defined visually (without code) and then executed against an openEHR REST API implementation, like a CDR.
Personally I’ve spent a huge amount of time just defining different workflows to test openEHR CDRs, and I think there should be a better way of doing this. Life is short…
This is the second demo of the PoC we are developing to see check with the community if there are any ideas or preferences that people can contribute to make this tool better. Thanks!
I’m thinking in the use case for training. Would it be possible to see the actual REST calls that are generated? That would be very useful to help students understand the API by building their own examples.
It’s a great idea Pablo and something that we built internally using Postman and have plans to share publically. We also had thoughts about putting this behind CLI so that you could populate a CDR with test data (of different varieties) via the command-line / scripting etc…
The biggest work is setting up and maintaining the templates and instance examples.
Thanks @damoca I agree this app will be very useful for training, for instance for a non-technical audience, they still can create their “scripts” visually and interact with an openEHR CDR.
About the requests, it’s easy to see the requests using Wireshark, which I’m using for testing right now.
Currently I’m using Atomik as the reference CDR, then when this PoC is complete I’ll test against other CDRs, so anyone can use the app with any openEHR CDR.
Hi @ian.mcnicoll I have collections of requests too, and for me it’s a pain to test use cases that way. It’s just too time consuming. I have two sets of collections, one for testing EHRServer and Atomik, and one for the work I’m doing for the openEHR Conformance Verification.
For me, these take a lot of time:
designing templates
designing test data sets
implementing the HTTP requests for implementing one workflow or test case
Step 1 is unavoidable.
For Step 2. I created an instance generator which has been part of the openEHR Toolkit (I used that in HiGHmed for testing EHRBase, for testing EHRServer and Atomik, and many colleagues here used it too) and now it’s been updated as part of the new Toolkit, for instance it can generate demographic instances automatically.
For step 3. I was thinking a lot on how it can be automated and a higher level. Though of a CLI too to some kind of high level language, and other options, but all options need technical users or even some kind of programming. The option that I thought could help the most people is the one that requires no knowledge about the API at all, so I started testing ideas for this visual tool, which uses kind of a CLI inside, but the user doesn’t deal with that directly. I think the key is to define the verbs correctly and make it easy for the user to use those verbs step by step with the minimal input to build their worksflows. Inside we use the automatic data generator from the Toolkit to generate LOCATABLE instances, so we remove the need of creating custom COMPOSITIONs, EHR_STATUS, FOLDER, PERSON, GROUP, etc. but it’s possible that for testing one specific use case you provide your own instead of making the app generate one for you.
The initial PoC will be focused on pushing data to the server. Then we will release a beta for some selected friends (two happen to just comment above ). If the community finds that useful, we will proceed with pulling and querying data, so the interaction will be full cycle.
The nice thing about the design behind this app is that it’s totally independent from the API being used, so the next step will be to configure the visual language to run against FHIR (if this works, it will be something )
We added a lot of error checks, and are working on reporting the output after running an action chain, some visual feedback while a chain is running and some improvements to the UI. In terms of functionality it’s completed for a beta release, so anyone who wants to test it, please let me know!
By the way, I tried to run it against the EHRSCAPE API online but it seems the test site is broken. Does anybody knows if EHRSCAPE changed the test site or if it’s not longer available? (I’ll test against EHRBase too, and any other CDR that allows me to do so, so we can be sure this tool works on any openEHR REST API implementation, which would be great! @rong.chen. Also against EHRServer once we migrate the REST API to the official one).
to some kind of high level language, and other options, but all options need technical users or even some kind of programming. The option that I thought could help the most people is the one that requires no knowledge about the API at all, so I started testing ideas for this visual tool, which uses kind of a CLI inside, but the user doesn’t deal with that directly. I think the key is to define the verbs correctly and make it easy for the user to use those verbs step by step with the minimal input to build their worksflows. Inside we use the automatic data generator from the Toolkit to generate LOCATABLE instances, so we remove the need of creating custom COMPOSITIONs, EHR_STATUS, FOLDER, PERSON, GROUP, etc. but it’s possible that for testing one specific use case you provide your own instead of making the app generate one for you.
). If the community finds that useful, we will proceed with pulling and querying data, so the interaction will be full cycle.
(if this works, it will be something 
)
openEHR Automation tool. What do you think?