Channels ▼


Healthcare Information Integration

Kristina M. Kermanshahche is Chief Architect for Intel's Digital Health Group.

Simple interventions can save lives and reduce the cost of healthcare. Home care for patients with co-morbidities can mean the difference between life and death. For example, with ongoing monitoring of vital signs, patient condition, and medication levels, sudden changes outside of the patient's established thresholds can be detected, which can mean the difference between extended hospitalization and rapid decline in health, versus maintaining a quality of life in the patient's home, surrounded by family and friends.

Similarly, maintaining tight control over blood glucose levels during gestational diabetes can mean the difference between premature birth with a whole host of medical complications for both mother and child, versus a stable healthy maternity and normal delivery.

Remote patient monitoring (RPM) can be significant to both examples just cited, and the effectiveness of RPM depends directly on the availability of standardized information from a variety of health-care data sources, including patient health summary, prescriptions, lab results, daily vital signs collection, and functional assessments.

Remote Patient Monitoring Use Case

In this section we discuss a typical Remote Patient Monitoring (RPM) use case, to set the context for applying health-care informatics standards and to explain how subtle nuances in clinical workflow and system interactions can have a profound impact, both on the design of the end-to-end information integration as well as on future enhancements to informatics standards.

Figure 1 was adapted from the HITSP RMON Business Use Case [6], representing a superset of actors, steps, and functionality across a number of finer-grained but related use cases. We currently work with clinicians in a variety of regions worldwide but primarily based in the United States and the United Kingdom. Clinical delivery and reimbursement models are very different between these two regions. Some health-care delivery models rely upon visiting nurses, community outreach, and clinical call centers to perform primary patient engagement, monitoring patients remotely and within the home, and only referring the most acute cases for physician or hospital intervention.

Figure 1: RPM Sequence Diagram (Source: Intel Corporation, 2009. Adapted from HITSP RMON Business Sequence Diagrams [6])

Other delivery models rely upon physician practices to monitor patients directly, at times delegating these tasks to trained staff that operate as part of the practice under their clinical supervision. These two models exist in both regions regardless of patient acuity, frequency of monitoring, or reimbursement models. (In the health-care context, patient acuity refers to the type and severity of illness, with acutely ill patients requiring emergency care.) It is important that use cases and the supporting informatics standards comprehend these types of variation in order to deliver an effective RPM solution.

Figure 1 represents three primary actors of concern -- the Patient, the Remote Monitoring Management System (RMMS) that operates the RPM solution, and an external Electronic Health Record (EHR) system, which might represent anything from a clinical electronic medical record system to a purpose-built system developed specifically for chronic disease management (CDM) or home health monitoring. The primary monitoring of a Patient's wellbeing by a Clinician can occur either within the RMMS itself or by extension, from within the EHR system. The sequence diagram is triggered by the event of patient data collection, including vital signs and assessments defined by a Treatment Plan, which specifies not only what data to collect but also the frequency and schedule.

Typical patients are asked to collect vital signs anywhere from one to four times per day (an average of eight vital sign readings per day), ranging anywhere from three to seven days per week. Patients work with a variety of peripheral device types including blood pressure cuff, glucose meters, weight scales, and pulse oximeters. Vital sign measurements are combined with assessment questions that are geared to assess patient adherence to the treatment plan, functional status, and coping mechanisms with regard to their specific set of co-morbidities, such as congestive heart failure, diabetes, and chronic obstructive pulmonary disease (COPD).

Once the RMMS aggregates the vital sign and assessment data, it compares the values against a pre-established reference range or threshold to identify those readings that are out of normal range. Optionally, alerts and notifications may be generated to the EHR system and members of the clinical team, notifying them of the abnormal readings. Next, both normal and out-of-range information is transmitted to the EHR system, either in raw or summary format. The clinician reviews the information, makes clinical notes, and as needed, generates referrals and modifies the Treatment Plan. The updated Treatment Plan is transmitted to the RMMS and subsequently communicated to the Patient and the patient-local devices.

