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.
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.
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
Could you explain what you mean by context please?
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
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 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
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
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
sorry for the sloppy text, a bit in a hurry 
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.