The Patient Role in a Federal National-Scale Health Information Exchange.

The federal Trusted Exchange Framework and Common Agreement (TEFCA) aims to reduce fragmentation of patient records by expanding query-based health information exchange with nationwide connectivity for diverse purposes. TEFCA provides a common agreement and security framework allowing clinicians, and possibly insurance company staff, public health officials, and other authorized users, to query for health information about hundreds of millions of patients. TEFCA presents an opportunity to weave information exchange into the fabric of our national health information economy. We define 3 principles to promote patient autonomy and control within TEFCA: (1) patients can query for data about themselves, (2) patients can know when their data are queried and shared, and (3) patients can configure what is shared about them. We believe TEFCA should address these principles by the time it launches. While health information exchange already occurs on a large scale today, the launch of TEFCA introduces a major, new, and cohesive component of 21st-century US health care information infrastructure. We strongly advocate for a substantive role for the patient in TEFCA, one that will be a model for other systems and policies.

Modeling and validating HL7 FHIR profiles using semantic web Shape Expressions (ShEx).

BACKGROUND: HL7 Fast Healthcare Interoperability Resources (FHIR) is an emerging open standard for the exchange of electronic healthcare information. FHIR resources are defined in a specialized modeling language. FHIR instances can currently be represented in either XML or JSON. The FHIR and Semantic Web communities are developing a third FHIR instance representation format in Resource Description Framework (RDF). Shape Expressions (ShEx), a formal RDF data constraint language, is a candidate for describing and validating the FHIR RDF representation. OBJECTIVE: Create a FHIR to ShEx model transformation and assess its ability to describe and validate FHIR RDF data. METHODS: We created the methods and tools that generate the ShEx schemas modeling the FHIR to RDF specification being developed by HL7 ITS/W3C RDF Task Force, and evaluated the applicability of ShEx in the description and validation of FHIR to RDF transformations. RESULTS: The ShEx models contributed significantly to workgroup consensus. Algorithmic transformations from the FHIR model to ShEx schemas and FHIR example data to RDF transformations were incorporated into the FHIR build process. ShEx schemas representing 109 FHIR resources were used to validate 511 FHIR RDF data examples from the Standards for Trial Use (STU 3) Ballot version. We were able to uncover unresolved issues in the FHIR to RDF specification and detect 10 types of errors and root causes in the actual implementation. The FHIR ShEx representations have been included in the official FHIR web pages for the STU 3 Ballot version since September 2016. DISCUSSION: ShEx can be used to define and validate the syntax of a FHIR resource, which is complementary to the use of RDF Schema (RDFS) and Web Ontology Language (OWL) for semantic validation. CONCLUSION: ShEx proved useful for describing a standard model of FHIR RDF data. The combination of a formal model and a succinct format enabled comprehensive review and automated validation.

Beyond compliance with the 21st Century Cures Act Rule: a patient controlled electronic health information export application programming interface.

OBJECTIVE: The 21st Century Cures Act Final Rule requires that certified electronic health records (EHRs) be able to export a patient's full set of electronic health information (EHI). This requirement becomes more powerful if EHI exports use interoperable application programming interfaces (APIs). We sought to advance the ecosystem, instantiating policy desiderata in a working reference implementation based on a consensus design. MATERIALS AND METHODS: We formulate a model for interoperable, patient-controlled, app-driven access to EHI exports in an open source reference implementation following the Argonaut FHIR Accelerator consensus implementation guide for EHI Export. RESULTS: The reference implementation, which asynchronously provides EHI across an API, has three central components: a web application for patients to request EHI exports, an EHI server to respond to requests, and an administrative export management web application to manage requests. It leverages mandated SMART on FHIR/Bulk FHIR APIs. DISCUSSION: A patient-controlled app enabling full EHI export from any EHR across an API could facilitate national-scale patient-directed information exchange. We hope releasing these tools sparks engagement from the health IT community to evolve the design, implement and test in real-world settings, and develop patient-facing apps. CONCLUSION: To advance regulatory innovation, we formulate a model that builds on existing requirements under the Cures Act Rule and takes a step toward an interoperable, scalable approach, simplifying patient access to their own health data; supporting the sharing of clinical data for both improved patient care and medical research; and encouraging the growth of an ecosystem of third-party applications.

A proposal for shoring up Federal Trade Commission protections for electronic health record-connected consumer apps under 21st Century Cures.

Under the 21st Century Cures Act and the Office of the National Coordinator for Health Information Technology (ONC) rule implementing its interoperability provisions, a patient's rights to easily request and obtain digital access to portions of their medical records are now supported by both technology and policy. Data, once directed by a patient to leave a Health Insurance Portability and Accountability Act-covered health entity and enter a consumer app, will usually fall under Federal Trade Commission oversight. Because the statutory authority of the ONC does not extend to health data protection, there is not yet regulation to specifically address privacy protections for consumer apps. A technologically feasible workflow that could be widely adopted and permissible under ONC's rule, involves using the SMART on FHIR OAuth authorization routine to present standardized information about app behavior. This approach would not bias the patient in a way that triggers penalties under information blocking provisions of the rule.

