Upon first login after March 31, 2024, all Infoway Account users will be required to reconfirm acceptance of the Terms of Use and License Agreements. Learn More >

Share this page:

file Canadian SMART on FHIR CoP - Meetings

  • Posts: 29
2 years 10 months ago - 2 years 10 months ago #6847 by Paula Martin
SMART North - May 10, 2021, Meeting Notes
Attendees: Paula L, Jason L, Dan S, Ted J, John W, Adam W, Bikram B, Pechow Z, Adam C, Radhika V, Tim B, Steve S, Doug K, SajadcH, Caryn H, Elliot S, Mohammed L, Micahl S, Syed A, Harsh S, Dwayne P, Shamil N, Joel F, Patrick P, Yaron D, Cori T
Meeting Recording: contact paula dot lee at ehealthce dot ca

NOTE: Adam C from SMILE CDR has offered to share his practical experience through Smile CDR implementing FHIR in the US with insurance companies. If you are interested in hearing the US FHIR context in an upcoming call, please let me know and we can add it to the agenda.

• Action Items Summary
o Note taker required for May 31st meeting
o Paula to work with Russ to start a chart – when to consider SMART on FHIR vs. server to server FHIR API
• Upcoming Agenda Items
o eForms use case – Shamil
o chat.fhir.org discussion channel? John W
1. Continue demonstration of eReferral SMART launch from EMR/EHR/HIS to external system
a. Doug summarized that previously on Monday, April 26th meeting
i. OCEAN launchee is launched by a launcher (Cerner, EPIC, Dapasoft) and accomplishes 1) SSO between 2 systems (EHR and OCEAN); and 2) Launch can transfer patient context.
ii. EHRs have SMART on FHIR guides that describe workflow details
iii. Challenges are in 1) safe and secure manner; and 2) minor incompatibilities in the payload (90% compatible with FHIR)
b. Joel asked how does the application know it is time to refresh the token? Does the app intercept the 401 error or is it managed via a session?
i. Implementation detail that is defined as part of the Oath2.0 protocol. For example, see EPIC section 7 fhir.epic.com/Documentation?docId=oauth2§ion=Embedded-Oauth2-Launch_ID-Tokens. Doug corroborated that it is the tricky part and recommend, if possible, to avoid using Refresh Tokens and this use case. However, Adam C suggested that using Refresh Tokens is the correct pattern.
ii. As an aside, John W mentioned that in the context of client_credentials authorization flow, it recommends against refresh tokens. SMART uses authorization_code grant type which should be fine.
c. Adam C asked how different systems map resource (MedicationRequest, Dispense, etc..) into their databases.
i. Doug mentioned that their launch had a limit payload dataset; however, it some data elements (e.g. OHIP number) a broader set of logic to search and find and read the correct value was necessary.
d. Sajjad asked regarding eReferral Launch use-case, whether it only *.read is needed; or in addition, *.write was also part of business use-case to document the eReferral at Patient chart?
i. Yaron mentioned that OCEAN use case was just *.read but will be working on getting a summary of the referral back to the launching system.
e. Sajjad asked what data model is OCEAN using
i. Doug stated OCEAN is proprietary database but for SMART Launch it follows the FHIR standards and OCEAN leverages HAPI FHIR library.
ii. Tim mentioned that FHIR is an interchange model and not meant for systems to replicate that model. Doug concurred that FHIR is optimized for data mapping; however, you would pay for it on the database architecture and management side. But it’s good to keep FHIR as part of database design conversation.
f. Paula asked how target system returns data to sending system
i. Depending on the workflow there are 2 access approaches: SMART on FHIR (user authorization) versus server-to-server comparison and when to choose each pattern.
ii. SMART on FHIR (user authorization)
• OCEAN chooses server [resource].write (e.g. Patient.write or Observation.write) and that would allow the target server to send back information to the sending system.
iii. Elliot mentioned that SMART does have CDS Hooks which enable a two-way flow. Some deeper technical implication changes involve time-to-live (TTL) token
• Paula recommended that these meetings at the moment, should be focused on high level business use cases and not on technical details
g. Additional resources include the following:
i. smilecdr.com/docs/smart/smart_on_fhir_introduction.html
ii. docs.smarthealthit.org/
iii. www.hl7.org/fhir/smart-app-launch/

