Heather and Pablo, First for Heather: Thanks for being open on your concerns. I think that the reply from Pablo is also important. He pledges (like you but more explitly) for common ground on API's, of course also for application specific API's.
But that common ground needs to be defined first as a starting point. Inspiration could be found in the link I send as a reply to Thomas, yesterday. And for that common ground writing AQL would not be that hard, and it would be necessary. But I also tast in the reply of Pablo something like wanting to wait until there is an agreement. I don't think that will work. Waiting for agreements can take forever. It is a plan without time frame. Better is to look for agreements (agreed API) with suitable partners, and when they are found, some pressure will grow on the market, and that can make commercial motivated funders see the importance of that agreement of which CKM is from the OpenEhr side indispensable. There is, however, one important step. The agreement can only be platform independent, not only at the front side, but also on the backend side. Here we do it with OpenEhr, others will do it with FHIR messaging, and others will create layers between vendor API's and the agreed API. The profit will be in the marketpressure caused by that common API, and the platform-differences will be in what is outside the agreement. Bert. Op ma 16 jul. 2018 02:39 schreef Heather Leslie < heather.les...@atomicainformatics.com>: > Hi Bert, > > > > I totally agree with your view that CKM would carry AQL queries that could > be reviewed and potentially published in the same way that the archetypes > and templates are. I think it would have enormous impact on healthIT and > unleashing the power of openEHR and atomic data. > > > > It was a high priority in my strategic plan for CKM but I wasn’t able to > get inhouse resources when CKM was my responsibility. Now it is in the > hands of whoever is the new product manager for CKM and the new funders of > Ocean to assign the resources, although judging by their previous business > priorities I am concerned that CKM may not be a high priority item. > > > > I’d be ecstatic to be proved wrong. > > > > Regards > > > > Heather > > > > > > > > *From:* openEHR-implementers < > openehr-implementers-boun...@lists.openehr.org> *On Behalf Of *Bert > Verhees > *Sent:* Sunday, 15 July 2018 9:00 AM > *To:* For openEHR implementation discussions < > openehr-implementers@lists.openehr.org> > *Subject:* API's > > > > Today I looked at the OpenEhr API: > > https://www.openehr.org/releases/ITS/latest/ehr_restapi.html#top > > > > I live sometime in the OpenEhr world, so I am not surprised that it is a > rather low level API. In fact it is a bit hard to recognize quick what it > is about. And it fits perfectly to the philosophy of OpenEhr. The API is > not semantically rich. It are the archetypes which are semantically rich, > the API IS GENERIC. So it is fine. I am not criticizing. > > > > I found another API on the Internet, in fact, I found many. They are all > semantically rich. They all have functions like "Which medication does the > patient take". > > > > In OpenEhr there is only a function to execute a query to find > semantically meaningful data. The API itself offers no further clues. > > > > Again, this is not criticizing, it fits in the philosophy of OpenEhr. It > is impossible to write queries for the customers, because we do not know > the archetypes they use. The customer is helpless without the expertise of > OpenEhr specialists, of which are not many people on the world. I think, > from marketing point of view this is hard to sell, because other vendors > offer semantically rich API's out of the box. Only a web developer, without > special education is then needed to write a GUI. > > > > I think it is not necessary that it is that way. The premise that we don't > know which archetypes customers use is not always true. In fact, from many > customers it is known that they use archetypes from CKM. So, my point: > > > > How nice would it be when CKM would publicly be extended with queries > which fit on the archetypes, which can be used to create a semantically > rich API. > > > > This would have to advantages. > > 1) It would be a strong marketing point. An OpenEhr customer would not > anymore need expensive expertise to do simple things like querying which > medication a patient uses. > > 2) It would motivate customers to use CKM archetypes (Which maybe do not > use them now, or edit them without telling anyone, and maybe even without > changing the identifier) because this would then have an extra advantage to > stay closely connected to CKM. > > > > Someone having any thoughts about this? > > > > Bert > _______________________________________________ > openEHR-implementers mailing list > openEHR-implementers@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org >
_______________________________________________ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
