Hi Pieter, 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]> 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]> on > behalf of Thomas Beale <[email protected]> > Reply-To: For openEHR technical discussions <openehr-technical@lists. > openehr.org> > Date: Friday, 26 January 2018 at 14:23 > To: Openehr-Technical <[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] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > -- Ing. Pablo Pazos Gutiérrez [email protected] +598 99 043 145 skype: cabolabs <http://cabolabs.com/> http://www.cabolabs.com https://cloudehrserver.com Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