2. Review of the ONE ID Oath specification, comparison to OAuth2
a. Ted did a high level walk through of ONE ID OpenID Connection Specification ehealthontario.on.ca/en/standards/one-id-openid-connect-specification
i. Section 5.0 OAuth Interface specifications: All Clients
• Tim asked could you build a Use Case where you (EMR) could login with ONE ID and get basic context and further leverage CMS to supplement additional context to launch another application. Ted said that this is a valid use case.
• Radhika provided Ontario CMS Spec link simplifier.net/guide/ontariocontextmanagement/newitem
i. ONE ID supports both old SAML as well as OAuth2 and extends it (e.g. ID tokens for additional attributes)
ii. Dan provided link for OAuth2.0 backgrounder: oauth.net/2/
iii. For those interested in providing feedback to BC PharmaNet API design currently being proposed, based on the OAuth2.0 framework, please see github.com/bcgov/moh-eRx/blob/dev/docs/design/eRX_API_Design.md
Last edit: 2 years 10 months ago by Paula Martin.

Please Log in or Create an account to join the conversation.

  • Posts: 29
2 years 10 months ago #6828 by Paula Martin
Done, my apologies.

Please Log in or Create an account to join the conversation.

  • Posts: 6
2 years 10 months ago #6827 by Caryn Harris
Hi Paula
This email is bouncing back as undeliverable: paula dot lee at ehealthce dot com
And this email is bouncing back as address rejected:access denied" paula dot lee at ehealthce dot ca
Could you reconfirm your email address, please
Many thanks
Caryn

Please Log in or Create an account to join the conversation.

  • Posts: 29
2 years 10 months ago - 2 years 10 months ago #6824 by Paula Martin
Our next meeting will take place on Monday May 10th and we will continue our deep dive into the eReferral Launch from EMR/HIS use case.

If time allows, Ted will lead us in a review of the ONE ID Oath specification to see the differences compared to Oath2.0.

email paula dot lee at ehealthce dot ca for calendar invite details.

* edited email address
Last edit: 2 years 10 months ago by Paula Martin.

Please Log in or Create an account to join the conversation.

  • Posts: 29
2 years 10 months ago #6823 by Paula Martin
SMART North - April 26, 2021, Meeting Notes
- Thanks to Jason for his excellent note taking on April 26th and May 10th.
- Volunteer note take requested for May 31st.

Next Meeting: May 10 @ 2pm
- continue Ocean demonstration discussion (Doug, Yaron)
- review of the ONE ID Oath specification to see the differences compared to Oath2.0 If time allows: ehealthontario.on.ca/en/standards/one-id-openid-connect-specification

1. Action Items Summary
a. Paula to send out email with a call-out for additional Simplifier maintenance volunteers.
b. Doug to share Ocean presentation slide deck. (see below)
c. Paula to send an invitation for May 10 @ 2pm to continue Ocean demonstration discussion (complete)
d. Paula to add a review of the ONE ID Oath specification to see the differences compared to Oath2.0 at next monthly meeting.

2. Welcome & Roll Call
Attendees: Paula Lee, Jason Lin, Sheridan Cook, Joel Francis, Justin Wolting, Russell Buchanan, Sean Mikalson, Tim Berezny, Ted Jin, Patrick Pyette, Radhika Verma, Yaron Derman, Dan S, Igor Sirkovich, Mohammed Loubanni, Francis Lau, Pechow Zheng, Doug Kavanagh, Lance Adams, Thodoros Topaloglou, Syed Ahmed, Arun Bala, Ion Moraru, 14164492166, John Wills, Shamil Nizamov, Thomas Chu, Anil Patel

3. Review of Action Items
a. All: Bring applicable real life business use cases for eReferral launch from EMR/EHR/HIS to external system & Complete a form (within the FHIR SDC framework) to next meeting
See below
b. All: If you have skills in posting to Simplifier – please let Paula know. A group of authors will take turns keeping our project up to date.
Joel set up simplifier.net/canadiansmartonfhircommunitypractice
Sheridan volunteered to assist Joel in updating the Simplifier page.
Action Item: Paula to send out email with a call-out for additional Simplifier maintenance volunteers.
c. All: We need a name: Canadian SMART on FHIR Community of Practice doesn’t roll off the tongue, and something to distinguish us from similar US groups
Group agreed on suggestion from Yaron: SMART North
d. All: Send potential agenda items to Paula - DONE
e. Future Agenda Item: Consider a discussion channel on chat.fhir.org

