Web Services is one of these technical terms than many folk have heard of, some people understand, and a very few people can actually use. The definition of a Web Service from a technical perspective – courtesy of Wikipedia - is "a software system designed to support interoperable machine-to-machine interaction over a network.
From an eClinical perspective, Web Services allow disparate eClinical systems to communicate on a (near) real-time basis.
I believe that Web Services will help resolve many of the integration issues that eClinical systems suffer from today. You can procedure 2 great systems, but if they don’t speak properly together at lot of business value is lost. Combining CDISC with Web Services may well be a solution to many problems encountered.
Web Services – the Basics
Technologies similar to web services have been around for many many years. For example, when you visit an autoteller, put your Visa card in the slot to withdrawn cash, a Web Service ‘type’ of communication goes on between the bank you communicate with and the Credit Card company actually releasing the funds. What they actually say when such communications occur will of course differ depending on application, but, with Web Services, the way they say it is standardized.
Web Services have evolved into many different things, but, the underlying principles remain the same. Generally, they communicate using XML (Extensible Markup Language) based text over a Protocol called SOAP.
Many folk will be familiar with XML already – CDISC ODM is build around XML as a means to give meaning to clinical data that is transferred. SOAP though may be new term. SOAP, put simply provides a means to transfer – typically over the Internet, XML messages from system to system over firewall friendly channels (or Ports).
When you open up a browser, and enter something like http://www.google.com/ what you are actually doing is asking to communicate with google on internet port ’80’. The http equates to Port 80. You might also see https. The ‘s’ part signifies ‘secure’ and indicates the use of Port 443 (known as SSL). Many corporate and site networks place restrictions on the ports that are open to the internet. Ports 80 and 443 are some of the few ports almost always open, and therefore usable for communication. SOAP can use both these ports. Therefore, web services running on SOAP can speak between systems, avoiding firewall conflicts. This means that if you want System A to speak to System B via Web Services, all you need to do is ensure that an Internet link is available, and you’re off and running.
CDISC & eClinical before Web Services
So, what about Web Services, CDISC and eClinical. Why should I care?
Well, traditionally, eClinical systems have been relatively ‘dumb’ when it has come to communicating. An IVR system would be used to capture the recruitment, or randomization of a subject. The IVR would then send a Text file via old fashioned FTP file transfer to an EDC system, and the EDC system would – at some time in the future – process the text file – creating a new subject, or recording the randomization in the EDC system tables. Sounds ok… but.. what if things go wrong?
With this model, the EDC and IVR systems don’t really speak to each other. The IVR system sends something – yes, but if the EDC system doesn’t like it – then oops! The IVR will keep sending things regardless. That is one issue. The second issue is that because the two systems don’t actively communicate, they cannot cross check (or Handshake) with each other. Imagine if the EDC system held information that the IVR did not. Lets say for instance that the investigator recorded in the EDC system that the subject had dropped out. If the investigator later used the IVR to possibly then Randomize this same patient the IVR could check against the EDC system that the subject was valid and current. Maybe not a perfect example, but, the capability exists.
Web Services provides the mechanism for system A to speak with system B. CDISC ODM provides the syntax with which to communicate. When both systems make reference to a ‘FORM’, both systems know what is meant.
Web Services – eClinical – so…
In traditional systems design, you had a decision to make when you developed new modules of software as part of a suite of applications. Do I store database information in the same place – sharing a common database, or, do I store it in a separate database and communication / synchronize between the two systems. If you stored everything in the same database – you simplified the table structure, and didn’t need to worry about data replication, but, systems were tied together. If you separated the databases, then of course you had duplicate data between the databases, and you had to replicate. This replication was complicated and problematic.
Ok, now lets imagine that the systems come from different vendors. Of course each vendor wants to sell their own system independently – a separate database is mandatory. They hold common information…. no problem, we write interfaces.
Complicated software is designed to examine information that is common between systems, and transfer this by batch transfer. So, for example, we have a list of Sites in System A – we also have a list of Sites in System B. We have a list of site personnel in system A, we also have a list of site personnel in system B – no problem I hear you say. Lets imagine that System A doesn’t fully audit trail the information that has changed on the Site’s tables. How would System B know what to take…. we need to transfer all the sites, and compare the site information with the previous site information… getting tricky…and this is just a simple list of sites.
Now, lets imagine a more complicated situation, common in an eClinical system. A Protocol amendment occurs, a new arm has been added to a study whereby subjects meeting particular criteria are branched into two separate dosing schemes.
Transferring or Synchronizing this sort of information between 2 systems would be possible, but very very difficult. System A may not have a good place to the put the information from System B. The question is though – do both systems really need the same data? If System B wants to know something, why doesn’t it just ask System A at the time it needs the answer, instead of storing all the same data itself?
This is where Web Services can come in.
Lets imagine an IVR system wanted to check with an EDC system if a subject was current in a study (current meaning not dropped out, early terminated or a screen failure). A Web Service could be offered by the EDC system to respond with a ‘True’ or ‘False’ to a call ‘IS_SUBJECT_CURRENT’ ? Of course hand-shaking would need to occur before it hand for security and so on, but following this, the IVR system would simply need to make the call, provide a unique Subject identifier, and the EDC system web service would respond with either ‘True’ or ‘False. With Web Services, this can potentially occur in less than a second.
Lets take this one step further. The EDC system would like to record a subject randomization. The site personnel enter all the key information into the EDC system. The EDC system then makes a Web Service call to the IVR system – passing all of the necessary details. The IVR takes these details, checks them, and if valid, returns the appropriate subject randomization no.. The EDC system presents the Randomization No. for the subject on the eCRF for the site personnel to use. This all happens realtime, and via web service calls in systems located in completely different locations.
Web Services - Metadata independence
Web Services are significant for a number of reasons. Yes, they allow systems to communicate in a near real-time basis over the internet – that’s quite cool in itself. What’s more significant though in terms of eClinical systems is that Systems A and B don’t really need to understand how the other systems do what they do.
If System A had to read the database of System B, it would need to understand how System B actually used the data in the database. The same applies to an interface. If System A received data from System B, it needs to process that data with an understanding of how System B works before it could use it, or potentially update it.
Web Services – beyond CDISC?
CDISC ODM allows you to transfer data, and to some extent metadata from one system to another. To ensure it works for all, the support is to some extent, the ‘lowest common denominator’ of metadata. It is only really able to describe data that is common and understandable to every other system – (barring extensions – see eClinicalOpinion on these).
Imagine if we could create a common set of Web Service calls. The common calls would take certain parameters, and, return a potential set of responses. The Messaging might be based on CDISC ODM, but the actions would be new and common.
- Add_Subject(Study, Site, SubjectId) returns ScreeningNo
- Add_DataValue(Study, Site, Subject, Visit….) returns Success, QueryResponse
- Read_DataValue(Study, Site, Subject, Visit….) returns DataValue,QueryResponse, DataStatus
With this sort of mechanism, the degree of processing of data and metadata between systems is limited. The ‘owning’ system does all the work. The data and metadata that the systems need, stay with the original system.
One remaining challenge exists – the common indexing of information – if a data value is targeted towards a particular site, subject, Visit, Page and Line, then they all must be known and specified. That said, a bit of business logic (protocol knowledge) can be applied. For example, if a DBP is captured for a subject, and the target study only has one reference to DBP for a subject in the whole CRF, should I really need to specify the Visit, Page and Instance? Sufficient uniqueness rules could apply.
If CDISC were to create a standard set of InBound and OutBound Web Service calls, you would see a great simplification in how normally disconnected systems inter-operate. Not only could we send data from System A to System B, we could appreciate what happens when it gets there – ‘Can I login’, ‘Did that Verbatim Code?’ ‘Can I have lab data for subject x’… etc etc.
Will Web Services technologies change the eClinical landscape? No. But, technology advances such as these all help to make the whole eClinical process somewhat less complicated.