US20130346107A1 - Mobile clinical research associate framework for offline capability - Google Patents

Mobile clinical research associate framework for offline capability Download PDF

Info

Publication number
US20130346107A1
US20130346107A1 US13/827,073 US201313827073A US2013346107A1 US 20130346107 A1 US20130346107 A1 US 20130346107A1 US 201313827073 A US201313827073 A US 201313827073A US 2013346107 A1 US2013346107 A1 US 2013346107A1
Authority
US
United States
Prior art keywords
trip report
skeleton
trip
mobile device
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/827,073
Other languages
English (en)
Inventor
Matthew LYNES
Victor MATSKIV
Jayant Thomas
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oracle International Corp
Original Assignee
Oracle International Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oracle International Corp filed Critical Oracle International Corp
Priority to US13/827,073 priority Critical patent/US20130346107A1/en
Assigned to ORACLE INTERNATIONAL CORPORATION reassignment ORACLE INTERNATIONAL CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: THOMAS, JAYANT, LYNES, Matthew, MATSKIV, Victor
Priority to JP2015518406A priority patent/JP6261573B2/ja
Priority to CN201380030137.5A priority patent/CN104335212B/zh
Priority to EP13728269.5A priority patent/EP2864950A4/en
Priority to PCT/US2013/041096 priority patent/WO2013191824A2/en
Publication of US20130346107A1 publication Critical patent/US20130346107A1/en
Priority to US16/810,066 priority patent/US11693882B2/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • G06F19/36—
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/20—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for electronic clinical trials or questionnaires
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/273—Asynchronous replication or reconciliation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H15/00—ICT specially adapted for medical reports, e.g. generation or transmission thereof

