Help in drafting specification for building and distributing "Apps" on top of openEHR and FHIR

Implementation
1

Hello everyone,

I am interested in writing a draft specification for building and distributing reusable apps. The idea is to get to an iPhone or Android like “App marketplace” where we can download and reuse applications on top of vendor neutral APIs.

This is the original article from Dr Mandl et al (Boston Children’s hospital) introducing the motive behind SMART. SMART on FHIR has now been adopted as an industry standard, with a lot of innovation and legislation happening around this space.

The motive is the same, but the implementation of SMART on FHIR does not work for a global marketplace due to FHIR’s regional profiling requirements. I think this can be solved by openEHR’s global, maximal data modelling approach and robust APIs.

We can still however, reuse a majority of the specifications that have been defined on top of FHIR to make it openEHR native, while still maintaining backwards compatibility. Some of these specifications being:

I’ve done research on the above specifications, and have also tried to implmented many of them using open-source libraries alongside openEHR APIs. Combined and used together in a certain way with FHIR and openEHR, they have the potential for building tomorrow’s healthcare app marketplace. There is, however, a need to formally define how these specifications (originally meant to be used with FHIR APIs) are meant to be used with openEHR APIs.

I haven’t written many formal papers or RFCs before and I need help in finding authors who might be interested in writing the first draft. I’m not sure if this could fall under the openEHR specification framework or will be considered it’s own thing, but I know there’s a need to formally define these profiles somewhere.

I’d also like general feedback and comments on the usefulness of such a specification and interest from implementors (especially who’re already using openEHR + FHIR in production) to adopt something like this. I’d like to invite anyone - academecians, implementors or anywhere in between who is interested in contributing to reply to this thread.

PS: If you’re unfamiliar with any of the speficiations mentioned above, I can also help you in quickly getting you up to speed.

Some previous references to this ideas:

Talk at 5th openEHR Asia Conference - https://www.youtube.com/watch?v=aAzTzd2u0UM

8 Likes
2

Here’s a draft Google Doc with the specification (suggesting and commenting enabled for the public): SMART App Launch, CDS Hooks, and SMART Web Messaging on openEHR - Google Docs

4 Likes
3

I added a comment on the Google Doc, As I wondered if an interesting variant on this idea might be to that the Smart App interface might handle both FHIR and openEHR, and just delegate to the appropriate route once past the generic ‘SMART’ aspects - I guess embed behaviour and OAuth ?? A single entry point might be more attractive to app implementers and for simpler embeds

1 Like
4

Hey Ian, having a single Service Discovery url that then provides all the different APIs seems to be the solution for this.

5

Regarding aligning SMART with Netherlands’ Nuts protocol:

According to RFC003 OAuth2 Authorization - V1 a Nuts token can be constructed using JWT assertion (RFC7523). This is one of the possible modes of authentication for SMART and it doesn’t really break the protocol. However it does look like running “vanilla” SMART apps on a server that implements the Nuts flavour of Oauth2 (requiring the tokens to be signed in a specific way) would require the app to know about some additional constructs like UZI, Login contract etc.

I’m wondering if the additional constructs of Nuts can somehow be separated out from the base SMART protocol while still targeting compatibility. Maybe Nuts could be a separate set of APIs that are discoverable on the well-known endpoint and a specific capability would indicate the client app to use Nats style authentication?

1 Like
6

from Slack:

Sidharth Ramesh

I had a few short meetings with @Bostjan Lah and @Borut Fabjan today on the SMART on openEHR and the Eventing spec today.These are the concerns on the openEHR eventing spec draft:

  • event type: org.openehr.definition.template.v1 should not have application/openehr.wt+json since a webtemplate does not represent the template fully
  • event type: org.openehr.contribution.v1 should not exist since a contribution is more like a “transaction”.

Also some feedback on the SMART on openEHR spec:

  • If a .well-known/smart-configuration changes the service’s namespace from a proprietary (care.better.ehrscape) to an official (“org.openehr.ehrscape” or “ehrscape”), the vendor SHOULD advertise the old namespace along with the new official namespace to avoid old apps breaking. New vendor implementations MAY choose to include just the official namespace for the service.
  • The launch token if it is JSON encoded MAY also include extra parameters along with context data to be used for vendor specific operations

I’m trying to make both of the documents more readable and help with the official ASCII doc files, but until then, I can personally explain the gist of both of these specs to any member or vendor who is also interested. It will take around 20 mins to explain SMART and 10 mins to explain the eventing spec. (edited)

1 Like
7

We also talked about this; contribution is indeed not like the other versionable resources, so perhaps cruds does not apply. It is indeed a transaction, and although we have to create a contribution (POST), it is actually “executing” it.
But nevertheless all compositions, folder, ehr_status, ehr_access have to be committed to the EHR with an underlying contribution. And a contribution may contain more versions (a composition+folder, folder+ehr_eccess+ehr_status, etc). Also, if you would like to clone a CDR by listening to events, you won’t make it right unless you also replay contributions (not only versions).

So, I see value into having such event. What are the concerns with the fact that is a transaction?

8

From Slack:

Jorrit Spee:

Hi Sidharth, thanks for taking the time to look into it. I asked the Nuts tech team for input on your remarks. Good to know is that the Nuts team is currently also implementing OpenID for Verifiable Credentials. This is the standard for communication between wallets and agents that will be part of eIDAS2 legislation: https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/arf.md

A couple of weeks ago I presented at FHIR DevDays together with @Frank Olthuijsen. We included a couple of slides with some comparisons between SMARTonFHIR and FHIRxNuts: DD23_Tutorial_230608_FrankOlthuijsen_JorritSpee_FHIRxNuts.pptx - Google Drive (slides 49 en 50)

1 Like
9

@Bostjan_Lah might be good to explain here why contribution as an event may not be required in your opinion?

@sebastian.iancu I feel a CDR could technically still be cloned even if contributions aren’t emitted. It may not be exactly the same, but should logically have the same content executed as different contributions.

10

I am not against contributions, the only thing that bothers me is that we then send data twice.
Apart from meta-data and definitions everything else needs to be written through a contribution. Which means we will stream compositions twice - once in composition events and once in contribution events.
Maybe that is not really a problem and we can have both - listeners can decide if they will use contributions or compositions.

1 Like
11

Why not just stream contributions since these contain the compositions? I’m sure I’m missing something !! Why the need to stream individual compositions? I understand and support the value of having the simplified REST /composition calls which hide the complexity but I’d assumed folks interested in streaming would not find that a barrier?

12

I am in favour of both (or having it configurable). There are probably different use cases we want to cover here - some simpler downstream services might only need compositions and some might need full contributions.

2 Likes