Web Services and Cloud Computing in Pediatric Care

The Health Information Technology for Economic and Clinical Health Act, part of the 2009 American Recovery and Reinvestment Act, helped to drive adoption of electronic health records (EHRs). This act paid incentives to eligible health care providers meeting meaningful use requirements.¹  Per the Office of the National Coordinator for Health Information Technology, 96% of hospitals and 78% of physician offices use certified EHR technology.^2,3 

Unfortunately, some EHRs used by pediatricians are still not supportive of pediatric functionalities, such as plotting growth charts or computing anthropometric percentiles, tracking adherence to well-child visits and immunizations, supporting weight-based dosing, or determining catch-up immunizations.^4,5  Safe pediatric medication prescribing, in particular, has been noted as an area where meaningful use has fallen short.^6,7  In addition to these fundamental pediatric EHR capabilities, additional pediatric EHR requirements that have been previously described for outpatient⁸  and inpatient⁹  systems have not routinely been available in the systems adopted.¹⁰ 

Web services and applications often require local customization, either by the practice or by the EHR vendor (with corresponding time lag). This report explores the technical and legal foundations when creating and integrating clinical Web services and applications for use in pediatric health care.

A software service is code that can be executed within the context of another process or application.¹¹  The earliest software services were based on technologies such as remote procedure calls, whereby an application could communicate with another application on the same computer to process information using the other application’s processing or memory space.¹² 

The ability to encapsulate computer logic to be run between computer processes and applications gains a lot of power when expanded to the Internet. Web services are software services in which the calling application uses Internet protocols to access services on a different machine (or cloud of machines). Logic encapsulated in a service can be called from applications anywhere on the World Wide Web and processed by the service using the Web service’s processor or memory, with results returned to the calling applications. Web services typically use standard communications protocols for information transport and structure. Some services, such as Simple Object Access Protocol (SOAP), use data exchange with Hypertext Transport Protocol, unsecured or secured (HTTP versus HTTPS), with information these days often encoded in extensible markup language (XML).^11,13,14,15 

Some Web services support the sharing of resources within the Web services using representational state transfer (REST), in which resources are accessed via uniform resource identifiers (URIs). These resources are accessed by using standard interfaces and protocols such, as GET, PUT, POST, and DELETE. When representational state transfer is used, interactions with resources require that the resources be passed explicitly through the interfaces.¹⁶ 

It is fairly common for applications to use Web services provided by a vendor (eg, Amazon Web Services, Microsoft Azure, Salesforce Customer Relationship Management) to allow the application writer to focus on the more novel parts of their application, letting the Web service platform handle the minutiae of straightforward operations (eg, data storage, databases), authentication, networking, messaging and/or e-mail, cross-platform functionality, and updating, or to encapsulate the complex processing of “big” clinical data. The concept of Web service requests that can be processed by multiple different processors and by different vendors is known more broadly as “cloud computing.” Cloud computing places the maintenance and expertise related to maintaining hardware and software in the hands of the Web service vendor, reducing the customer’s needs to supply the computing power.¹⁷ 

More recently, SMART (Substitutable Medical Applications, Reusable Technologies) application programming interface (API) has been defined to allow applications built atop EHRs to access EHR data in a way that is more independent of EHRs.¹⁸  The SMART API is used to access information in the EHR, such as medications, and the resulting data, such as a decision support solution, come back in a SMART data format. EHR vendors implement the SMART API on their EHRs by mapping their internal data structures to the normalized clinical data structures that SMART is expecting. SMART applications also support an authentication standard and selected terminology standards, such as RxNorm, Logical Observation Identifiers Names and Codes (LOINC), and Systematized Nomenclature of Medicine–Clinical Terms (SNOMED CT). SMART applications are HTML5 applications that can run within Web browsers and frames. The SMART standards include open-source libraries, a “sandbox” for application testing, and an app gallery for users.¹⁸ 

