Thomas, from my phone, short. The Sct integration as I propose is optional. No changes in openehr specs is needed. No software change is needed. It are only additions except for two minor issues.
So if organization's do not want to use Sct, or are not allowed to use it, they still can keep on using Openehr. So you don't need to solve all those mappings before integrating Sct. Organizations can start right now, I can help, or another developer can help building the additional needed software and the most beautiful, an archetype editor based on SCT. Op ma 12 sep. 2016 17:38 schreef Grahame Grieve < [email protected]>: > yes. In our terminology, this is paging through an expansion > > Grahame > > > On Tue, Sep 13, 2016 at 1:34 AM, Thomas Beale <[email protected]> > wrote: > >> >> In other words something like a DB cursor to traverse large value sets >> that reside on the server, in response to client (user) actions on the >> screen? Has that been implemented in FHIR-land? >> >> - thomas >> >> On 12/09/2016 16:26, Grahame Grieve wrote: >> >>> The best way to resolve this is to make the terminology server part of >>> the local system, and have the resolution a dynamic one between the >>> systems. That allows you to optimise the performance implications of large >>> value sets. >>> >>> Grahame >>> >>> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > > > > -- > ----- > http://www.healthintersections.com.au / [email protected] > / +61 411 867 065 > _______________________________________________ > openEHR-technical mailing list > [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