The significance of the use case and sequence diagram just described are as follows:

  • There is a high degree of variability in where patient data are maintained. The clinician and clinical support team review and annotate patient information in multiple systems of record. The RMMS is generally deployed in addition to multiple legacy systems used to manage patient healthcare, and typically, little to no integration exists.
  • Some healthcare use cases and informatics standards assume that a clinician event is responsible for triggering the transfer of information from one clinical team to the next; however, this use case underscores several examples where data transmission is triggered instead by system events, and it is important for informatics standards to comprehend both scenarios.
  • The type, frequency, and schedule of the information collected is also highly variable, which must be comprehended by informatics and system deployment designs alike. The more standardized the information, the more it will drive machine computability, advanced analytics, and improved healthcare at lower costs. However, informatics standards must always balance the goal of perfect information requiring every data element, with a pragmatic approach to incremental adoption, relying instead on implementations to deliver best effort results in populating standard data elements with carefully designed constraints.
  • A consistent, appropriately encoded specification of the treatment plan is just as important as the data collection itself. Initial focus is rightfully on capturing and transmitting RPM data, yet to truly measure patient adherence and prognosis over time, we also need a consistent method to specify the treatment plan in a semantically meaningful way.

Figure 2 reveals several additional deployment considerations with respect to RPM. Step 1 represents the transmission of patient session data to the RMMS. The RMMS aggregates trend information, compares vital signs against reference ranges, and generates alerts and notifications. It has its own data repository, consisting of historical patient treatment plans, reference ranges, clinical notes, patient monitoring data, and customer-specific configuration information. The RMMS is necessarily designed to be an online transaction processing (OLTP) system, since its primary goal is to drive RPM in a high-performance, transaction-oriented manner.

Figure 2: RPM Interaction Diagram (Source: Intel Corporation, 2009)

Optionally, Step 2 and 3 depict a Care Manager who reviews the Patient's status from within the RMMS. The Care Manager may modify the Treatment Plan directly, or annotate the record and refer to a Clinician for review and follow-up. The Care Manager may also play a key role in assessing the viability of the data collected prior to escalation. For example, in the case of a very low weight reading generating an alert, the Care Manager might confirm that the Patient's grandson had in fact triggered the scale.

Step 4 represents some form of data synchronization between the RMMS and the Integration Services environment. The primary goal of the Integration Services environment is rapid query, retrieval, translation, transformation, and guaranteed delivery (push/pull) of health-care information between a number of participating entities (Step 5). Integration Services, therefore, are commonly a mix of online analytic processing (OLAP) combined with logical mechanisms of extract, transform, and load (ETL). Trend analysis and summarization may also be performed at this stage. The Integration Services environment is best developed according to SOA principles, largely due to the complexity and number of end points, the variability of legacy and standard interfaces, and the number of different workflows and external services required. We discuss the rationale and benefits of applying SOA to RPM in more detail later. The mechanism of data synchronization depends upon patient acuity, data latency, and a number of other considerations, also discussed later in this article.

As a part of the transformation that occurs in Step 5, multiple calls may be made to services across the Internet (Steps 6 and 7) in order to complete the health-care dataset, including identity match; terminology encoding; record locate; patient consent; or data enrichment, incorporating the latest lab results, prescription history, or drug-to-drug interaction checks.

Finally, the RPM information is transmitted to the EHR (Step 8), where it is reviewed and annotated by the Clinician (Step 9). Note that many providers will require manual review of the data for clinical accuracy prior to committing it to the EHR. This review requirement poses significant workload and process implications to the future viability of RPM, discussed in more depth later.

The Clinician enters modifications to the Treatment Plan and generates requests for consultation (Step 10). Changes to the Treatment Plan are returned to the RMMS (Step 11) and transmitted to the patient-local devices (Step 12). The inbound data flows undergo similar decomposition and transformation as outbound flows (Steps 5-7), remapping identity and terminology to local code sets.

System designers should anticipate the need to support a large number of end points with a high complexity and variability of transforms (e.g., HL7 v2.x, HL7 v3, proprietary XML, proprietary delimited files) and translations (e.g., SNOMED CT, LOINC, RxNORM, ICD9/10) required across an array of different transport protocols (e.g., SOAP over HTTPS, SFTP, MLLP, and proprietary sockets). A powerful approach is the implementation of the HL7 v3 CDA [4] in the Integration Services environment (Step 5) as a normalized view of RPM information, leveraging the full richness of the HL7 v3 Reference Information Model (RIM). The CDA becomes in effect a Rosetta Stone, making the subsequent translation to legacy, proprietary, and standards-based systems predictable, reliable, and semantically correct. The incremental adoption model inherent in CDA ensures the relative ease with which we can populate optional segments with new information, such as Plan of Care, while the SDOs work through the optimal encoding scheme. It also ensures straightforward compliance with new CDA document types, such as the Continua Health Alliance Personal Health Monitoring (PHM) Report [3], as a minor transform from the baseline CDA.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags


<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags


<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