More recently, Health Level Seven defined standards for Fast Healthcare Interoperability Resources (FHIR), with implementers using this standard to support laboratory result exchanges.¹⁹  FHIR represents clinical resource profiles as intuitive interoperable concepts, such as MedicationPrescription, which may refer to a prescriber, patient, and drug prescribed. The SMART group took these FHIR specifications (which included FHIR descriptions of about 50 clinical resource profiles with APIs for data access) and added the SMART concepts of authorization, authentication, additional SMART resource profiles, and user interface integration, which they call SMART on FHIR.²⁰ 

SMART resource definitions require EHR vendors to normalize their data, and early developer experiences with SMART on FHIR suggest that vendors are reluctant to adopt this technology.²⁰  Although FHIR does not require the data normalization, the combination of SMART on FHIR typically requires some adjustments to run on each individual vendor platform.

Web-based services and applications are desirable because they allow for clinical logic to be developed and programmed once and then shared across many different applications and/or EHRs. The ability of developing a shareable resource only once is the major benefit of “modular programming,” in which logic is encapsulated in a module instead of being repeatedly redeveloped with the potential for errors. Established technical protocols like SMART on FHIR allow for Web services to be accessed from multiple platforms.

Web-based services and applications hold the promise that they may speed the implementation of computable pediatric clinical functions in EHRs. Instead of focusing resources on understanding and correctly interpreting clinical algorithms or logic, the vendors need to focus only on how to call the Web service and correctly integrate and display its results. For the vendor, the underlying logic and operation of the Web service may remain a black box. For simple Web services, such as some that provide content for discharge instructions, vendors simply call the Web service to retrieve the discharge instruction information then customize format and display for printing.²¹  The encapsulation of expertise may allow medical specialty societies and organizations to serve as the clinical experts if they can provide Web services and applications that permit integration with EHRs.²² 

In addition to encapsulating expertise, Web services and applications simplify the maintenance of clinical logic. Web services can, for example, provide immunization forecasting based on the immunizations already given to the patient.²³  When EHR vendors integrate such a service, any Web service logic update that reflects updatd immunization recommendations from the American Academy of Pediatrics or from the Centers for Disease Control and Prevention Advisory Committee on Immunization Practices would immediately be available to users of different EHRs without any required changes to the EHR software, assuming that the interface remains preserved.

Another advantage of creating Web services and applications relates to testing. Because the logic is encapsulated in one place, the Web service can be called by a small test application to ensure that it is working correctly before integrating the service with the more complex environment of EHRs. Calls to the Web service can be automated so that regression testing scenarios (eg, in the immunization example, ensuring that immunization logic for parts of the immunization schedule that were not updated still works correctly). And because the Web service is ubiquitously available on the Internet, testing efforts can be shared among multiple stakeholders in different locations instead of reliance on vendor internal testing and discovery of errors by end-user clinicians.²⁴ 

There are abundant examples of nonmedical Web services that are used by Web sites people visit every day. Maps that are integrated into hotel or restaurant Web sites are usually externally generated and then incorporated into the site through a Web service. Calculations of latitude and longitude are externally determined to measure distances between addresses when searching for the shortest route. Centralized data from real estate listings are accessed and integrated into individual realtor Web sites. There are also Web services that support data storage and cloud computing, although these services may or may not always be secure enough in managing protected health information to comply with the Health Insurance Portability and Accountability Act (HIPAA).²⁵ 

Clinical Web services and applications are more limited at this time. Initial experiments with encapsulated logic included independently developed solutions to improve EHR safety.²⁶  For example, a calculator for continuously infused medication was integrated with a vendor EHR. Web services and applications offer opportunities to catalyze the integration of pediatric-specific functionalities into EHRs. Immunization decision support could be accomplished by sending immunization data and relevant demographic and clinical data to a resource that performs an assessment and returns forecasted results. A multitude of pediatric-specific calculations, such as percentiles for pediatric hypertension assessment, could also be readily available through Web services.²⁷ 

