Revision as of 12:32, 14 January 2017

Medication Track

Submitting WG/Project/Implementer Group

Justification

This project is intended to support the Pharmacy WG in moving the Pharmacy FHIR resources to a higher maturity level based on feedback from the Argonaut Project, HL7 work groups and industry implementers. The key objective for this project is to use implement and test the following FHIR Medication related resources and the corresponding US-Core medication Profiles:

In addition to implementing the existing US-Core medication Profiles this tract will examine and support the development of new proposed US-Realm profiles for MedicationAdministration and MedicationDispense.

We will also introduce the scenario for search across all Medication Resources using common search parameter as it is described in the Core Specification

Proposed Track Lead

Expected participants

Please sign up!

If you're working on a server, please complete the "servers" tab of the Signup Spreadsheet **This time around you'll need to update the `status` flag to indicate whether you've begun work (or completed work), so clients will know when to start testing.** You'll also share details about how a developer can obtain OAuth client credentials (`client_id` for public apps, or a `client_id` and `client_secret` for confidential apps) as well as user login credentials. You might consider simply sharing a set of fixed credentials in this spreadsheet, or else directing users to a web page where they can complete self-service registration. If absolutely necessary, you can ask developers to e-mail you directly.

If you're working on a client, please complete the "clients" tab of the Spreadsheet. You'll also need to update the `status` flag to indicate whether you've begun work (or completed work).

Roles

(reproduced from Argonaut Project implementation-program Resprint)

Server/EHR

If you're working on a server, please complete the "servers" tab of the Sprints Spreadsheet (see above). You'll need to update the status flag to indicate whether you've begun work (or completed work), so clients will know when to start testing. You'll also share details about how a developer can obtain OAuth client credentials (client_id for public apps, or a client_id and client_secret for confidential apps) as well as **user login credentials. The preferred approach is to direct users to a web page where they can complete self-service registration. (If absolutely necessary, you can ask developers to e-mail you directly.)
Work on your OAuth implementation

open server. Before you get OAuth working, and even once you have an OAuth-secured server, it can be helpful to host sample data at a totally unprotected https endpoint. This facilitates testing, debugging, and exploration

Standalone launch. Following SMART’s “standalone launch” flow means that the user (patient, or clinician) can begin by launching an app, and from there can engage in a “connect to my EHR” workflow. This approach is suitable for MU3 patient API access.

EHR launch. Following SMART’s “EHR launch” flow means that the user (patient, or clinician) can begin from the EHR or potal, and launch an app from there, ensuring that the app learns the context about the surrounding EHR or portal environment. This approach is suitable for embedding apps in an EHR or portal.

Single Sign-on. Using the OAuth2-based OpenID Connect framework for single sign-on, your authorization server can “vouch for” a user’s identity. This helps ensure that users don’t need to create a new account, with new credentials, for every app they use. This approach to SSO can be used with either of SMART’s launch flows.

Client

If you're working on a client, please complete the "clients" tab of the Sprints Spreadsheet (see above) . You'll also need to update the status flag to indicate whether you've begun work (or completed work).

Medication Track

Submitting WG/Project/Implementer Group

Justification

This project is intended to support the Pharmacy WG in moving the Pharmacy FHIR resources to a higher maturity level based on feedback from the Argonaut Project, HL7 work groups and industry implementers. The key objective for this project is to use implement and test the following FHIR Medication related resources and the corresponding US-Core medication Profiles:

In addition to implementing the existing US-Core medication Profiles this tract will examine and support the development of new proposed US-Realm profiles for MedicationAdministration and MedicationDispense.

Proposed Track Lead

Expected participants

Please sign up!

If you're working on a server, please complete the "servers" tab of the Signup Spreadsheet **This time around you'll need to update the `status` flag to indicate whether you've begun work (or completed work), so clients will know when to start testing.** You'll also share details about how a developer can obtain OAuth client credentials (`client_id` for public apps, or a `client_id` and `client_secret` for confidential apps) as well as user login credentials. You might consider simply sharing a set of fixed credentials in this spreadsheet, or else directing users to a web page where they can complete self-service registration. If absolutely necessary, you can ask developers to e-mail you directly.

If you're working on a client, please complete the "clients" tab of the Spreadsheet. You'll also need to update the `status` flag to indicate whether you've begun work (or completed work).

Roles

Server/EHR

If you're working on a server, please complete the "servers" tab of the Connectathons Spreadsheet (see above). You'll need to update the status flag to indicate whether you've begun work (or completed work), so clients will know when to start testing. You'll also share details about how a developer can obtain OAuth client credentials (client_id for public apps, or a client_id and client_secret for confidential apps) as well as **user login credentials. The preferred approach is to direct users to a web page where they can complete self-service registration. (If absolutely necessary, you can ask developers to e-mail you directly.)
Work on your OAuth implementation

open server. Before you get OAuth working, and even once you have an OAuth-secured server, it can be helpful to host sample data at a totally unprotected https endpoint. This facilitates testing, debugging, and exploration

Standalone launch. Following SMART’s “standalone launch” flow means that the user (patient, or clinician) can begin by launching an app, and from there can engage in a “connect to my EHR” workflow. This approach is suitable for MU3 patient API access.

EHR launch. Following SMART’s “EHR launch” flow means that the user (patient, or clinician) can begin from the EHR or potal, and launch an app from there, ensuring that the app learns the context about the surrounding EHR or portal environment. This approach is suitable for embedding apps in an EHR or portal.

Single Sign-on. Using the OAuth2-based OpenID Connect framework for single sign-on, your authorization server can “vouch for” a user’s identity. This helps ensure that users don’t need to create a new account, with new credentials, for every app they use. This approach to SSO can be used with either of SMART’s launch flows.

Client

If you're working on a client, please complete the "clients" tab of the Connectathons Spreadsheet (see above) . You'll also need to update the status flag to indicate whether you've begun work (or completed work).

Success Criteria:Server returns a Bundle containing entries for each of the use cases above

Bonus point:

1. Search for a patient medication across all of the medication resources.

In this scenario, the medication list includes MedicationRequest, MedicationAdministration and MedicationDispense resources in addition to MedicationStatement and multiples queries or a _revinclude on Patient would be used See Bonus 2. below for a discussion of cross resource searches using common search parameters.

The medication list includes MedicationRequest, MedicationAdministration and MedicationDispense resources

Questions for discussion:
1 Should there be a Category element and parameter for MedicationAdministration and MedicationDispense as well?
This would allow a single query across all medications resources for a medication list.

GET [base]?_type=MedicationStatement,MedicationRequest?status=active,completed,stopped,on-hold&subject=[id]&_format=[mime-type]