Bibliographic record
Abstract
Sir, The introduction of smart phone mobile devices with dedicated apps, has ushered an era of pervasive technology in our personal and professional lives. A recent survey by d4 (independent United Kingdom-based charity with a focus on mobile technology for health care professionals) found that up to 80% of health professionals used smart phones (phone enabled for internet or email use) at their work space.[1] Although since its launch in 2008, the Apple App Store (Apple, CA, USA) has seen availability of more than 10,00,000 apps, the figure for medical apps (including health and fitness) is a just above 20000, which is an abysmal 2% of all available apps.[2] It is clear that mobile medical apps hold huge potential, both as personal tools to improve academic portfolio management, and as tools for improving patient care. Usage of apps for management of on-call commitments, logbook management, and registering academic portfolios are fast-becoming a standard on the smart phones of western trainees. At the same time usage of textbooks, references, and other dedicated apps at the point of care are enhancing patient management. Despite this, it is notable that the medical profession involvement with mobile app development is negligible, and there are issues concerning app quality evaluation, regulation, and information security. Since app development requires an in-depth knowledge of coding languages (JAVA, X-code, or C++), the lack of it is in our case (medical professionals) is the most obvious impediment to active participation. However, all is not lost. There are several established and new upcoming services addressing this very expanse. The (Massachusetts Institute of Technology, US) “App Inventor” is a web browser based android app development platform that enables any end user to create mobile services and applications.[3] This allows an individual to engage as a mobile app developer regardless of their computer programming backgrounds. The program uses Google mail login services and is completely free. The app inventor platform uses a “palette” for app component addition, which is then customized and viewed on the “viewer”. Once ready, the app is opened on “block editor” to allow visualization on an android phone “emulator.” The final app can be downloaded or distributed as an Android Application Package file. However, this method can be fairly complicated. The “Buzztouch” service uses another approach wherein apps components (plug-ins such as content, menus, and media) are assembled into an app on a customized propriety platform, and then downloaded as source code file.[4] The latter is imported onto X-code (for Apple) or eclipse (for android) for testing and processing into an app. At present, this service comes at the expense (monthly or yearly) and is not fairly straight forward. However, the features available for app content are among the best available and the apps can be generated for both Apple and Android platforms. Perhaps the easiest way to generate an app is using the website based platforms such as “IBuildApp.”[5] They are free (or subscription based), easy to use, and allow a visual creation of an app as you want. However, features may be limited, and some may not work. Clearly, this seems to be a work in progress. Pleasantly, the service supports both Apple and Android platforms and allows distribution to their respective app stores. The recently held “NHS Hack Day” in London saw the convergence of clinicians, computer programmers, and web designers on a common platform in an effort to build medical software tools and smart phone “Apps”.[6] These platforms have provided a much-needed adrenaline shot to the wonderful world of medical apps that has shown promise, but has failed to deliver thus far!
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.008 | 0.037 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.002 | 0.002 |
| Science and technology studies | 0.003 | 0.005 |
| Scholarly communication | 0.014 | 0.021 |
| Open science | 0.002 | 0.006 |
| Research integrity | 0.009 | 0.014 |
| Insufficient payload (model declined to judge) | 0.020 | 0.015 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".