Patient-led data sharing for clinical bioinformatics research: USCDI and beyond.

The 21st Century Cures Act, passed in 2016, and the Final Rules it called for create a roadmap for enabling patient access to their electronic health information. The set of data to be made available, as determined by the Office of the National Coordinator for Health IT through the US Core Data for Interoperability expansion process, will impact the value creation of this improved data liquidity. In this commentary, we look at the potential for significant value creation from USCDI in the context of clinical bioinformatics research and advocate for the research community's involvement in the USCDI process to propel this value creation forward. We also describe 1 mechanism-using existing required APIs for full data export capabilities-that could pragmatically enable this value creation at minimal additional technical lift beyond the current regulatory requirements.

A landscape survey of planned SMART/HL7 bulk FHIR data access API implementations and tools.

The Office of National Coordinator for Health Information Technology final rule implementing the interoperability and information blocking provisions of the 21st Century Cures Act requires support for two SMART (Substitutable Medical Applications, Reusable Technologies) application programming interfaces (APIs) and instantiates Health Level Seven International (HL7) Fast Healthcare Interoperability Resources (FHIR) as a lingua franca for health data. We sought to assess the current state and near-term plans for the SMART/HL7 Bulk FHIR Access API implementation across organizations including electronic health record vendors, cloud vendors, public health contractors, research institutions, payors, FHIR tooling developers, and other purveyors of health information technology platforms. We learned that many organizations not required through regulation to use standardized bulk data are rapidly implementing the API for a wide array of use cases. This may portend an unprecedented level of standardized population-level health data exchange that will support an apps and analytics ecosystem. Feedback from early adopters on the API's limitations and unsolved problems in the space of population health are highlighted.

Push Button Population Health: The SMART/HL7 FHIR Bulk Data Access Application Programming Interface.

The 21st Century Cures Act requires that certified health information technology have an application programming interface (API) giving access to all data elements of a patient's electronic health record, "without special effort". In the spring of 2020, the Office of the National Coordinator of Health Information Technology (ONC) published a rule-21st Century Cures Act Interoperability, Information Blocking, and the ONC Health IT Certification Program-regulating the API requirement along with protections against information blocking. The rule specifies the SMART/HL7 FHIR Bulk Data Access API, which enables access to patient-level data across a patient population, supporting myriad use cases across healthcare, research, and public health ecosystems. The API enables "push button population health" in that core data elements can readily and standardly be extracted from electronic health records, enabling local, regional, and national-scale data-driven innovation.

Opening the Duke electronic health record to apps: Implementing SMART on FHIR.

OBJECTIVE: Recognizing a need for our EHR to be highly interoperable, our team at Duke Health enabled our Epic-based electronic health record to be compatible with the Boston Children's project called Substitutable Medical Apps and Reusable Technologies (SMART), which employed Health Level Seven International's (HL7) Fast Healthcare Interoperability Resources (FHIR), commonly known as SMART on FHIR. METHODS: We created a custom SMART on FHIR-compatible server infrastructure written in Node.js that served two primary functions. First, it handled API management activities such rate-limiting, authorization, auditing, logging, and analytics. Second, it retrieved the EHR data and made it available in a FHIR-compatible format. Finally, we made required changes to the EHR user interface to allow us to integrate several compatible apps into the provider- and patient-facing EHR workflows. RESULTS: After integrating SMART on FHIR into our Epic-based EHR, we demonstrated several types of apps running on the infrastructure. This included both provider- and patient-facing apps as well as apps that are closed source, open source and internally-developed. We integrated the apps into the testing environment of our desktop EHR as well as our patient portal. We also demonstrated the integration of a native iOS app. CONCLUSION: In this paper, we demonstrate the successful implementation of the SMART and FHIR technologies on our Epic-based EHR and subsequent integration of several compatible provider- and patient-facing apps.

More Medicine, Fewer Clicks: How Informatics Can Actually Help Your Practice.

In the information age, we expect data systems to make us more effective and efficient-not to make our lives more difficult! In this article, we discuss how we are using data systems, such as electronic health records (EHRs), to improve care delivery. We illustrate how US Oncology is beginning to use real-world evidence to facilitate trial accrual by automatic identification of eligible patients and how big data and predictive analytics will transform the field of oncology. Some information systems are already being used at the point of care and are already empowering clinicians to improve the care of their patients in real time. Telehealth platforms are being used to bridge gaps that currently exist in expertise, geography, and technical capability. Optimizing virtual collaboration, such as through virtual tumor boards, is empowering communities that are geographically disparate to coordinate care. Informatics methods can provide solutions to the challenging problems of how to manage the vast amounts of data confronting the practicing oncologist, including information about treatment regimens, side effects, and the influence of genomics on the practice of oncology. We also discuss some of the challenges of clinical documentation in the modern era, and review emerging efforts to engage patients as digital donors of their EHR data.

