On February 25th President Obama at the White House celebrated the one year anniversary of his announcement of the Precision Medicine Initiative. The Initiative, first announced in the President’s State of the Union Address last year, initially invested $215 million in this research approach.
Most medical treatments are designed to treat the average patient. This broad approach fails to account for the differences in genetics, physiology, environments, and lifestyles that greatly impact the effectiveness of therapies. Precision medicine works to overcome these shortcomings by conducting research into the efficacy of the available treatments in different patients using these and additional factors.
For example, Warfarin, a drug used in anticoagulation therapy for patients who need to prevent blood clots from forming (e.g., patients with implanted heart valves or who recently suffered a stroke), showcases the value of precision medicine research. Not to get too technical, the CYP2C9 gene encodes one of the main enzymes involved in the metabolism of Warfarin. In addition, there are several variants of the gene that reduce the enzyme activity, therefore impacting how quickly the drug is metabolized. The speed it is metabolized, affects the length of time after a dose is taken that the drug is effective as an anticoagulant.
Typically, physicians prescribe Warfarin at an average dose. They then conduct multiple lab tests (i.e., blood draws) to adjust the dose up or down depending upon the individual patient’s efficiency in metabolizing the Warfarin as determined by the patient’s variant of the CYP2C9 gene. The titration process can take several weeks as the dose is adjusted up and down. In the meantime, the patient is put at risk for clotting – too little Warfarin – or excessive bleeding – too much Warfarin.
Application of a precision medicine approach would short circuit this methodology and the related risks. As precision medicine takes into account the genetic makeup of patients, in addition to other factors, clinicians applying this medical research would start patients on the proper Warfarin dose at the beginning of therapy rather than needing to employ a trial and error approach to discover the correct dose. Warfarin is just one of many drugs where genetic makeup impacts metabolism. However, without applicable IT systems, precision medicine is doomed.
Precision medicine research requires patient information that historically has been locked up in paper records that proved too difficult and expensive to extract. Even recently, with the advent of EMRs turbo-charged by Meaningful Use and the HITECH act, electronic records exist but not necessarily in searchable, extractable, and interchangeable form.
Unfortunately, like paper records, the failure to foster true interoperability as part of the Meaningful Use criteria used to guide EMR implementations left the industry with valuable data locked up in proprietary formats and incompatible data definitions. Although CCD and CCD-A standards allow for some degree of interoperability, these formats transfer information in large bundles rather than discreet finer-grained elements, the latter being much more useful to researchers and new healthcare analytics applications.
Which brings us to HL7’s proposed FHIR® (Fast Healthcare Interoperability Resources) specification. HL7’s release of the proposed FHIR standard (Welcome to FHIR, 2015) attempts to unlock the data within EMRs and make it available for other applications to utilize. In doing so, it creates the opportunity for a slew of new HCIT applications that can interchange data in ways that are easier, faster, more fine-grained, and more cost effective than previously possible.
Two key characteristics of FHIR make the standard so powerful: data types and metadata. As data types are defined and represented in a common way, single data elements (e.g., blood pressure) become addressable to various HCIT software systems. Metadata then provides a descriptive context and characteristic to the data element. This allows the element to be managed, processed, and routed.
Think of running an Internet search: Each Web page contains metadata that describes the page’s content, which is how search engines like Google® or Bing® know what pages to show us in response to our queries. In the case of a data element like blood pressure, the metadata may suggest that the results need to be routed to Dr. Smith for review.
Data points, forms, images, and unstructured text make up a patient’s EMR. Because EMRs were designed to mimic the pages of a paper record, the information they contain remains trapped within those “pages.” Without the FHIR standard, extracting a data point and understanding its meaning can be very difficult.
Free the Data
FHIR’s ability to isolate and describe data elements frees the data from the monolithic clinical database. Using an application programming interface (API) to access the data, innovative developers can create standalone applications that utilize FHIR-enabled data elements to deliver information to patients and clinicians independent of the EMR. Rather than having the data imprisoned by the predetermined structure, workflow, and user interface of the EMR and other clinical systems, applications can be developed that satisfy the specific needs of both clinical staff and patients. Thus a new breed of clinical HCIT applications is unleashed.
The HL7 organization effectively describes how to think about data element storage and exchange. If a medical record is thought of as a large folder with folders within folders, proximal to other folders, then a patient’s medical information is stored on pages within those many folders. To review that information in paper records, someone must search through the folders and the pages inside to get to the information required. That approach might work well for a human, who can determine which folder to look in (e.g., to find a patient’s weight, a human knows to look in the vital signs folder and then scan the folder’s pages for the correct data element). For a digital system, though, access is not that easy—these systems do not have the analytical power of the human brain. Instead, they require specific instructions about where to find the data element and what characteristics are associated with the element (e.g., the date on which a patient’s weight was measured).
A FHIR-enabled HCIT application will be able to leverage the standard to interact with the key data elements in other FHIR-enabled applications in the following ways:
- Search: Find the data element based on criteria that include the specific data element and other characteristics associated with it (e.g., most recent weight)
- Read: Retrieve the data element selected by the search function and report the results
- Create: Add a new storage location (e.g., folder) to the EMR for storage of similar, newly acquired data elements
- Update: Add a new data element with related descriptors to a folder (e.g., location) for storage
- Delete: Remove an entire set of data elements from storage (i.e., virtually remove it while really identifying it as “do not open”)
- Operation: Perform an action or procedure on data elements in one or more locations and produce a summary record
Composition, Messaging, Services
In addition to these capabilities, FHIR offers other useful and flexible functionality. It uses composition to bring together a set of healthcare-related information and assemble it into a single document, one that includes meaning and context and assigns responsibility to the person assembling the information. Rather than actually containing the content, composition provides the structure for delivering the information in a bundle, where the first data element is the composition. Therefore, composition acts to decipher the content and turn it into an understandable format. To illustrate, think of the periodic table of the elements. Without the structure of the table (i.e., composition)—which orders the elements based upon their number of protons—the elements would be listed randomly and would not have much meaning.
Unlike its predecessors, FHIR includes the concept of messaging and services within the standard facilitating the ability of applications to interoperate using web services and other modern architectures. Messaging provides communication between two digital systems. Per HL7, “the message serves to notify the receiver that the event occurred as well as provide the details about any existing data that was modified or new data that was created” (Welcome to FHIR, 2015). For example, such messaging may indicate that a patient was discharged or a lab order was filled. Services, meanwhile, act as a simpler type of messaging and provide a response to requests for data elements. Such functionality offers the prospect of great utility in clinical decision support. Services could be applied to data element requests (e.g., prescribing penicillin) with a question about the data element (e.g., is the patient allergic to penicillin?).
FHIR is the Key
FHIR is the key to driving the Precision Medicine Initiative. If adopted, it can facilitate the transfer of patient information on a scale that allows stratification of populations by genetics and other factors. Last month the President announced an additional $200 million for the Precision Medicine Initiative. The National Institutes of Health (NIH), the Department of Health and Human Services, the Department of Veteran Affairs, and the Department of Defense are already engaged in projects to advance this initiative.
Specifically, the NIH, in conjunction with the Office of the National Coordinator for Healthcare Information Technology (ONC), sees FHIR as a technology that would allow individual patients to withdraw their own medical information directly from EMRs and make it available to the NIH for medical research. This is clearly an important component of the Vice President’s Cancer Moonshot program.
Technologies that can “FHIR-enable” EMRs through an API are currently under development by EMR and interoperability vendors. It is unknown how the EMR vendors, who have a tight technology leash on their provider clients, intend to roll-out their FHIR APIs. Options include embedding it in an upgrade or releasing it as a bolt on application, and the potential cost worries many provider organizations who initially spent huge sums implementing their EMRs.
Non-EMR vendors see a short 12-24 month window to develop the technology and beat the EMR vendors to market. The potential revenue is huge, but even bigger is the impact FHIR can have on the delivery of precision medicine, and ultimately, improved healthcare for all of us.