FAQs for the HL7 FHIR Standard


What is the Oracle Health roadmap for FHIR standard implementation?

Both the retired May2015 and current DSTU 2 Final versions of our HL7 FHIR standard implementation are available in production. Our roadmap includes helping provide feedback to the current draft of the FHIR standard, and updating to the latest release. Also, our roadmap is prioritized depending on the maturity of the resources in the FHIR standard (in other words, how stable they are considered), and the needs of our business partners. Some external forces, such as Promoting Interoperability, also help determine the priorities and order for the FHIR standard resources we implement. If you want to create a business partnership with us and help guide our roadmap, see the Oracle Health Developer Program for more information. Once an application is tested in our secure sandbox, read through the Developer Program documentation before submitting your application.

What is the Oracle Health Millennium Web Services toolkit?

Millennium Web Services is an application programming interface (API) that exposes a set of Millennium Platform business and application logic through person-centric web interfaces. The Oracle Health Millennium Web Services toolkit includes web services that provide access to a range of the clinical services that are available on the Millennium Platform. These services include concepts around patient demographics, clinical results, clinical documentation, reporting, and scheduling. The Millennium Web Services are exposed using standard protocols (for example, SOAP, REST, and HTTPS).

What is the future of Millennium Web Services?

With the emergence of the FHIR standard, we expect to migrate Millennium Web Services to the FHIR standard for all services that have a standard resource equivalent. Oracle Health expects that some of the services may never have standard equivalents, and so we maintain those services in addition to the Oracle Health FHIR implementation.

How will Oracle Health implement the FHIR standard?

Oracle Health is currently in the process of implementing the FHIR standard to expose Millennium Platform data to our customers and third-party developers. Oracle Health believes that the FHIR standard can become the public API that the JASON report and the JASON Task Force have called for. We believe the FHIR standard, along with SMART and OAuth2, enable Millennium Platform to become an open electronic health record (EHR) platform that supports innovative developers.

With the Oracle Health implementation of the FHIR standard, what service and protocol is supported?

The current FHIR standard implementation supports the REST API through the HTTPS protocol. Any application capable of making an HTTPS call can consume the Oracle Health implementation of the FHIR standard. We currently have desktop, web, and mobile applications that consume our resources in varying stages of development. We support the SMART platform, OAuth2 authentication, and authorization profiles.

What are SMART applications and what is the Oracle Health position on usage with the FHIR standard?

The SMART (Substitutable Medical applications & Reusable Technology) platform defines a specification for an EHR to safely and securely open other applications with context. These SMART applications are commonly web applications but may also be native mobile applications and use the FHIR standard to read and write data from the EHR. With SMART, Oracle Health can embed a SMART application in the EHR. Oracle Health believes that SMART applications will be a major user of implementations of the FHIR standard resources. We will also support access through mobile SMART applications, as those specifications emerge from the SMART website.

Where can I ask a question?

Anyone can post a question to the community using the Oracle Health Developer Forums.

Common Issues

This topic describes the most common issues that we identify when validating applications to run on our platform. We suggest that you work through each of these topics before submitting an application for validation.

API Usage

Avoid Multiple Resource Calls

Ensure that your application can make efficient API calls. Remove duplicate API calls to avoid additional performance load on the system and to improve application load time. As part of the technical review process, we review logs to see if calls are identical each time and if they are retrieving the same data set.

Implement Paging

Your application should handle paging for all resources, even if our server does not support it yet. This recommendation ensures that your application is compatible with more implementations (including future versions of our server if we add paging to improve performance of resources that do not currently page).

Queries on some resources can result in large data sets. If you do not implement paging logic, the application can miss relevant information because the system does not load more than just the initial page. As a result, the system may not account for the entire patient dataset.

In addition, if your application displays results directly to the user, you probably do not want to display hundreds of records at a time. Your application may not have the memory available to hold all data at one time. Consider these factors when determining the appropriate page size for your application.

Oracle Health recommends one of the following ways to test your logic once implemented:

Posting Documents Using the DocumentReference Resource

If your application uses the DocumentReference resource to post clinical notes back to the system, the following parameters can help ensure that your document is displayed as intended:

Requests by Specific LOINC Codes

