Sounds like a good proposal Pablo. For ADL 2 a single archetype api can be used for both archetypes and templates. However, it makes sense to allow the get api of archetypes to specify the form you want the result in: differential, flattened, or operational template (opt2).
Our EHR still will integrate the archetype part and query part, as well as the option to choose a used archetype for a slot at runtime. Could all be built with separate services and apis, but once you have everything integrated it makes for a very easy to use API for both EHR and datawarehouse usage. without needing sophisticated client libraries. However, you need much more complex server side tools in the EHR of course. Regards, Pieter Op 16 feb. 2018 om 15:48 heeft Pablo Pazos <pablo.,@cabolabs.com> het volgende geschreven:Ivo Hi Pieter,s Besides the API, I think for ADL2 archetypes and templates/OPTs have the same model, and archetype IDs / template IDs will follow the same structure.So for ADL2 using archetypes or templates would be the same in the API. Which endpoints do you find problematic in terms of using ADL2? About querying, analyzing your use case, I think there are two ways of knowing the full specialization hierarchy, one is to query an archetype repo/CKM while evaluating a query and do not have that info in the data repo. Like "give me all archetype IDs that specialize arch ID X", this will be [A, B, C], then use that list on the query in your data repo like "archetype_id IN [A, B, C]". The other option is to have the archetype repo/CKM integrated with the clinical data repo (which I don't like architecturally speaking), so the "give me all the archetype IDs that specialize arch ID X" is resolved internally. Considering there is a component that has knowledge about the specialization, and that can be used internally (behind the API) I don't see the need of adding explicit support in the API for archetypes. What I think is better is to define an archetype repo/CKM API to manage archetypes and to resolve specialization queries among other queries like "this path exists for this archetype ID?", etc. If this is possible, we can have interoperability between archetype repos and your queries can use my repo to get specialization info, and vice-versa. Best, Pablo. On Thu, Feb 15, 2018 at 1:09 PM, Pieter Bos <[email protected]<mailto:[email protected]>> wrote: I noticed the recent version of the REST api only works with templates, and not archetypes. As our EHR is ADL 2 only, this has some interesting consequences. Of course, you can upload just the operational templates and probably create a fully functional EHR, but if you work with ADL 2, you would always need an external tool to create the OPT2 from the ADL repository that you want to use, instead of an EHR that generates the OPT2s from the source archetypes itself. Of course, you could just use the ADL workbench or the Archie adlchecker command-line utility to do it for you, but I’m not sure if it’s a nice thing to do. Also if you only use OPT2, you might want to do queries such as ‘retrieve all information that is stored in an EHR that has been derived from archetype with id X, including archetypes specializing from X’ (not just operational template X). An example: retrieve all reports, or all care plans, regardless of the used template. To do that, you probably need a specialization section in the OPT2, which according to the specs should have been removed, and you also need to create operational templates for archetypes that you never use to directly create compositions from. Or the tool querying the EHR must be fully aware of the full archetype specialization tree and use that to create a query with all specializing archetypes included in the query. So, is it intended that the REST API only works with operational templates, and never archetypes? Regards, Pieter Bos From: openEHR-technical <[email protected]<mailto:[email protected]>> on behalf of Thomas Beale <[email protected]<mailto:[email protected]>> Reply-To: For openEHR technical discussions <[email protected]<mailto:[email protected]>> Date: Friday, 26 January 2018 at 14:23 To: Openehr-Technical <[email protected]<mailto:[email protected]>> Subject: openEHR REST APIs - Release 0.9.0 / invitation for comments The REST API Team (Bostjan Lah, Erik Sundvall, Sebastian Iancu, Heath Frankel, Pablo Pazos, and others on the SEC<https://www.openehr.org/programs/specification/editorialcommittee> and elsewhere) have made a 0.9.0 Release of the ITS (Implementation Technology Specifications) component, in order to make a pre-1.0.0 release of the REST APIs available for wider comment. The key point about this current release is that it is meant to be a 'core basics' foundation of APIs to build on, and some services like CDS, and more sophisticated querying (e.g. that Erik Sundvall has published in the past) will be added over time. NOTE THAT IN THE 0.9.0 RELEASE, BREAKING CHANGES ARE POSSIBLE. You can see the ITS Release 0.9.0 link here<https://www.openehr.org/programs/specification/latestreleases>, while the links you see on the specs 'working baseline' page<https://www.openehr.org/programs/specification/workingbaseline> are the result of 0.9.0 plus any modifications made due to feedback. The .apib files are here in Github<https://github.com/openEHR/specifications-ITS/tree/master/REST_API> (see mainly the includes directory). We are aiming to release 1.0.0 at the end of February, at which point the formal process kicks in. Since we are in Release 0.9.0, the formal PR/CR process is not needed, and you can comment here. However, if you want to raise a PR you can, in which case, please set the Component and Affects Version fields appropriately: [cid:[email protected]] - thomas beale -- Thomas Beale Principal, Ars Semantica<http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare<https://intermountainhealthcare.org/> Management Board, Specifications Program Lead, openEHR Foundation<http://www.openehr.org> Chartered IT Professional Fellow, BCS, British Computer Society<http://www.bcs.org/category/6044> Health IT blog<http://wolandscat.net/> | Culture blog<http://wolandsothercat.net/> _______________________________________________ openEHR-technical mailing list [email protected]<mailto:[email protected]> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Ing. Pablo Pazos Gutiérrez [email protected]<mailto:[email protected]> +598 99 043 145 skype: cabolabs [https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ] <http://cabolabs.com/> http://www.cabolabs.com<http://www.cabolabs.com/> https://cloudehrserver.com<https://cloudehrserver.com/> Subscribe to our newsletter<http://eepurl.com/b_w_tj> _______________________________________________ openEHR-technical mailing list [email protected]<mailto:[email protected]> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