The effect of an electronic health record-based tool on abnormal pediatric blood pressure recognition.

BACKGROUND: Recognition of high blood pressure (BP) in children is poor, partly due to the need to compute age-sex-height referenced percentiles. This study examined the change in abnormal BP recognition before versus after the introduction of an electronic health record (EHR) app designed to calculate BP percentiles with a training lecture. METHODS AND RESULTS: Clinical data were extracted on all ambulatory, non-urgent encounters for children 3-18 years old seen in primary care, endocrinology, cardiology, or nephrology clinics at an urban, academic hospital in the year before and the year after app introduction. Outpatients with at least 1 BP above the age-gender-height referenced 90th percentile were included. Abnormal BP recognition was defined as a BP related ICD-9 code, referral to nephrology or cardiology, an echocardiogram or renal ultrasound to evaluate BP concern, or a follow-up primary care visit for BP monitoring. Multivariable adjusted logistic regression compared odds of recognition before and after app introduction. Of 78 768 clinical encounters, 3521 had abnormal BP in the pre- and 3358 in the post-app period. App use occurred in 13% of elevated BP visits. Overall, abnormal BP was recognized in 4.9% pre-app period visits and 7.1% of visits post-app (P < .0001). Recognition was significantly higher when the app was actually used (adjusted OR 3.17 95% CI 2.29-4.41, P < .001). Without app use recognition was not different. CONCLUSIONS: BP app advent modestly increased abnormal BP recognition in the entire cohort, but actual app use was associated with significantly higher recognition. Predictors of abnormal BP recognition deserve further scrutiny.

SMART-on-FHIR implemented over i2b2.

We have developed an interface to serve patient data from Informatics for Integrating Biology and the Bedside (i2b2) repositories in the Fast Healthcare Interoperability Resources (FHIR) format, referred to as a SMART-on-FHIR cell. The cell serves FHIR resources on a per-patient basis, and supports the "substitutable" modular third-party applications (SMART) OAuth2 specification for authorization of client applications. It is implemented as an i2b2 server plug-in, consisting of 6 modules: authentication, REST, i2b2-to-FHIR converter, resource enrichment, query engine, and cache. The source code is freely available as open source. We tested the cell by accessing resources from a test i2b2 installation, demonstrating that a SMART app can be launched from the cell that accesses patient data stored in i2b2. We successfully retrieved demographics, medications, labs, and diagnoses for test patients. The SMART-on-FHIR cell will enable i2b2 sites to provide simplified but secure data access in FHIR format, and will spur innovation and interoperability. Further, it transforms i2b2 into an apps platform.

SMART on FHIR: a standards-based, interoperable apps platform for electronic health records.

OBJECTIVE: In early 2010, Harvard Medical School and Boston Children's Hospital began an interoperability project with the distinctive goal of developing a platform to enable medical applications to be written once and run unmodified across different healthcare IT systems. The project was called Substitutable Medical Applications and Reusable Technologies (SMART). METHODS: We adopted contemporary web standards for application programming interface transport, authorization, and user interface, and standard medical terminologies for coded data. In our initial design, we created our own openly licensed clinical data models to enforce consistency and simplicity. During the second half of 2013, we updated SMART to take advantage of the clinical data models and the application-programming interface described in a new, openly licensed Health Level Seven draft standard called Fast Health Interoperability Resources (FHIR). Signaling our adoption of the emerging FHIR standard, we called the new platform SMART on FHIR. RESULTS: We introduced the SMART on FHIR platform with a demonstration that included several commercial healthcare IT vendors and app developers showcasing prototypes at the Health Information Management Systems Society conference in February 2014. This established the feasibility of SMART on FHIR, while highlighting the need for commonly accepted pragmatic constraints on the base FHIR specification. CONCLUSION: In this paper, we describe the creation of SMART on FHIR, relate the experience of the vendors and developers who built SMART on FHIR prototypes, and discuss some challenges in going from early industry prototyping to industry-wide production use.

SMART precision cancer medicine: a FHIR-based app to provide genomic information at the point of care.