Definitions

  • Clinical trials are sets of tests in medical research and drug development that generate safety and efficacy data, such as information about adverse drug reactions and adverse effects of treatments for health interventions (e.g., drugs, diagnostics, devices, therapy protocols). Furthermore, information about the design of the clinical study, such as information about drugs, diagnostics, devices and protocols may also be included.
  • safety and efficacy data such as information about adverse drug reactions and adverse effects of treatments for health interventions (e.g., drugs, diagnostics, devices, therapy protocols).
  • health interventions e.g., drugs, diagnostics, devices, therapy protocols.
  • information about the design of the clinical study such as information about drugs, diagnostics, devices and protocols may also be included.
  • trip reports stores information regarding a clinical study. Therefore, trip reports are highly customizable and include significant data. It is desirable to edit and display the trip report on a mobile device without having to customize the interface with the mobile device or having to repeatedly access the remote server. Likewise, it is difficult to standardize trip reports due to the interaction of the business components and the trip report web service.
  • FIG. 1 illustrates one embodiment of a method associated with a clinical research associate (CRA) framework for offline capability.
  • CRA clinical research associate
  • FIG. 2 illustrates another embodiment of a method associated with a CRA framework for offline capability.
  • FIG. 3 illustrates another embodiment of a system associated with a CRA framework for offline capability.
  • FIG. 4 illustrates another embodiment of a system associated with a CRA framework for offline capability.
  • FIG. 5 illustrates an embodiment of a computing system in which example systems and methods, and equivalents, may operate.
  • the CRA application framework provides a generic way to encrypt and cache data using declarative tags to databases and file systems on a mobile device. Using declarative programming minimizes the amount of coding required to enable the CRA application framework.
  • the CRA application framework allows users to cache offline data, enables downloading of data to a mobile device, and operate the mobile device while offline.
  • the CRA application framework performs trip report related activities. Creating a trip report is one of the most resource intensive operations. Typically, a thread processing the request to create a trip report would then generate the trip report. To reduce the amount of strain put on the CRA application framework, the activities related to the trip report are performed asynchronously. Accordingly different threads process the request to create the trip report and generate the trip report. By separating the resource intensive operations into separate threads the CRA application framework achieves better control over the server resources, allows for greater scalability, and makes the system more reliable.
  • FIG. 1 illustrates an example embodiment of a method associated with a CRA application framework with offline capability.
  • the method 100 is performed in a CRA application framework used for managing data from clinical studies.
  • the CRA application framework facilitates communication between mobile devices and a server.
  • a user visiting a clinical setting has a mobile device that is used to store and manage data about their trip to the clinic. To ensure the desired data is acquired, the user enters the trip report data into predefined spaces in a trip report skeleton.
  • a creation request to create a trip report skeleton is sent from the mobile device to a server which processes the request in a first thread at 110 .
  • the creation request is acknowledged by the server.
  • the trip report skeleton is created in a second thread on the server. To better distribute server resources, the first thread operated asynchronously from the second thread.
  • the mobile device issues a fetch request to retrieve the created trip report skeleton. Because the first thread and the second thread operate asynchronously, the trip report skeleton may not be ready when the trip report skeleton is requested.
  • the mobile device issues a subsequent fetch request to retrieve the trip report skeleton.
  • the timing of sending additional fetch requests may comply with a predetermined schedule. Alternatively additional fetch requests may be sent as soon as the fetch request times out at 160 or after a predetermined amount of time elapses after the fetch request times out at 160 .
  • the method 100 then returns to step 150 to determine whether the trip report is ready to be sent to the mobile device.
  • the method 100 proceeds to step 180 where the trip report skeleton is received by the mobile device.
  • the mobile device receives the trip report skeleton as a Self Describing Object (SDO).
  • SDO Self Describing Object
  • the clinical data can be entered into the SDO on the mobile device.
  • the SDO contains metadata that enables the mobile device to render the trip report skeleton on the mobile device. Therefore, the mobile device does not need to access a remote server when data is being entered into the trip report skeleton. This reduces the number of times that the mobile device has to access the remote server.
  • FIG. 2 illustrates an embodiment of a method associated with a CRA application framework with offline capability.
  • the trip report skeleton is generated as a Self Describing Object (SDO).
  • SDO Self Describing Object
  • One advantage of the trip report skeleton being in an SDO format is that generic tools can be used to manipulate trip report data. Self-describing data contains the information that tools need to manipulate various types of data correctly.
  • Another advantage of the trip report skeleton being in an SDO format is that it makes the CRA application framework more robust and flexible. Multiple programs running on different devices (e.g., mobile device, server) may interface to a single program despite differences in where the different devices place trip report data.
  • Metadata is created for rendering a trip report on a mobile device and stored on a server.
  • the stored metadata is combined with a canonical trip report to create a skeleton trip report in an SDO format.
  • the skeleton trip report is fetched by the mobile device.
  • the mobile device renders the skeleton trip report based on the embedded metadata.
  • trip report data is entered in the skeleton trip report. Because the trip report skeleton is maintained on the mobile device as an SDO, data is entered by the mobile device into the skeleton trip report regardless of whether the server has immediate access to the data. Data can be entered when the mobile device is offline (i.e., disconnected from the server).
  • the completed trip report is sent back to the server to be stored.
  • the device parameters may include completing the trip report skeleton with a predetermined percentage of trip report data.
  • the device parameters may be a function of the relationship between the mobile device and the server.
  • the completed trip report may be sent to the logic when a network link is established between the mobile device and the server.
  • FIG. 3 illustrates one example embodiment of a system associated with a CRA application framework with offline capability.
  • Trip reports are heavily customized. Customizing the trip report changes the underlying data structure, related clinical components, and the trip report web service that facilitates communication between a server side logic 310 and a mobile device 350 .
  • the server side logic 310 and the mobile device 350 communicate trip report data using a CRA application framework 300 .
  • the server side logic 310 stores a canonical trip report 320 and metadata 330 .
  • the canonical trip report 320 is a generalized structure that is linked to a custom trip report. Therefore, a custom trip report may be highly customized making the custom trip report form inappropriate for distribution to multiple users.
  • the canonical trip report 320 is generalized so that the canonical trip report 320 can be distributed to a number of users for a number of trips even when the users are employing different mobile devices.
  • the metadata 330 is used to render (e.g., individual screen rendering, individual field rendering and validation, screen transitions, and handling data change events) the canonical trip report 320 on the mobile device 350 .
  • the canonical trip report 320 supports custom activity attributes (e.g., checklist functionality).
  • the metadata 330 renders the custom activity attributes on the mobile device 350 .
  • the metadata 330 is generated and stored on the server side logic 310 by an administrator. Once the metadata is stored, any number of mobile devices, like the mobile device 350 can use the metadata for rendering.
  • the creation request sent by a mobile device may include device data such as a mobile device identifier so that the correct metadata for a mobile device is known.
  • the canonical trip report 320 and the metadata 330 are combined by an SDO transformer 315 on the server side logic 310 to create a trip report skeleton 340 .
  • the trip report skeleton 340 is a Self Describing Object (SDO).
  • SDOs like the canonical trip report 320 , are defined in an object oriented computer programming language (e.g., JAVA).
  • JAVA object oriented computer programming language
  • the trip report skeleton 340 is an SDO that is a plain Java object, structured in a JavaScript Object Notation (JSON) for Java to JSON deserialization.
  • JSON JavaScript Object Notation
  • the canonical trip report 320 uses classes that contain special annotations to facilitate use of XML serialization.
  • SDO classes are structurally similar to canonical trip report classes.
  • the difference between the canonical trip report 320 and the trip report skeleton 340 is that the trip report skeleton 340 is in an SDO format and additionally contains metadata 330 .
  • the server side logic 310 also provides application programming interfaces (APIs) for the mobile device 350 to load and synchronize the trip report skeleton 340 .
  • APIs application programming interfaces
  • the SDO transformer 315 also reverses the conversion from trip report skeleton 340 back to a canonical trip report 320 .
  • Some of the features of a custom trip report may be lost when the custom trip report is converted to a canonical trip report 320 . Accordingly the conversion of the custom trip report to the canonical trip report 320 is considered “lossy.” However, information lost during the conversion from the custom trip report to the canonical trip report 320 is restored during the reverse conversion.
  • the server side logic 310 persists the custom trip report by saving the custom trip report. When the server side logic receives a trip report skeleton 340 with information about a trip, the resulting modified trip report skeleton is merged with the custom trip report during the reverse conversion. Accordingly, the trip report data lost by using a trip report skeleton can be restored.
  • FIG. 4 illustrates another example embodiment of a system associated with a CRA application framework with offline capability.
  • the mobile device 350 has received the trip report skeleton 360 .
  • the mobile device 350 may receive the trip report skeleton 360 in the manner described with respect to FIG. 1 .
  • the mobile device 350 inputs the trip report data 370 and stores the trip report data 370 locally in the trip report skeleton 360 on the mobile device 350 of the CRA application framework system 300 .
  • the trip report skeleton 360 is an SDO that is deserialised into a generic recursive dictionary/array structure.
  • a rendering logic 375 renders the trip report skeleton 360 based on the metadata included in the trip report skeleton 360 .
  • the trip report data 370 can be manipulated regardless of whether the mobile device 350 is connected to a network, disconnected, or the connection is intermittent.
  • the trip report skeleton 360 including the trip report data 370 can be sent back to the server side logic 310 . Therefore, the network interactions are minimized because the trip report data 370 can be manipulated on the mobile device 350 and sent when it is convenient.
  • the trip report skeleton 360 is stored locally on the mobile device 350 using a persistence stack 380 .
  • the persistence stack 380 performs encryption of the trip report data 370 on the mobile device 350 .
  • the persistence stack 380 also stores and retrieves trip report skeletons 360 , tracks changes to the trip report data 370 , and performs updates.
  • the persistence stack 380 includes a persistent context 385 , a persistent model 390 , and a persistent store 395 .
  • the persistent context 385 registers objects, such as the trip report skeleton 360 which is an SDO, by associating objects with a unique key.
  • objects such as the trip report skeleton 360 which is an SDO
  • the persistent context 385 may assign a unique key to the object using a persistent context delegate method.
  • the persistent context 385 also tracks changes occurring in the trip report skeleton 360 by assessing the trip report skeleton 360 to be in a dirty state when the persistence stack 380 detects that the trip report data 370 has been changed. If the trip report skeleton 360 is deemed dirty, an update action is scheduled for the trip report data 370 . The update action causes the flagged trip report skeleton 360 to be saved to the persistence context 385 thereby saving the trip report data 370 . If the trip report skeleton 360 is still dirty, the update is finalized resulting in the “dirty” flag being cleared.
  • the persistent context 385 detects changes in the trip report skeleton 360 in response to a number of events (e.g., a change being made, initialization). For example upon initialization, the persistence context 380 verifies whether any of the managed trip report skeletons 360 are in a dirty state. If a trip report skeleton, such as trip report skeleton 360 , is dirty, the persistence context 380 determines that an update operation was not completed, and the persistence context 380 subsequently reschedules the update operation for the trip report skeleton.
  • a trip report skeleton such as trip report skeleton 360
  • the persistent model 390 provides in memory collection of the trip report data 370 .
  • the persistent model 390 also loads previously persisted trip report skeletons from the persistent context.
  • the persistent model 390 will not update earlier persisted items in the dirty state or objects with a timestamp greater than the timestamp of the incoming trip report data 370 .
  • the persistent store 395 saves the trip report skeletons like the trip report skeleton 360 .
  • the persistent store 395 also encrypts and decrypts trip report data 370 .
  • the CRA application framework 300 enables ease of caching offline data using declarative programming and enables a user to download data to the mobile device 350 and manage the data while offline.
  • the system caches the data on the mobile device and monitors the lifecycle of the cached data and provides dynamic synchronization capabilities.
  • the system provides widgets that are configured to display the cached data in various formats using declarative programming.
  • the system enables sensitive data to be HIPPA and CFR part 11 compliant using settings.
  • the described methods and/or their equivalents may be implemented with computer executable instructions.
  • a non-transitory computer-readable medium is configured with stored computer executable instructions that when executed by a machine (e.g., processor, computer, and so on) cause the machine (and/or associated components) to perform the method.
  • a machine e.g., processor, computer, and so on
  • the described systems, methods and/or their equivalents may be implemented in logic.
  • FIG. 5 illustrates an example computing device in which example systems and methods described herein, and equivalents, may operate.
  • the example computing device may be a computer 500 that includes a processor 502 , a memory 504 , and input/output ports 510 operably connected by a bus 508 .
  • the computer 500 may include a server side logic 530 configured to operate on a CRA application framework and allow a mobile device to function offline.
  • the server side logic 530 may be implemented in hardware, a non-transitory computer-readable medium with stored instructions, firmware, and/or combinations thereof. While the server side logic 530 is illustrated as a hardware component attached to the bus 508 , it is to be appreciated that in one example, the server side logic 530 could be implemented in the processor 502 .
  • the server side logic 530 has means (e.g., hardware, non-transitory computer-readable medium, firmware) for combining a canonical trip report with metadata to create an SDO.
  • the means may be implemented, for example, as an ASIC programmed to create the SDO.
  • the means may also be implemented as stored computer executable instructions that are presented to computer 500 as data 516 that are temporarily stored in memory 504 and then executed by processor 502 .
  • the functionality of the server side logic may be implemented on a mobile device.
  • the processor 502 may be a variety of various processors including dual microprocessor and other multi-processor architectures.
  • a memory 504 may include volatile memory and/or non-volatile memory.
  • Non-volatile memory may include, for example, ROM, PROM, and so on.
  • Volatile memory may include, for example, RAM, SRAM, DRAM, and so on.
  • a disk 506 may be operably connected to the computer 500 via, for example, an input/output interface (e.g., card, device) 518 and an input/output port 510 .
  • the disk 506 may be, for example, a magnetic disk drive, a solid state disk drive, a floppy disk drive, a tape drive, a Zip drive, a flash memory card, a memory stick, and so on.
  • the disk 506 may be a CD-ROM drive, a CD-R drive, a CD-RW drive, a DVD ROM, and so on.
  • the memory 504 can store a process 514 and/or a data 516 , for example.
  • the disk 506 and/or the memory 504 can store an operating system that controls and allocates resources of the computer 500 .
  • the bus 508 may be a single internal bus interconnect architecture and/or other bus or mesh architectures. While a single bus is illustrated, it is to be appreciated that the computer 500 may communicate with various devices, logics, and peripherals using other busses (e.g., PCIE, 1394, USB, Ethernet).
  • the bus 508 can be types including, for example, a memory bus, a memory controller, a peripheral bus, an external bus, a crossbar switch, and/or a local bus.
  • the computer 500 may interact with input/output devices via the i/o interfaces 518 and the input/output ports 510 .
  • Input/output devices may be, for example, a keyboard, a microphone, a pointing and selection device, cameras, video cards, displays, the disk 506 , the network devices 520 , and so on.
  • the input/output ports 510 may include, for example, serial ports, parallel ports, and USB ports.
  • the computer 500 can operate in a network environment and thus may be connected to the network devices 520 via the i/o interfaces 518 , and/or the i/o ports 510 . Through the network devices 520 , the computer 500 may interact with a network. Through the network, the computer 500 may be logically connected to remote computers (e.g., mobile devices). Networks with which the computer 500 may interact include, but are not limited to, a LAN, a WAN, and other networks.
  • a non-transitory computer-readable medium is configured with stored computer executable instructions that when executed by a machine (e.g., processor, computer, and so on) cause the machine (and/or associated components) to perform the methods of FIGS. 1 and 2 .
  • a machine e.g., processor, computer, and so on
  • references to “one embodiment”, “an embodiment”, “one example”, “an example”, and so on, indicate that the embodiment(s) or example(s) so described may include a particular feature, structure, characteristic, property, element, or limitation, but that not every embodiment or example necessarily includes that particular feature, structure, characteristic, property, element or limitation. Furthermore, repeated use of the phrase “in one embodiment” does not necessarily refer to the same embodiment, though it may.
  • ASIC application specific integrated circuit
  • CD compact disk
  • CD-R CD recordable.
  • CD-RW CD rewriteable.
  • DVD digital versatile disk and/or digital video disk.
  • HTTP hypertext transfer protocol
  • LAN local area network
  • PCI peripheral component interconnect
  • PCIE PCI express.
  • RAM random access memory
  • DRAM dynamic RAM
  • SRAM synchronous RAM.
  • ROM read only memory
  • PROM programmable ROM.
  • EPROM erasable PROM.
  • USB universal serial bus
  • XML extensible markup language
  • WAN wide area network
  • Computer component refers to a computer-related entity (e.g., hardware, firmware, instructions in execution, combinations thereof).
  • Computer components may include, for example, a process running on a processor, a processor, an object, an executable, a thread of execution, and a computer.
  • a computer component(s) may reside within a process and/or thread.
  • a computer component may be localized on one computer and/or may be distributed between multiple computers.
  • Computer communication refers to a communication between computing devices (e.g., computer, personal digital assistant, cellular telephone) and can be, for example, a network transfer, a file transfer, an applet transfer, an email, an HTTP transfer, and so on.
  • a computer communication can occur across, for example, a wireless system (e.g., IEEE 802.11), an Ethernet system (e.g., IEEE 802.3), a token ring system (e.g., IEEE 802.5), a LAN, a WAN, a point-to-point system, a circuit switching system, a packet switching system, and so on.
  • Computer-readable medium refers to a non-transitory medium that stores instructions and/or data.
  • a computer-readable medium may take forms, including, but not limited to, non-volatile media, and volatile media.
  • Non-volatile media may include, for example, optical disks, magnetic disks, and so on.
  • Volatile media may include, for example, semiconductor memories, dynamic memory, and so on.
  • a computer-readable medium may include, but are not limited to, a floppy disk, a flexible disk, a hard disk, a magnetic tape, other magnetic medium, an ASIC, a CD, other optical medium, a RAM, a ROM, a memory chip or card, a memory stick, and other media from which a computer, a processor or other electronic device can read.
  • database is used to refer to a table. In other examples, “database” may be used to refer to a set of tables. In still other examples, “database” may refer to a set of data stores and methods for accessing and/or manipulating those data stores.
  • Logic includes but is not limited to hardware, firmware, a non-transitory computer readable medium that stores instructions, instructions in execution on a machine, and/or combinations of each to perform a function(s) or an action(s), and/or to cause a function or action from another logic, method, and/or system.
  • Logic may include a microprocessor controlled by an algorithm, a discrete logic (e.g., ASIC), an analog circuit, a digital circuit, a programmed logic device, a memory device containing instructions, and so on.
  • Logic may include one or more gates, combinations of gates, or other circuit components. Where multiple logics are described, it may be possible to incorporate the multiple logics into one physical logic. Similarly, where a single logic is described, it may be possible to distribute that single logic between multiple physical logics.
  • An “operable connection”, or a connection by which entities are “operably connected”, is one in which signals, physical communications, and/or logical communications may be sent and/or received.
  • An operable connection may include a physical interface, an electrical interface, and/or a data interface.
  • An operable connection may include differing combinations of interfaces and/or connections sufficient to allow operable control.
  • two entities can be operably connected to communicate signals to each other directly or through one or more intermediate entities (e.g., processor, operating system, logic, non-transitory computer-readable medium).
  • Logical and/or physical communication channels can be used to create an operable connection.
  • “User”, as used herein, includes but is not limited to one or more persons, computers or other devices, or combinations of these.
  • the phrase “one or more of, A, B, and C” is used herein, (e.g., a data store configured to store one or more of, A, B, and C) it is intended to convey the set of possibilities A, B, C, AB, AC, BC, and/or ABC (e.g., the data store may store only A, only B, only C, A&B, A&C, B&C, and/or A&B&C). It is not intended to require one of A, one of B, and one of C.
  • the applicants intend to indicate “at least one of A, at least one of B, and at least one of C”, then the phrasing “at least one of A, at least one of B, and at least one of C” will be used.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)