One of the simplest types of Web services takes a term and uses a Web service to find out more information about that term. This type of functionality is called “Infobutton” technology because it is based on the user interface concept of being able to highlight a term then click on an “info button” or menu selection to learn more about what has been highlighted.²⁸ 

One example of this technology is when users can send the Web service a diagnosis code in SNOMED, International Classification of Diseases, Ninth Revision, or International Classification of Diseases, 10th Revision, and an XML (or JavaScript Object Notation [JSON] or JSON with Padding [JSONP]) construct will be returned that contains patient education information for that medical condition. Services are also provided to support pharmacy and/or medication lookup by RXCUI (RxNorm concept unique identifer for the clinical drug or substance)/NDC and laboratory test lookup by LOINC. In addition to being accessible by EHR programs.²⁹ 

Clinical calculators take selected patient information and use it to provide a customized report or calculation. Calculation Web services are best if they not only provide good calculations and can handle erroneous or missing inputs gracefully but also provide references and explanations for their calculation results.³⁰  Some examples amenable to being provided as Web services to support pediatrics may include the following:

• Fahrenheit (English) to Celsius (metric) conversion;

• length or height, weight, weight for height, and BMI percentiles, including condition-specific growth charts, such as for cerebral palsy³¹  or Down syndrome³² ;

• blood pressure percentiles;

• neonatal morbidity and mortality calculations for preterm infants;

• medical translation services; and

• services that take input and use natural language processing to spell check, grammar check, or correct text.

One published example of a simple pediatric Web service that can be easily integrated into an EHR relates to plotting values on a bilirubin nomogram. Such a Web service can take 3 arguments (hour of life, bilirubin level, and units) as part of a URL and return a Web page that describes the infant’s risk for developing severe hyperbilirubinemia based the American Academy of Pediatrics bilirubin nomogram.^33–35 

Several Web services exist to provide clinical decision support for immunizations.^36–38  These services can be integrated into EHRs, allowing for both the forecasting of future vaccine doses and the validation of existing documented doses. The different services may have different business models and methods of integration.

The SMART App Gallery lists applications for bilirubin level charting, blood pressure percentiles, rheumatology summaries (including joint homunculi), and growth charts.³⁹  Although these apps are likely in use at the institutions that developed them, it is unclear whether these apps are in use at other institutions.

The factors that both vendors and users need to consider when Web services and applications are used are similar to those to assess when practices are considering purchasing an EHR: application availability, downtime procedures, data ownership, interoperability and vocabularies, and workflow analysis and simulation. In addition, there are 2 new underappreciated areas to consider: transparency of the logic of the Web service and concerns about the ability to identify individuals from their data.^40,41 

Performance and uptime characteristics are critical. Delays in results from the Web service will often be perceived by end users as failures in the EHR itself. If the EHR fails or generates cryptic error messages because of a Web service failure, health care providers may become disgruntled, and it may be difficult for the practice and for the vendor to address the problem in real time because the Web service is controlled by a third party. Health care providers have the expectation that their EHRs will be available when they are needed, and some health care providers may require that these systems be available 24/7 (eg, for emergency and/or inpatient care).

Acceptable downtime for Web services is driven by the agreements between the end users (physicians or EHR vendors) and by the type of services. If the Web service provides a low risk service which can easily be done manually (eg, plotting a point on a growth chart), downtime may be more tolerable than if it performs a more mission critical operation (eg, dose range checking). It will be up to the health care provider and his or her EHR vendor to negotiate response time to unforeseen problems with Web service providers.

Clinical calculators may take a fixed set of inputs and return a fixed output. For example, a Web service can convert from English to metric units (eg, Fahrenheit to Celsius, pounds to kilograms, inches to centimeters). Although such a Web service would, in theory, not need to store any data, it could (eg, it could store what it was called with and/or administrative data included in the Web request, such as the IP address of where the request originated). Web service developers have used information passed to them to try to improve their services and to attempt to generate revenue (eg, targeted advertising through Google AdSense).

