XML4Pharma and the SMART Challenge

The US Government regularly publishes challenges, some of them in the area of informatics for healthcare.

One of these is the SMART challenge, challenging people to develop 'apps' using electronic health records (EHRs) from an imaginary hospital (in this case, the 'Childrens Hospital Boston' - CHB). These 'apps' can be embedded in a SMART container, allowing seamless switching between the EHR system of the imaginary hospital and the developer's own application.

For example, an 'app' can take the EHR and, from the lab values for Cholesterol, age, gender, family history and smoking habits, calculate the cardiac risk.

The EHR does NOT come as a CCD HL7-v3 message, nor as an ASTM CCR, nor as an OpenEHR extract, but can be extracted from the hospital system using a REST service. The REST-API has been published by the owners of the hospital system. The result of a request for a medical record of a specific patient is an RDF graph, which can be queried e.g. using the SPARQL quering language.

Our Challenge

As one of the pioneers of the integration between electronic health records and clinical research (see our presentation at the CDISC EU Interchange in April 2009 in Budapest), we could of course not resist accepting this challenge and started developing an 'app' that takes the EHR from a patient and uses that in clinical research, in this case, prefilling a CDASH 'Prior and Concomitant Medications' form.

Imagine the situation that the EHR lists over 60 medications for a specific patient, with dose and frequency information, prescription dates, dispense dates, and when available, date that taking the medication was stopped.
How do you transfer this information to a CDASH 'Prior and Concomitant Medications' Case Report Form (CRF)? Will you, as an investigator really try to type over this information into the CRF?

Our 'app' (work in progress)

This is work in progress, so please bookmark this page, and visit this page regularly.

In our 'app', the user (a hospital physician) first selects a patient in the hospital system

He/she can then click the 'Clinical Research' button on the left, the electronic health record is retrieved and queried, and the information passed to another application (such as an EDC system) which, by virtue of the SMART container, simply runs in the same window. The application that then runs (in the same window) can even run on another server than the EHR system (and will usually do so), but the user does not even notice this (seamless integration).

In our situation, when clicking the 'Clinical Research' button, our (simulated) EDC system takes over, and generates a list of all the medications for which there is information in the EHR, and sorts them by dispense date. The latter is regarded as the date the patient started taking the medication (as the real start date is not in the EHR). This information is then displayed in a tabular way on the screen:

In our case there are 82 medications in the list.
Now, if our patient Brian Diaz in involved in a clinical study, the physician, who is also an investigator, would like to add this information to the 'CDASH Prior and Concomitant Medications' form. Classically, as the EDC system runs on another server than the hospital information system, the investigator would need to type in all the information from the EHR system into the EDC system, using copy and paste, or even making a paper copy of the information first, and then type it in into the EDC system.

After the medication information is retrieved from the hospital system, and listed, an hyperlink is added to the bottom of the list, inviting the investigator to transfer the medication information to the 'CDASH Prior and Concomitant Information' form in the EDC system:

When the investigator now clicks the hyperlink, the medical information is transformed into 'CDASH' information, using CDISC ODM and XForms technology and standards. The 'CDASH Prior and Concomitant Medications' form is automatically prepopulated, with as well subject ID, visit ID, and visit date and time:

For each medication for which there is information in the EHR, a group of fields (according to the CDASH standard) is created and prepopulated. For Brian Diaz (subject 308194), there are 82 such groups, each containing 8 fields. Imagine this information had to be typed over!

The investigator still needs to check the information (as he/she is responsible for the correctness), and can still change some of the details. The 'app' can however also be designed so that some of the information cannot be edited anymore. As the 'app' uses XForms technology, the form is fully dynamic. For example, if for "Is medication still continueing?" is set to "Yes", then the "Stop Date" field will disappear.

When coming at the end of the form (well, a long list indeed), and all the information is accurate and correct (it should be if the EHR was correct), the investigator can then use the "Submit" button to submit the data to the EDC system:

The data is then submitted to the EDC system. For demo purposes, we added the feature that the submitted information is also exported into CDISC ODM 1.3 format, wich is shown in the lower part of the screen:

At the same time, a PDF is generated for the investigator tabulating all the information that has been submitted. This can be used for the investigator's own archive.
It is displayed in the upper part of the screen, and can be saved to file by the investigator. The EDC system however also archives a copy.

Remark that, as this PDF file is generated on the fly, it can have any form, including one that looks very similar to what was visible on the computer's screen. For demo purposes however, we chose to use a tabular view, displaying as well the coded as decoded values for those items for which there was an enumeration.

Let us now go back to the starting screen: It can be that the patient is not eligible for the clinical study, as e.g. the patient is too young. Usually a clinical study contains a set of 'eligibility criteria' (also named 'inclusion-exclusion criteria'). In our study, these criteria are (WORK IN PROGRESS):

For example, patient Carl Moore is only 7 years old, and is thus not eligible for this study. The electronic medical records does not contain the age (as age can change from one day to the next), but contains the birth date. So our 'app' calculates the age from the current date and the birth date and displays this at the top. In case the patient is less than 18 years old, the 'Prior and Concomitant Medications' form is not generated and thus not presented to the user. Instead, a message appears after the list of medications that the patient is not eligible for this study.

Patient Barbara Hill has suffered depression problems, and is therefore excluded from the study. A table is displayed with the medical problems that have led to exclusion from the study: the SNOMED code is given together with a description, the onset date, and if known, also the resolution date:

To do

We want to further extend this 'app'. We recently extended it with the possibility to also prepopulate the CDASH 'Demographics' (DM) form. Other features we are thinking about is to take the demography information, together with the list of diseases, and use that for selecting patients to take part in the study using eligibility criteria. The 'app' can then generate an "informed consent" form (in PDF) which can be electronically signed (e.g. using CoSign technology).

At the moment however, we can limit ourselves to use the elibility criteria to allow access to the CRF for entering data.

Advantages of the 'app' approach

The great advantage of the 'app' approach is that the user (the physician) can immediately switch to another application that does something different with the EHR of the same patient. For example, the user can just click the 'Cardiac Risk' button on the left part of the screen and then immediately gets a calculated value of the cardiac risk, based on age, cholesterol levels (from the lab data), whether the patient is a smoker, etc..
Please remark that this 'app' is from another author (so not ours).

Another advantage is that the user can always add new 'apps' and remove others from his list of 'apps'

Conclusion

Although the automatic prepopulation of CRFs from EHR data has been demonstrated before, the nice thing about the SMART system and its container, is that different applications ('apps'), can run within the same window/container (even when they essentially run on different servers). The user even doesn't notice that it is running on a different server!
Currently, our 'app' used four different web applications running on two different servers (it could however be four):

As demonstrated here, such a prepopulation of CRFs saves an enormous amount of time. Again, imagine the investigator had to type in this information for these medications!

The other advantage is in data quality. If at least the information in the EHR was correct, the information in the EDC system will also be correct. If the investigator had to type over the information, how many errors would then have been made?

Last and not least, the SMART system uses a new paradigm, thus avoiding the 'EHR Standards Jungle'. It exposes a REST (web)service interface to the developer, which produces RDF that can be queried by the 'app'. As such, it is "EHR-standards-independent" and thus also vendor-neutral.


Home	Services	CDISC	Software	About us