Oracle Health maps proprietary codes to standard terminologies as part of our implementation process. For example, LOINC codes are exposed in some resources. Sometimes, these mappings do not cover all the possible variances in the ways hospitals have implemented their EHRs. When EHRs were originally implemented, it was common to use proprietary codes to document laboratory results and measurements that do not map directly to the LOINC codes defined by the FHIR specification.

For the Observation resource, we have seen applications developed that use a set of LOINC codes as a filter to get specific results. If your application uses specific codes to query for data, determine if the request should be broader and include more possible codes to account for different ways data might be coded. You can also work with us to determine the appropriate way to return the information you need.

For example, lead can be performed on blood, capillary blood, or venous blood.

If you are using a specific code to query for lead and use code 5671-3, then your application would only return results when installed at Hospital A. Your application would return nothing if installed at Hospital B. You need to ensure that all codes are accounted for so that the application works at all sites.

Another scenario is where hospitals have different tests and codes set up for different methodologies. An example is when a separate test and code is created to document blood lead collected by venipuncture versus a capillary draw, which is a common collection method for children. On occasion, customer proprietary codes may not map directly to any LOINC code. For special cases where we discover a proprietary code that does not map cleanly to any standard, we can work with you to figure out the appropriate option for that mapping during deployment.

For each of these scenarios, in addition to validating against our sandbox to adhere to the FHIR specification, we also need to validate your application at each customer site to check for hospital-specific considerations. This validation occurs when we connect your application to a hospital domain. We can work with you to resolve any of these hospital-specific considerations.

The above examples use lead, but similar considerations could exist for virtually any laboratory result or measurement where concept mapping and specific LOINC codes are used. If your application uses specific LOINC codes to query for information, contact us on the Oracle Health Developer Forums, and we can help you work through any considerations that might exist.

Use Query Parameters

In many instances, developers perform post-query filtering rather than use the query parameters defined by the API. Oracle Health recommends using the available query parameters. Query parameters make the dataset more predictable, speed up your searches, and are more reliable than relying on post-query filtering.

Review Filtering Options

Using query parameters is recommended over post-query filtering (when possible). Regardless of the method used to filter results, ensure that your application handles resources that have been marked in error or invalid using the appropriate status fields for each resource.

Review your application’s status filtering logic to ensure that the appropriate results are displayed. For the Oracle Health implementation of the HL7 FHIR standard (based on DSTU 2 Final (1.0.2)), this review is important for the MedicationOrder or Observation resources. A patient safety issue can occur if an uncharted value is displayed to a user. Double-check the status codes that you use from the MedicationOrderStatus or ObservationStatus value sets.

Typically, for MedicationOrder, only medications in Active, On-Hold, or Completed statuses are displayed. For Observation, only results in Final and Amended statuses are displayed.

You can read about our available sandbox test patients to find a patient that has some entered-in-error results to test with.

The Condition, MedicationStatement, and Observation resources do not support filtering by the encounter parameter in the current implantation of Oracle Health FHIR APIs. If you do use these resources, your application may need to implement a post-filter to display only the current encounter.

Why do I not see the same data for different users or applications?

Data can be filtered for various reasons. Resources with a status of entered-in-error and sensitive data are filtered out for patient personas. Providers, systems, and applications may have data filtered for encounter and organization security reasons and privilege and preference build in the domain.

If your application is accessing data with a patient persona, your application should handle filtered data.

Using Appropriate Scopes for SMART Launch

SMART on FHIR defines OAuth2 access scopes that correspond directly with FHIR resource types. We define read and write permissions for patient-specific and user-level access. Patient-specific scopes allow access to specific data about a single patient. User-level scopes allow access to specific data that a user can access.

In some situations, user-level scopes are appropriate, but with a patient in context, you use patient-centric scopes.

Registering More Scopes Than Application Uses

Ensure that you are only requesting scopes that are used. You are asked to remove unused scopes from registration if you do not use those resources or actions.

Authorization Durations Longer Than 10 Minutes

The default duration of access received through the authorization grant workflow is a single token that is valid for 570 seconds (~10 minutes). For applications that need access to services for longer durations, some validated applications request a new token each time, but a more streamlined method is available.

By requesting the online_access scope, the system grants a refresh token that can be used during a user’s authenticated session (for more information, see the Authorization Framework). Such refresh tokens are valid until the user explicitly logs out, an administrator terminates the session, or other risk mechanisms (such as timeouts) require a user to be re-authenticated.

Oracle Health Customer Deployment

Using Video in Your Application