Web services and applications may save data so that in the event of interruption, they can continue from where they left off. The information may be stored in the client (EHR) application or in the application’s storage. To keep track of stored information, apps may use identifiers. If identifiers use protected health information, either individually or in aggregate (eg, Social Security numbers), HIPAA may apply. Web services and applications need to validate sent data in a way that does not compromise the security of the calling application or computing environment. Hackers may attempt to exploit Web services to gain control over the process and/or memory to which Web services have access (as seen with recent events related to ransomware) or to access health information, which is of increasing value on the black market.⁴²  Ideally, Web services will execute within a protected address space where any failures cannot compromise the processor or memory running the Web service.

Just as a Web service must maintain integrity with inputs, EHR applications that call Web services must process returns from the Web service in a safe manner. EHR data sent to a Web service that would contain protected health information should be (1) securely transmitted between the application and the Web service; (2) managed per HIPAA rules by the Web service (as described in business associate agreements between EHR vendors, Web service or application vendors, and the clinical practice); and (3) controlled by an agreement that describes any storing of information sent to the Web service and its ownership and use.⁴³ 

A potential additional risk of Web services using the Internet and storing data are that these separate data repositories can become compromised. If the application vendor stores data using Web services, and authentication is insufficient (as reported with the initial version of Apple iCloud, which allowed celebrity passwords to be guessed by brute force without lockouts after a certain number of failed password attempts), the data stores may be hacked, allowing access to data backed up from phones.⁴⁴ 

It is desirable to use existing data and vocabulary standards when developing Web services. Using existing standards, such as RxNorm, LOINC, SNOMED, and International Classification of Diseases, will allow data to be exchanged with other clinical systems, will capitalize on vendor support for these standards, and will reduce the effort required to connect to and integrate Web services.⁴⁰ 

Consumers of different Web services and applications may vary significantly. Ideally, Web services for clinicians will be integrated in the regular workflow; for example, the Web service is available through the clinician’s EHR, which autopopulates data sent to the service with the appropriate patient information. Some Web services or applications can be accessed via links to Web pages.

From a technical standpoint, Web services and applications constitute software code that can be used ubiquitously. End users may, by default, assume that applications have been tested and are safe. They may not have a clear understanding of how results, such as recommendations or calculated values, are achieved. All clinical software should be transparent as to the evidence applied and calculations made. Making the work transparent allows stakeholders (such as informaticians and clinician end users) to be informed when determining whether the software supports organizational goals when deciding whether to integrate the software.

Web services and applications, especially those that perform calculations, should cite references and provide transparency to algorithms used so that any recommendation can be validated and verified. Transparency will aid both users and developers. Users who disagree with the Web service’s recommendation can review the underlying assumptions and rules and may be able to contact the developer and suggest changes and corrections. If improvements or corrections are needed in a Web service or application, the Web service should be reconfigured rapidly, with the anticipated time frame communicated, to maintain clinician cooperation and engagement.³⁰ 

Health care identities are considered more valuable than simple credit card numbers and achieve higher prices on the black market. Health care identities may be used to apply for credit, to file fraudulent tax returns, or to commit Medicare and/or Medicaid fraud. Measures to protect identities are only as good as the most insecure step. Data passed to Web services should be limited to the minimum needed for execution, especially if protected health information is requested. Use of heuristics to allow patient record deduplication is recommended when possible.⁴⁵ 

A simple way to determine the correct amount of information to pass to a Web service involves simulation in which the developer team examines the data being requested or sent to the Web service and reviews them in aggregate and in the context of the mission and functionality of the Web service. A Web service designed to perform Fahrenheit to Celsius conversion that is requesting patient identifiers would raise concerns and be flagged as requesting more data than required. Such analysis is critically important, especially in the case of identified data, because data in transit or stored outside of the system may potentially be more vulnerable to compromise.

Aggregating data from one source with other sources allows previously anonymous data to be identified. Even if identifying information has not been provided, an unintended consequence of sharing data with Web services and applications is the discerning of identities, especially if the data are combined with the increasing amount of public data on individuals. For example, when AOL released a list of searches that were grouped by anonymous search identifiers, the identity of one searcher was revealed just from queries.⁴⁶  When similar events occur in a health context, patients could be vulnerable not only to a lack of privacy but also to blackmail, discrimination, or other threats.

