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