4. Doug & Yaron demonstrated eReferral launch from EMR/EHR/HIS to external system
• CognisantMD: Documentation & Current Implementations
• SMART intro Ocean SMART App Launch (SMART on FHIR ER Contextual Launch) uses Open ID Connect standard openid.net/connect/
• Ocean ‘launchee’ is connected out of both 1) St Joseph’s Hamilton EPIC ‘launcher’ and 2) Champlain LHIN Cerner that was co-developed with Dapasoft.
o Action Item: Doug to share Ocean presentation slide deck.
• Ted Jin asked about leveraging Ontario Health ONE ID Oath SSO ONE ID OIDC specification: ehealthontario.on.ca/en/standards/one-id-openid-connect-specification; Doug said that Ontario Health ONE ID is essentially Oath2.0. ONE ID is SAML.
• Action Item: Paula to add a review of the ONE ID Oath specification to see the differences compared to Oath2.0 at next monthly meeting.
• Tim asked if there should be one Canadian approach? Doug alluded to a number of challenges/incompatibilities to do mostly with formatting (e.g. unordered). This will be discussed in greater detail at the Ocean follow-up meeting on May 10th.
• Ion asked how does Ocean ‘launcher’ know what information is required by the HIS ‘launchee’?
o Answer: Ocean has to register to be a trusted app within their ecosystem.
• Ion asked how does SMART Launcher discover what does the 3rd party app require for context?
o Answer: Discovery process / app registration process will determine what you need to include as part of use of the app. Security in order to be whitelisted and what are the common use cases/APIs/operations (e.g. Patient.Create (R4) Patient.create (STU3), patient/Observation.read) that are supported.
• Ion asked what methods can be used to present an outcome back to the user.
o Answer: Yaron shared that CDS Hooks is also a method to present an outcome back to the user
• Yaron provided links to the following Health Information System SMART on FHIR documentation:
o Meditech: home.meditech.com/restapiresources/index.html#authorization-code-grant-access-token-post
o Epic: fhir.epic.com/Documentation?docId=launching
o Cerner: code.cerner.com/developer/smart-on-fhir/apps/e085a883-2895-4633-b406-5f6ffeb1badb
• Continuation of Ocean demo at next special Meeting. Action Item: Paula to send an invite for Monday, May 10 @ 2pm to continue Ocean demonstration discussion.

5. Complete a form (within the FHIR SDC framework)
• Da Vinci CRD (Coverage Requirement Discovery) and Da Vinci DTR (Documentation Templates and Rules) IGs www.hl7.org/fhir/us/davinci-dtr/use_case.html#crd-and-dtr-workflow (Shamil)
o Deferred to May 24th meeting.
o Shamil provided SMART App Gallery link apps.smarthealthit.org/apps/
o This will be discussed alongside Da Vinci CRD at Monday, May 24 meeting.

Ocean eReferral Use Cases
1. Review eReferral dashboard for inbound and outbound referral management
2. Launch a new referral
3. Sending an internal referral within an organization (special case of #1 & 2)
General SMART Documentation / Getting Started
• HL7 Smart App Launch Quick start
• smarthealthit.org Test Sandbox / "Smart App Launcher"
• Making Your EHR Smart

• Infoway
Vendor Documentation for SMART
• Ocean by CognisantMD
• Meditech
code.cerner.com/
fhir.epic.com/
• Dapasoft
Open ID for Single Sign-On
• OpenID Connect Specification
• Epic's explanation for Open ID
Challenges we've seen across instances for FHIR:
• Finding the "primary" value to use for a patient among several instances of the same PHI items (e.g. addresses, names) with various "uses":
o "home" vs "usual" vs "official"
o (different uses and recommendations from different vendors)
• Canadian-specific FHIR challenges we've seen:
o Finding SMART-compatible vendors in the Canadian health IT community (as discussed; a SMART North listing would help)
o Relative lack of patient sample JSON values from source systems
o Health number format inconsistencies: "JHN" vs "urn:oid:1.2.840.114350.1.13.517.2.7.5.737384.48"
o HN province of the HN identifier: "fhir.infoway-inforoute.ca/NamingSystem/ca-on-patient-hcn" vs "ontario" vs "on"
o HN Version code formatting: "health-card-version-code" vs "1.2.840.114350.1.13.517.3.7.5.737384.23028"

Please Log in or Create an account to join the conversation.

  • Posts: 29
2 years 11 months ago #6796 by Paula Martin
The next meeting of the SMART on FHIR Community of Practice is this upcoming Monday at 2pm: infocentral.infoway-inforoute.ca/en/news-events/event-calendar/icalrepeat.detail/2021/04/26/4437/-/canadian-smart-on-fhir-community-of-practice

We will be looking at the use cases from CognisantMD's Ocean eReferral launch from EMR/EHR/HIS to external system. Other implementations of this use case are welcome to present their samples also.

If we have time, we will also look at the eForm business case examples suggested by Shamil: Da Vinci CRD (Coverage Requirements Discovery) and Da Vinci DTR (Documentation Templates and Rules) IGs - www.hl7.org/fhir/us/davinci-dtr/use_case.html#crd-and-dtr-workflow

Many thanks to Jason for offering to take notes this meeting.

Please Log in or Create an account to join the conversation.

InfoCentral logo

Improving the quality of patient care through the effective sharing of clinical information among health care organizations, clinicians and their patients.