To support successful implementation, the Web service interface and outputs should be clearly specified. The application must respect the data requirements of the Web service (eg, if a Web service is passing a length or height of a patient and the Web service requires that the length or height be specified in centimeters, then the calling application needs to provide the length or height in the appropriate units). The application is responsible for converting data into the format required by the Web service.

The EHR application calling the Web service should transmit information via a secure, encrypted channel, especially if protected health information is involved. The EHR vendor must ensure that the Web service will handle data securely. This can be achieved by either an agreement, such as a business associates agreement, or, in exceptional cases, by reviewing source code to ensure that (1) the Web service does not store data or (2) the Web service stores data in a secure manner and in a secure location not vulnerable to compromise. Ideally, the business associates agreement will also describe what data the Web service is collecting, the ownership of data, and the permissible data uses.

Currently, many EHR systems authenticate users using a username, password, and location-based authentication. EHR vendors are to determine when a Web service is accessing user data, how the Web service will be authenticated, and what access and permissions are allowed. Ideally, when Web services are authenticated, they would not authenticate through an existing user profile with potentially broad permissions, but instead, in a way that the service would have limited or no access to protected health information. This would force the Web service to work with information explicitly supplied to the service.

Web services may represent a security risk in the event that (1) the EHR application is redirected to a different Web service with ill intent or (2) the Web service itself is not robust and/or mishandles data. Therefore, the calling application must be able to manage situations in which (1) the Web service tries to perform actions within the calling application that it should not, (2) the Web service corrupts data sent to it, or (3) the Web service returns results that are not valid. EHR applications should provide a limited and protected environment in which they execute Web service code (eg, a sandbox) and the service cannot cause harm resulting in data breaches, impermissible access, or data corruption.

Applications may manage performance of Web services by multitasking when Web services are in use (running them in separate threads or processes), allowing the user to continue with his or her work while awaiting results. Alternately, the Web service could be timed and stopped if it is taking too long.

Health care applications such as EHRs are held to a higher standard than consumer applications. EHRs ensure that the chain of data from entry to storage and retrieval is secure, auditable, and restricted to individuals with appropriate authorization.⁴³  These requirements of ensuring adequate privacy and security protections for protected health information are reinforced by meaningful use criteria.¹ 

Access to and editing of patient information are often restricted by role. Inappropriate chart access may be a terminable offense. Records are to be accessed only by individuals who are authorized by policy, and access to patient charts should be audited. Web services and applications need to preserve these safeguards, including user authentication and authorization, and are not allowed to take shortcuts, such as permitting Web services or applications to use a higher level of privileges than the user.

Audits of who accessed data to determine if access was proper and legal are important. When Web services that access and/or store data are implemented, this access must be recognizably recorded for auditing purposes so that practices can determine if data compromise is a result of data stored by Web services or a breach of security at the practice.

Web services will generate clinical recommendations to clinicians. It is imperative that a Web service delivers what is advertised and expected by the user. Preferable testing approaches would include automatic testing and logging of returned results compared with the expected results for all possible inputs to the Web service. For example, if a Web service input is three-dimensional (age, sex, laboratory value), testing scripts should cover every possible combination of each input parameter or, at a minimum, the most common use cases. Direct usability testing with users, ideally before roll out to inform training efforts, is desirable before any software releases.

As clinical knowledge grows, Web services will require updates and modifications. Other reasons to update a Web service include functionality enhancements, bug fixes, and safety and security enhancements.

Versioning (keeping track of modifications and their implementation) that includes the output created by the Web service is critical. Health care providers are required to practice the standard of care, which develops and changes over time. For medical-legal reasons, it is critical to be able to have a discovery process recreate the output of a Web service at a previous date to demonstrate the adherence to the standards of care at that time. Web services and applications should provide version information, and client software, such as EHRs, should capture this information so that practices can audit and reconstruct which data and rules were being used at different points in time.