US13/827,073 2012-06-20 2013-03-14 Mobile clinical research associate framework for offline capability Abandoned US20130346107A1 (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
US13/827,073 US20130346107A1 (en) 2012-06-20 2013-03-14 Mobile clinical research associate framework for offline capability
JP2015518406A JP6261573B2 (ja) 2012-06-20 2013-05-15 オフライン機能のためのモバイル治験モニターフレームワーク
CN201380030137.5A CN104335212B (zh) 2012-06-20 2013-05-15 针对离线能力的移动临床研究员框架
EP13728269.5A EP2864950A4 (en) 2012-06-20 2013-05-15 FRAMEWORK FOR OFFLINE CAPACITY OF A MOBILE CLINICAL MONITOR
PCT/US2013/041096 WO2013191824A2 (en) 2012-06-20 2013-05-15 Mobile clinical research associate framework for offline capability
US16/810,066 US11693882B2 (en) 2012-06-20 2020-03-05 System and method for offline capability for mobile devices including asynchronous threads

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201261662050P 2012-06-20 2012-06-20
US13/827,073 US20130346107A1 (en) 2012-06-20 2013-03-14 Mobile clinical research associate framework for offline capability

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/810,066 Division US11693882B2 (en) 2012-06-20 2020-03-05 System and method for offline capability for mobile devices including asynchronous threads

Publications (1)

Publication Number Publication Date
US20130346107A1 true US20130346107A1 (en) 2013-12-26

Family

ID=48607350

Family Applications (2)

Application Number Title Priority Date Filing Date
US13/827,073 Abandoned US20130346107A1 (en) 2012-06-20 2013-03-14 Mobile clinical research associate framework for offline capability
US16/810,066 Active 2034-10-09 US11693882B2 (en) 2012-06-20 2020-03-05 System and method for offline capability for mobile devices including asynchronous threads

Family Applications After (1)

Application Number Title Priority Date Filing Date
US16/810,066 Active 2034-10-09 US11693882B2 (en) 2012-06-20 2020-03-05 System and method for offline capability for mobile devices including asynchronous threads

Country Status (5)

Country Link
US (2) US20130346107A1 (ja)
EP (1) EP2864950A4 (ja)
JP (1) JP6261573B2 (ja)
CN (1) CN104335212B (ja)
WO (1) WO2013191824A2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11986663B2 (en) 2020-12-11 2024-05-21 Medtronic, Inc. Interactive clinician reports for medical device therapy

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6480847B1 (en) * 1996-10-18 2002-11-12 Sagent Technology, Inc. Database repository with deferred transactions
US20050070259A1 (en) * 2003-09-30 2005-03-31 David Kloba Method and system for accessing applications and data, and for tracking of key indicators on mobile handheld devices
US20090248693A1 (en) * 2008-03-27 2009-10-01 Microsoft Corporation Managing data transfer between endpoints in a distributed computing environment
US20120101837A1 (en) * 2010-10-20 2012-04-26 Mccorkle Rae Ellen Systems and methods for managing clinical trial site visit reports

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5557798A (en) * 1989-07-27 1996-09-17 Tibco, Inc. Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US6035324A (en) * 1997-08-28 2000-03-07 International Business Machines Corporation Client-side asynchronous form management
US6904434B1 (en) * 2001-12-18 2005-06-07 Siebel Systems, Inc. Method and system for providing real-time clinical trial enrollment data
JP3609778B2 (ja) * 2001-12-26 2005-01-12 株式会社亀田医療情報研究所 双方向通信ネットワークによる医療情報提供・取得システム及び方法並びにコンピュータプログラム
JP2003280931A (ja) * 2002-03-22 2003-10-03 Nec Corp トランザクション処理システムおよび処理方法
US8200622B2 (en) * 2002-05-31 2012-06-12 Informatica Corporation System and method for integrating, managing and coordinating customer activities
GB2398893A (en) * 2003-02-27 2004-09-01 Cmed Group Ltd Hierarchical database system employing audit nodes
US20080256128A1 (en) * 2006-12-08 2008-10-16 Clinical Ink, Llc Systems and methods for source document management in clinical trials
US20080288275A1 (en) * 2007-05-14 2008-11-20 Numoda Technologies, Inc. Trip report management system for clinical monitoring
JP5035176B2 (ja) * 2008-08-21 2012-09-26 富士通株式会社 伝送システム、伝送装置および伝送方法
CA2744083A1 (en) * 2008-11-18 2010-05-27 Kim Nitahara Qualifying data and associated metadata during a data collection process
WO2011047200A2 (en) * 2009-10-14 2011-04-21 Great Connection, Inc. Systems and methods for converting and delivering medical images to mobile devices and remote communications systems

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6480847B1 (en) * 1996-10-18 2002-11-12 Sagent Technology, Inc. Database repository with deferred transactions
US20050070259A1 (en) * 2003-09-30 2005-03-31 David Kloba Method and system for accessing applications and data, and for tracking of key indicators on mobile handheld devices
US20090248693A1 (en) * 2008-03-27 2009-10-01 Microsoft Corporation Managing data transfer between endpoints in a distributed computing environment
US20120101837A1 (en) * 2010-10-20 2012-04-26 Mccorkle Rae Ellen Systems and methods for managing clinical trial site visit reports

Also Published As

Publication number Publication date
EP2864950A4 (en) 2016-06-22
WO2013191824A3 (en) 2014-05-08
JP2015529872A (ja) 2015-10-08
CN104335212B (zh) 2018-06-08
CN104335212A (zh) 2015-02-04
WO2013191824A2 (en) 2013-12-27
US11693882B2 (en) 2023-07-04
EP2864950A2 (en) 2015-04-29
US20200202991A1 (en) 2020-06-25
JP6261573B2 (ja) 2018-01-17

Similar Documents

Publication Publication Date Title
US11429677B2 (en) Sharing common metadata in multi-tenant environment
US11507583B2 (en) Tuple extraction using dynamically generated extractor classes
RU2536379C2 (ru) Способ и система для обеспечения удаленного доступа к состоянию прикладной программы
JP6832347B2 (ja) 分散型システムにおける多段階処理のためのイベント順序の保証
US9613520B2 (en) Real-time event communication and management system, method and computer program product
Esposito et al. An event-based notification approach for the delivery of patient medical information
CN106990970B (zh) 基于mvc动态页面生成方法及系统
Kraus et al. Integrating Arden-Syntax-based clinical decision support with extended presentation formats into a commercial patient data management system
US11693882B2 (en) System and method for offline capability for mobile devices including asynchronous threads
US9747415B2 (en) Single schema-based RIS/PACS integration
CN113312052A (zh) 一种组件调用方法、装置、电子设备以及存储介质
US10216903B2 (en) Medical adherence tracking framework
CN113961569B (zh) 一种医疗数据etl任务同步方法和装置
JP6858603B2 (ja) 傷病名変更情報出力プログラム、傷病名変更情報出力システム、および、傷病名変更情報出力方法
US20160357912A1 (en) System for unitary display of patient data from mulitple care providers
Van Den Bossche et al. Design of a JAIN SLEE/ESB-based platform for routing medical data in the ICU
EP2972825B1 (en) Hybrid service-oriented computing architecture
US20090300654A1 (en) Collection access in a parallel environment
Di Dia et al. Augmented-Reality-Based Real-Time Patient Information for Nursing
Feinberg et al. Predictors of emergency room (ER) visits and hospitalizations in patients with mantle cell lymphoma (MCL) treated with chemotherapy
An et al. 1495-P: Incidence of Early Diabetes Complications among Patients Newly Diagnosed with Type 2 Diabetes
Wang et al. Wait Times and Bed Capacity for Hematopoietic Cell Transplantation in Ontario: A System Dynamics Model
JP2015529872A5 (ja)
US20160316040A1 (en) Providing pipeline for unified service and client interface
CN112468543A (zh) 发布信息的方法、装置、设备和计算机可读介质

Legal Events

Date Code Title Description
AS Assignment

Owner name: ORACLE INTERNATIONAL CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LYNES, MATTHEW;MATSKIV, VICTOR;THOMAS, JAYANT;SIGNING DATES FROM 20130416 TO 20130426;REEL/FRAME:030295/0412

STCV Information on status: appeal procedure

Free format text: ON APPEAL -- AWAITING DECISION BY THE BOARD OF APPEALS

STCV Information on status: appeal procedure

Free format text: BOARD OF APPEALS DECISION RENDERED

STCB Information on status: application discontinuation

Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION