It just occurred to me that I unintentionally made a suggestion for implementing this at the app level using openEHR: match the actor to an ehr within an "app defined context", wrap current APIs with overloaded versions that require an app defined context and call the standard apis if the context is unique etc etc.
On Tue, Apr 24, 2018 at 9:50 AM, Seref Arikan <serefari...@gmail.com> wrote: > Thanks Tom, > > Based on your description, this sounds like something that is completely > an app level concern for an openEHR based application. I mean, all > operations on clinical data need an EHR context, the APIs don't let data > written to the wrong EHR unless well, you provide the wrong EHR identifier > :) Can't see how this needs safeguarding at the spec/platform level other > than having the correct semantics in place, which as far as I can see, > openEHR does. > > I guess (from a specification point of view) a naive implementation could > match an Actor to an EHR within a context (which is the bit we don't have > in RM to cover this use case I guess) and require the context identifier > for operations on data to enforce what you're describing but that'd be > creating a lot of complexity for a potential problem that could be solved > much easier at the app level. > > > > On Tue, Apr 24, 2018 at 9:38 AM, Thomas Beale <thomas.be...@openehr.org> > wrote: > >> He is talking about user context, known as CCOW in HL7, which is to do >> with solving the problem of ensuring a user with possibly multiple patients >> open in applications doesn't mix them up. Especially important if the >> application is meant to stay open while focussing on different patients >> (i.e. not continuously opening and closing). Some solutions to this do >> tricks on the screen such as locking / greying out applications not >> connected to the 'current patient'. >> >> The data of this kind of context is all in openEHR (probably the one >> standard that actually has it), but you still have to design applications >> to use it in a smart way, or else you'll have a screen with 10 windows open >> and they'll be connected to 3 different patients. >> >> Another way to think about this kind of idea is that you don't just log >> into a system, but also to a patient (context). >> >> - thomas >> >> On 24/04/2018 09:05, Seref Arikan wrote: >> >> Thanks, would you say then, this definition of context sounds similar to >> the electronic health record concept openEHR is built on? >> >> As in, providing a core EHR concept >> <http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_ehr_package> >> exposed by APIs? >> >> If you have an application without this concept or based on an organic >> implementation of this concept, then SMART would make sense. >> >> I cannot see the use for it when using openEHR, based on your definition >> of its real value, since there is no diverging or non-existent context >> here. >> I think SMART would help in scenarios where you must mimic a platform on >> top of a number of black boxes, which is not the case with openEHR. This >> also sound like the answer to Brian's question, thanks to your kind >> response. >> >> I'll leave it to others (who know SMART and openEHR) to compare the depth >> and robustness of context provided by SMART with openEHR's EHR model. >> >> All the best >> Seref >> >> >> On Tue, Apr 24, 2018 at 8:48 AM, <michael.law...@csiro.au> wrote: >> >>> Broadly, the context is the current patient being looked at in the EMR, >>> or other platform being used to launch the SMART App. >>> >>> This allows the app to request authorisation for data specific to the >>> 'current patient' and then launch directly into the task. >>> >>> Michael >>> >>> Sent from my iPhone >>> >>> On 24 Apr 2018, at 5:23 pm, Seref Arikan <serefarikan@kurumsalteknoloji >>> .com> wrote: >>> >>> Could you explain what you mean by context please? >>> >>> On Tue, Apr 24, 2018 at 1:23 AM, <michael.law...@csiro.au> wrote: >>> >>>> >>>> The real value of SMART (whether its "on FHIR" or not) is that it sets >>>> a mechanism for EMRs to pass context to external apps. This means apps are >>>> re-usable across different back ends. >>>> >>>> >>>> Note that this is not really about authentication (SSO) but rather it >>>> is about authorisation. >>>> >>>> >>>> michael >>>> >>>> >>>> -- >>>> Dr Michael Lawley >>>> Research Group Leader, Health Informatics >>>> The Australia e-Health Research Centre http://aehrc.com/ >>>> work: +61 7 3253 3609; mob: +61 427 456 260 >>>> ------------------------------ >>>> *From:* openEHR-technical <openehr-technical-boun...@lists.openehr.org> >>>> on behalf of Pablo Pazos <pablo.pa...@cabolabs.com> >>>> *Sent:* Tuesday, 24 April 2018 9:29 AM >>>> *To:* For openEHR technical discussions >>>> *Subject:* Re: SMART on FHIR integration >>>> >>>> SSO is a front end feature, that is not on the current scope of the >>>> openEHR specs. >>>> >>>> I think any openEHR implementer can do SSO at the front-end app level >>>> to access SMART apps. >>>> >>>> On Mon, Apr 23, 2018 at 6:14 PM, Brian Nantz <br...@nantz.org> wrote: >>>> >>>>> I see you have had discussions on FHIR and SMART on FHIR. Is it on >>>>> the roadmap for openEHR to support SMART on FHIR launch sequence ( >>>>> http://docs.smarthealthit.org/authorization/) for single sign on? I >>>>> know many customers who would like this seemless integration. >>>>> >>>>> _______________________________________________ >>>>> openEHR-technical mailing list >>>>> openEHR-technical@lists.openehr.org >>>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >>>>> lists.openehr.org >>>>> >>>> >>>> >>>> >>>> -- >>>> Ing. Pablo Pazos Gutiérrez >>>> pablo.pa...@cabolabs.com >>>> +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 >>>> openEHR-technical@lists.openehr.org >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >>>> lists.openehr.org >>>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical@lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >>> lists.openehr.org >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical@lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >>> lists.openehr.org >>> >> >> >> >> _______________________________________________ >> openEHR-technical mailing >> listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> -- >> 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 >> openEHR-technical@lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >> lists.openehr.org >> > >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