With any Web service update, developers are required to provide documentation to prepare users for functionality or output modifications. Web service and application vendors will supply predocumentation of upcoming releases to allow end users to learn about future anticipated behavior of the Web service or application. Ideally, practices and EHR vendors will be allowed to accept or decline the updates. Release dates (and, if applicable, anticipated expiration dates) are obtained to support communication to users.

If an owner of a Web service or application is not willing or able to maintain and update his or her software in response to new knowledge or technology or security issues, the Web service should be explicit about this or should be retired for use.

More sophisticated Web services may return XML outputs that the invoking application can then interpret and/or display. For example, a Google Web service takes a text string representing a location and returns XML that represents that location on a map. A Web service that takes information such as sex, age, and weight could plot those weights and return a personalized growth chart^43,47  that would include likely interpretations for the growth chart (eg, consistent with failure to thrive versus consistent with hypothyroidism). A Web service could take a collection of addresses in a neighborhood of patients exposed to a toxin or infectious disease and return a geographical map with the specified locations highlighted.⁴⁸ 

Web services and cloud computing in health care are near the “peak of inflated expectations” on the hype cycle,⁴⁹  in which many small prototype applications exist that have not been broadly adopted because of underlying infrastructure issues, lack of integration with clinical workflows, and/or lack of perceived impact for cost to integrate. Given the rapid speed at which this field is developing, more Web-based services than are referenced in this document will be developed and marketed to clinicians in practice; thus, this report constitutes some illustrative examples only. It will be important to identify and prioritize needed Web services for the support of pediatrics to facilitate the development of these Web services, to help disseminate these services through either endorsement or integration with implementation tool kits, and to keep these concepts in mind when pediatricians and pediatric practices decide whether to put new Web services into practice.

Michael G. Leu, MD, MS, MHS, FAAP, FAMIA Stuart T. Weinberg, MD, FAAP, FAMIA Craig Monsen, MD, MS Christoph U. Lehmann, MD, FAAP, FACMI, FIAHSI

Emily Chui Webber, MD, FAAP, Chairperson Gregg M. Alexander, DO Eric L. Beyer, MD, FAAP Sandy Lee Chung, MD, FAAP Kevin Dufendach, MD, MS, FAAP Alexander M. Hamling, MD, MBA, FAAP Marvin B. Harper, MD, FAAP Eric S. Kirkendall, MD, MBI, FAAP Eli M. Lourie, MD, MBI, FAAP, FAMIA Ann M. Mann, MD, FAAP Stephen J. Morgan, MD, FAAP Heather C. O’Donnell, MD, FAAP Reza Sadeghian, MD, MBA, MSc, FAAP Eric Shelov, MD, MBI, FAAP Srinivasan Suresh, MD, MBA, FAAP Andrew M. Wiesenthal, MD, SM, FAAP Jeffrey A. Wright, MD, FAAP Stuart T. Weinberg, MD, FAAP, FAMIA – Immediate Past Chairperson

Dale C. Alverson, MD, FAAP – Section on Telehealth Care Francis Dick-Wai Chan, MD, FAAP – Section on Advances in Therapeutics and TechnologyHan Yu (Stephanie) Liou, MD – Section on Pediatric Trainees Melissa S. Van Cain, MD, FAAP – Section on Pediatric Trainees

Lisa Krams, MAHS

We thank Alan E. Zuckerman, MD, FAAP, for his contributions to the technical report.

API

application programming interface

EHR

electronic health record

FHIR

Fast Healthcare Interoperability Resources

HIPAA

Health Insurance Portability and Accountability Act

JSON

JavaScript Object Notation

JSONP

JSON with Padding

LOINC

Logical Observation Identifiers Names and Codes

SMART

Substitutable Medical Applications and Reusable Technologies

SNOMED CT

Systematized Nomenclature of Medicine – Clinical Terms

XML

extensible markup language