Re: SMART on FHIR integration

2018-04-24 Thread Seref Arikan 
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.
>>>>
>>>>
>>>>

Re: SMART on FHIR integration

2018-04-24 Thread Seref Arikan 
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 fr

Re: SMART on FHIR integration

2018-04-24 Thread Bert Verhees 

sorry for the sloppy text, a bit in a hurry ;-)

On 24-04-18 10:34, Bert Verhees wrote:
Maybe it is interesting to facilitate a SMART API for OpenEhr (now 
there is an API-definition effort in process for OpenEhr)?
Or is that to market specific and is it something more suitable for 
vendors or other third parties to develop?


That reminds me of an other discussion which runs for years. The 
status of the demographic-RM. To make OpenEhr suitable for consumer 
market-segments, it needs a full demographic section and API. I don't 
know if that was talked about in the latest SEC meetings, but the 
healthICT market is coming out of the hospitals and is going from 
professional healthcare, but also consumer/customer healthcare, and 
there is often no external demographic service except only based on 
OAuth, which has another reliability characteristic.


So, summarizing, healthICT is shifting from healthcare professionals 
to consumers. Does this need adaptations from the OpenEhr side, 
especially in the coming API?


Bert

On 24-04-18 02:23, 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 
<mailto: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/
<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
<mailto:openEHR-technical@lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/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 <mailto:pablo.pa...@cabolabs.com>
+598 99 043 145
skype: cabolabs
<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
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

Re: SMART on FHIR integration

2018-04-24 Thread Thomas Beale 
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 
<mailto: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
<serefari...@kurumsalteknoloji.com
<mailto:serefari...@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
<mailto: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/
<http://aehrc.com/>
work: +61 7 3253 3609; mob: +61 427 456 260

*From:* openEHR-technical
<openehr-technical-boun...@lists.openehr.org
<mailto:openehr-technical-boun...@lists.openehr.org>> on
behalf of Pablo Pazos <pablo.pa...@cabolabs.com
<mailto: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
<mailto: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/
<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
<mailto:openEHR-technical@lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/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 <mailto:pablo.pa...@cabolabs.com>

Re: SMART on FHIR integration

2018-04-24 Thread Bert Verhees 
Maybe it is interesting to facilitate a SMART API for OpenEhr (now there 
is an API-definition effort in process for OpenEhr)?
Or is that to market specific and is it something more suitable for 
vendors or other third parties to develop?


That reminds me of an other discussion which runs for years. The status 
of the demographic-RM. To make OpenEhr suitable for consumer 
market-segments, it needs a full demographic section and API. I don't 
know if that was talked about in the latest SEC meetings, but the 
healthICT market is coming out of the hospitals and is going from 
professional healthcare, but also consumer/customer healthcare, and 
there is often no external demographic service except only based on 
OAuth, which has another reliability characteristic.


So, summarizing, healthICT is shifting from healthcare professionals to 
consumers. Does this need adaptations from the OpenEhr side, especially 
in the coming API?


Bert

On 24-04-18 02:23, 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 
<mailto: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/
<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
<mailto:openEHR-technical@lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/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 <mailto:pablo.pa...@cabolabs.com>
+598 99 043 145
skype: cabolabs
<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
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

Re: SMART on FHIR integration

2018-04-24 Thread Seref Arikan 
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 list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SMART on FHIR integration

2018-04-24 Thread Michael.Lawley 
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 
<serefari...@kurumsalteknoloji.com<mailto:serefari...@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<mailto: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<mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Pablo Pazos 
<pablo.pa...@cabolabs.com<mailto: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<mailto: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<mailto: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<mailto:pablo.pa...@cabolabs.com>
+598 99 043 145
skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=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
openEHR-technical@lists.openehr.org<mailto: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<mailto: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

Re: SMART on FHIR integration

2018-04-24 Thread Seref Arikan 
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

Re: SMART on FHIR integration

2018-04-23 Thread Michael.Lawley 

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<mailto: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<mailto: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<mailto:pablo.pa...@cabolabs.com>
+598 99 043 145
skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=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
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SMART on FHIR integration

2018-04-23 Thread Pablo Pazos 
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  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://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org