View source for Providing Interoperability to a Pervasive Healthcare System Through the HL7 CDA Standard

== Introduction ==
The authors begin by defining "pervasive healthcare" and "pervasive healthcare systems" (PHS), describing it as a model of healthcare delivery that relies on "ubiquitous computing technology" to deliver healthcare outside its traditional constraints and taking a patient-centered approach<ref name=origpaper>Brugués, A., Bromuri, S., Pegueroles, J., & Schumacher, M. (2015). Providing Interoperability to a Pervasive Healthcare System Through the HL7 CDA Standard. <i>15th International HL7 Interoperability Conference Proceedings</i>, 5-12. Retrieved October 1, 2015, from http://ihic2015.hl7cr.eu/Proceedings-web.pdf</ref>. They note that the technology brings challenges of "interoperability, scalability and security"; the authors of this paper focus primarily on the challenge of [[interoperability]], examining the case of the application Gestational Diabetes Mellitus Management System (GDDMS). The application is "a PHS based on multiagent systems to continuously monitor women affected by Gestational Diabetes Mellitus (GDM)". The authors developed an implementation of the HL7 CDA (Clinical Document Architecture) standard to provide interoperability for this application, and conclude that their methods could be used for other PHS applications to achieve interoperability.

=== GDMMS Pervasive Healthcare System ===
The GDMMS application runs on Android phones; the patient with the phone can enter information about their condition such as symptoms and readings. The section goes into some technical detail about the application's architecture, covering security layers, load balancers, communications protocols, and so forth.

== Interoperability in the GDMMS ==
This section specifies which medical data elements are handled by the application; the authors note that they have built the communication channel from the phone to the server by implementing the CDA document standard to encapsulate the data. They include UML diagrams and XML samples to demonstrate how the data is represented by the application. 

=== CDA Header ===
The CDA Header section describes how the data schema is defined in the XML document. It describes how each node in the XML schema is used by the specification, including LOINC codes that specify what type of information is being presented.

=== CDA Body === 
The body section describes how the data values that fall under the above header items are represented.

==== Physiological Parameters ====
This section describes the XML mapping and the SNOMED CT codes that are used to define the data values represented, as well as their display names. The values include blood pressure, heart rate, blood sugar, and weight. Measurement timestamps and unit denominators are included where appropriate.

==== Symptoms ====
Symptoms are represented using ICD-10 coding. Timestamps are again included.

==== Medications ====
ATC<ref name=ATC>https://en.wikipedia.org/wiki/Anatomical_Therapeutic_Chemical_Classification_System</ref> codes are used to represent medications used to control the diabetic symptoms; their use in the application is explained similarly to the above sections. The authors explain that they had to define a data element to describe the dose actually taken vs the dose prescribed because diabetes is a patient-managed disease; they explain that their use of the locally-defined element is within the scope of the specification.
== Discussion ==
The authors note that the use of the locally-defined schema element does have an impact on interoperability; each system consuming the data must be validated for use with the data. The authors note that the CDA specification facilitates this effort, but the method of facilitation is not discussed.

The discussion also covers the authors' literature search; they describe related work done by others in the realm of pervasive healthcare. The paper cites work done with home health care applications and Alzheimer's care. In the Alzheimer's setting, they describe a "smart home" setup that incorporates sensor data into the messages sent to the PHS, not only patient-entered data as in the case of the GDMMS. Another paper cited describes a system for heart monitoring, using sensors, that would convey data automatically to a healthcare provider. The emphasis of the discussion is on the value of CDA for interoperability.

The authors also consider PHMR, the Personal Healthcare Monitoring Record, which is "an implementation guide for the CDA which constrains the elements of the CDA header and body". PHMR is designed to support the integration of sensor and other objective data into the CDA model, but the authors contrast with this noting that their model uses subjective data (symptoms) and therefore cannot be represented in the constrained model.

== Conclusions and Future Work ==
The authors note that the papers they found in their literature search did not focus on interoperability, while they went into some depth to describe how their application was implemented to provide for interoperability. They believe that the CDA should be extended to include elements such as their locally-defined "dose administered" field to improve interoperability.

== My Impressions ==

This was an interesting paper to read. It gives a sense of the importance of a standard like CDA for interoperability, and goes into some depth about how this is achieved. I was disappointed, however, that they did not go into detail about how the CDA can be used to facilitate validation when the XML schema has local modifications; it would seem that the authors assume too much about the knowledge of their readership.

== Related Articles ==
*[[A Framework to Assist Health Professionals in Recommending High-Quality Apps for Supporting Chronic Disease Self-Management: Illustrative Assessment of Type 2 Diabetes Apps]]

== References ==
<references/>

[[Category:Reviews]]
[[Category:Interoperability]]
[[Category:Technologies]]
[[Category:Terminology and Coding]]
[[Category:MHealth]]