Meditech

Submit the Greenfield Workspace registration request

1. Go to the Greenfield landing page and click Register, or open the iFiller registration form directly.

2. Fill out the form with your company information and intended use case. Be specific about the FHIR resources you plan to read and the patient population. Greenfield support uses this to shape the welcome packet and the EULA scope.

3. Submit. You’ll receive an automated acknowledgement, then wait for a welcome packet by email from the Greenfield support team. Turnaround is typically a few business days, not minutes.

Sign the EULA and provide a Google ID

1. The welcome packet contains the Greenfield End-User License Agreement (EULA). Sign it and return it per the packet’s instructions.

2. Provide a Google ID when asked. Greenfield Workspace authenticates members through Google SSO, not a username/password Meditech identity. Use a shared Google Workspace account on your company domain (e.g. dev@yourcompany.com) rather than a personal Gmail. This is the single biggest gotcha. Without a Google identity you cannot log into the workspace at all.

3. Greenfield support confirms your account is provisioned. You’re now ready to log in.

Log into the Greenfield Workspace

Go to greenfield.meditech.com and sign in with your provisioned Google ID. Once inside, you have access to the API Explorer (interactive docs for every exposed endpoint), sample patient data for testing, the US Core FHIR R4 and DSTU2 APIs, and FHIR Scheduling APIs where supported.

Treat the Workspace’s built-in test app as a sanity check that your account is alive. Your own app gets a separate Client ID delivered in the next step.

Receive your OAuth credentials

Meditech does not have a “Create App” button. Credentials are delivered via a secure 1Password share.

1. After your registration is processed, your organization’s primary contact receives an email containing a 1Password link with the Client ID and Client Secret. The link is active for 14 days. Open it once, copy the values into your team’s secret manager, and never paste them into chat or commit them.

2. Issues with the 1Password link or signing in to the Workspace? Email greenfieldinfo@meditech.com. That inbox is scoped narrowly to sandbox access issues (Google sign-in problems, Greenfield Portal access). It is not the channel for redirect URI registration or scope changes.

3. The registered client comes pre-configured. The grant type is authorization_code (3-legged OAuth, SMART Standalone Launch), and the sandbox enables the wildcard patient/*.read scope for exploratory testing. The wildcard works in Greenfield only. Production restricts you to the minimum scopes for your approved workflow.

4. The sandbox endpoints are fixed and shared across all Greenfield tenants, with no per-customer discovery.

Verify these any time by curling the SMART configuration URL. It returns authorization_endpoint, token_endpoint, and the full scopes_supported list as JSON.

⚠️ Critical: Meditech’s authorization codes are signed JWTs with a 60-second TTL, not the opaque multi-minute codes most OAuth servers issue. Your callback handler must exchange the code for tokens immediately. Manual copy-paste flows will routinely expire, and any retry or queue logic between callback and token exchange has to fit inside that 60-second window. If you’re integrating through the Medblocks Platform, the exchange already happens inline in the callback.

Configure your redirect URI

The Greenfield sandbox does not require you to pre-register redirect URIs by email. Meditech accepts any URI that conforms to the pattern rules below. Pass it as redirect_uri on the authorize call and use the same value verbatim on the token exchange.

Using the Medblocks Platform? Your callback URL is already handled. Use https://app.medblocks.com/api/auth/smart/callback as your redirect URI, with no custom domain or backend setup needed.

⚠️ Critical: The URI must match exactly between the authorize request and the token exchange, including protocol, domain, port, and path. A mismatch at authorize time returns a 400 with redirectUri: null in the error envelope, before the patient ever sees a login screen.

Select scopes

Meditech exposes the standard US Core FHIR R4 patient scopes, in both SMART v1 (patient/Patient.read) and v2 (patient/Patient.rs) formats.

1. For the sandbox, request openid fhirUser launch/patient offline_access patient/*.read and you’ll have read access to every supported US Core resource.

2. For production, the wildcard is not allowed. List every scope your workflow actually needs, at minimum patient/Patient.read, patient/Observation.read, patient/Condition.read, patient/MedicationRequest.read, patient/AllergyIntolerance.read, patient/DocumentReference.read, patient/Immunization.read, patient/Procedure.read, and patient/Encounter.read, plus openid, fhirUser, launch/patient, and offline_access for refresh tokens.

3. The authoritative scope list is in the SMART configuration.

curl -s https://greenfield-prod-apis.meditech.com/v2/uscore/STU6/.well-known/smart-configuration | jq .scopes_supported

Important Notes on Scopes

Enter your Client ID in the Medblocks Platform

1. Navigate to Settings → EHR Clients → Meditech in the Medblocks admin panel.

2. Enter the Client ID from your 1Password delivery.

3. Share the Client Secret with Medblocks support through a secure channel so it can be configured server-side. The secret authenticates every token exchange and refresh, so it never belongs in frontend code or a repository.

The Meditech Greenfield sandbox is already registered as a source on the platform, so once the credentials are in place, patients see Meditech as a connect option in your app.

Test the connection in your app

With the credentials in place, run the connect flow end to end. Create a patient session, pick Meditech from the source list, and complete the authorization.

One quirk to know before you sign in. The patient login is your Greenfield Google account, not a separate test-patient credential. When the authorize step opens the Meditech sign-in page, use the same Google account you registered with Greenfield, and the token returns that user’s synthetic patient context.

After the connection completes, the platform pulls the patient’s records in the background and you can read the data through the API or SDK. Seeing the synthetic patient’s demographics and observations come back confirms the whole chain, credentials, redirect URI, scopes, and token exchange.

Want to poke the sandbox APIs without your app in the loop? See the optional Postman section below.

Going live at a customer hospital

Greenfield testing is not required for production and does not initiate production onboarding. Production is a separate, organization-driven process.

1. You secure an active engagement with a healthcare organization that has reviewed and approved the proposed integration.

2. The healthcare organization opens a case with their Meditech Interoperability team to initiate onboarding. You cannot start this yourself. Plan for a per-hospital sales and onboarding cycle.

3. Meditech and the organization handle scope approval and registration. Provide the organization with your Client ID, your production redirect URI (https://app.medblocks.com/api/auth/smart/callback for Medblocks Platform), and the list of scopes your app requests.

4. The organization’s production FHIR endpoint is published in the public endpoint directory. Contact Medblocks support to get that FHIR base URL added as a source for each new organization.

⚠️ Critical: Greenfield credentials never become production credentials, and there is no global “make my app live everywhere” toggle. Each hospital issues its own registration.