Most Oracle Health customers deploy Millennium Platform user applications as a Citrix Xenapplication session connected from a shared server-based computing environment. If your application uses videos, they can challenge the Citrix connection because only so much bandwidth can be assigned to each Citrix connection.

The appropriate method for your application to play video is to open a new window using a custom code and load the web page containing the video. The video opens using the hospital’s network and the Citrix connection is not affected.

Also, when the application is deployed, the hospital’s IT staff need to ensure that the following conditions are met:

To open a new window through content redirection, the underlying Oracle Health platform supports the following APPLINK routine for opening a new window through content redirection instead of window.open through JavaScript. If content redirection is enabled and the URL is accessible by the local device, the video is played locally. If neither of those conditions are met, it is opened on the Citrix server.

For this routine to work, the following META tag must be included in the HEAD of the HTML file: <META content='APPLINK' name='discern'>

The following example illustrates opening a web page through a shell execute. When Citrix is configured for server-to-client redirection and the link is selected, your local default web browser opens and is directed to the link provided.

<a href='javascript:APPLINK(100,"http://www.cerner.com","")'>Launch "http://www.cerner.com" in local web browser</a>

Single Patient and Multi-Patient Views

The Oracle Health EHR, PowerChart (PowerChart.exe), has two main views that can be used to view patient information: the patient chart view and organizer view. Determine which view is appropriate for the functionality of your application and design your application accordingly.

Organizer Views

The MPages worklist framework allows hospitals to use multipatient and multi-item views at the organizer level of PowerChart. These views assist clinicians in organizing and prioritizing their work by providing key information about a population of patients or items. The views can also allow quick access to patients’ medical records, improving their efficiency and productivity. The most common worklist layout type currently available is the patient organizer view, which supports the display of multiple patients with key information about status and care.

Patient Chart View

The patient chart view in PowerChart displays information for a single patient. To open the patient chart, a patient is selected from one of the organizer views or from the patient search results. Multiple patient charts can be open at the same time, and you can select the patient’s name in the patient context toolbar to move between open charts. The patient chart view consists of two panes: the table of contents (TOC) and the workspace. The TOC is displayed on the left side of the window and allows you to move through any area of the patient’s chart. Selecting a PowerChart component in the TOC, such as a SMART application, opens that component’s workspace view. The workspace view displays and changes based on which PowerChart component is selected from the TOC. Each view can include multiple windows that are opened by selecting tabs or buttons in that view. If you open your SMART application from the TOC, information for the patient is displayed in the workspace view.

If your application is used for managing a population of patients, then it should be optimized for use at the organizer view level. If your application is used in the context of a single patient, it is critical that the user should not have access to organizer-level information, such as patient lists or other patients’ data. This information may not be appropriate in a single-patient chart view because users could become confused as to which patient’s information they are viewing. This issue is especially critical if you are porting your application to be used within the SMART on FHIR framework. For example, if developers did not remove functionality such as patient search, they had to restart their validation process once that functionality was removed.

Session Bleed Issue

When you are running a SMART application in multiple open charts in PowerChart, the application instance may share patient context and display the same patient’s data in two separate charts. To avoid this issue, see the HTML5 Session Storage section on the SMART page for information on sessionStorage.

If your application uses the open source fhir-client.js library, see the Open Source FHIR Client Libraries section on the SMART page for more information on the minimum required version and additional code that must be added to fix a session bleed issue.

Note: This issue cannot be properly tested until you are beginning validation and we are running your application directly in PowerChart. The re-creation steps below are for your information once you have access to PowerChart.

Complete the following steps to re-create this issue:

  1. Open the chart for Patient A and open an application.
  2. Go back to the patient list and open an additional chart for Patient B, then open an application for that patient.
  3. On Patient A’s chart, select As Of in the upper-right corner to refresh PowerChart. If the application displays the information for Patient B in the chart for Patient A, then you need to implement the change mentioned above.


As a part of your application’s validation, we perform a security review. After joining the program but before validation begins, you are provided with a security welcome packet that includes up-to-date and specific information on what is looked at during security validation. The items indicated in the packet should be fully completed as described to avoid delays in completing your application’s validation in a timely manner.

While the packet has a comprehensive list of required documentation to submit, you can expect to have items from the following topics requested:

Our current recommended tooling is documented in the packet. Contact us if you have any concerns or questions regarding your application’s security validation.