BACKGROUND: Precision cancer medicine (PCM) will require ready access to genomic data within the clinical workflow and tools to assist clinical interpretation and enable decisions. Since most electronic health record (EHR) systems do not yet provide such functionality, we developed an EHR-agnostic, clinico-genomic mobile app to demonstrate several features that will be needed for point-of-care conversations. METHODS: Our prototype, called Substitutable Medical Applications and Reusable Technology (SMART)® PCM, visualizes genomic information in real time, comparing a patient's diagnosis-specific somatic gene mutations detected by PCR-based hotspot testing to a population-level set of comparable data. The initial prototype works for patient specimens with 0 or 1 detected mutation. Genomics extensions were created for the Health Level Seven® Fast Healthcare Interoperability Resources (FHIR)® standard; otherwise, the prototype is a normal SMART on FHIR app. RESULTS: The PCM prototype can rapidly present a visualization that compares a patient's somatic genomic alterations against a distribution built from more than 3000 patients, along with context-specific links to external knowledge bases. Initial evaluation by oncologists provided important feedback about the prototype's strengths and weaknesses. We added several requested enhancements and successfully demonstrated the app at the inaugural American Society of Clinical Oncology Interoperability Demonstration; we have also begun to expand visualization capabilities to include cancer specimens with multiple mutations. DISCUSSION: PCM is open-source software for clinicians to present the individual patient within the population-level spectrum of cancer somatic mutations. The app can be implemented on any SMART on FHIR-enabled EHRs, and future versions of PCM should be able to evolve in parallel with external knowledge bases.

Driving Innovation in Health Systems through an Apps-Based Information Economy.

Healthcare data will soon be accessible using standard, open software interfaces. Here, we describe how these interfaces could lead to improved healthcare by facilitating the development of software applications (apps) that can be shared across physicians, health care organizations, translational researchers, and patients. We provide recommendations for next steps and resources for the myriad stakeholders. If challenges related to efficacy, accuracy, utility, safety, privacy, and security can be met, this emerging apps model for health information technology will open up the point of care for innovation and connect patients at home to their healthcare data.

Are Meaningful Use Stage 2 certified EHRs ready for interoperability? Findings from the SMART C-CDA Collaborative.

BACKGROUND AND OBJECTIVE: Upgrades to electronic health record (EHR) systems scheduled to be introduced in the USA in 2014 will advance document interoperability between care providers. Specifically, the second stage of the federal incentive program for EHR adoption, known as Meaningful Use, requires use of the Consolidated Clinical Document Architecture (C-CDA) for document exchange. In an effort to examine and improve C-CDA based exchange, the SMART (Substitutable Medical Applications and Reusable Technology) C-CDA Collaborative brought together a group of certified EHR and other health information technology vendors. MATERIALS AND METHODS: We examined the machine-readable content of collected samples for semantic correctness and consistency. This included parsing with the open-source BlueButton.js tool, testing with a validator used in EHR certification, scoring with an automated open-source tool, and manual inspection. We also conducted group and individual review sessions with participating vendors to understand their interpretation of C-CDA specifications and requirements. RESULTS: We contacted 107 health information technology organizations and collected 91 C-CDA sample documents from 21 distinct technologies. Manual and automated document inspection led to 615 observations of errors and data expression variation across represented technologies. Based upon our analysis and vendor discussions, we identified 11 specific areas that represent relevant barriers to the interoperability of C-CDA documents. CONCLUSIONS: We identified errors and permissible heterogeneity in C-CDA documents that will limit semantic interoperability. Our findings also point to several practical opportunities to improve C-CDA document quality and exchange in the coming years.

The SMART Platform: early experience enabling substitutable applications for electronic health records.

OBJECTIVE: The Substitutable Medical Applications, Reusable Technologies (SMART) Platforms project seeks to develop a health information technology platform with substitutable applications (apps) constructed around core services. The authors believe this is a promising approach to driving down healthcare costs, supporting standards evolution, accommodating differences in care workflow, fostering competition in the market, and accelerating innovation. MATERIALS AND METHODS: The Office of the National Coordinator for Health Information Technology, through the Strategic Health IT Advanced Research Projects (SHARP) Program, funds the project. The SMART team has focused on enabling the property of substitutability through an app programming interface leveraging web standards, presenting predictable data payloads, and abstracting away many details of enterprise health information technology systems. Containers--health information technology systems, such as electronic health records (EHR), personally controlled health records, and health information exchanges that use the SMART app programming interface or a portion of it--marshal data sources and present data simply, reliably, and consistently to apps. RESULTS: The SMART team has completed the first phase of the project (a) defining an app programming interface, (b) developing containers, and (c) producing a set of charter apps that showcase the system capabilities. A focal point of this phase was the SMART Apps Challenge, publicized by the White House, using http://www.challenge.gov website, and generating 15 app submissions with diverse functionality. CONCLUSION: Key strategic decisions must be made about the most effective market for further disseminating SMART: existing market-leading EHR vendors, new entrants into the EHR market, or other stakeholders such as health information exchanges.