elij

Microscopy is also the limiting factor in _developed_ areas when it comes to urinalysis which I'm sure this solution can easily be adapted for.

There are a few aspects of this and I can only talk from the point of view in healthcare in the UK.

In the care settings Apple has been able to pull at the hearts and minds of care providers and I’ve seen a pull from doctors about making use of apple hardware (and software) whether it has a use/or is a supported platform.

If Apple went for the care settings market they could very easily disrupt the incumbents (in the same way that they did with portable media and the mobile phone) because it quite frankly isn’t that hard. There are many examples of a technically superior product [0] gaining market share in a short period in healthcare and a technology company could easily do that.

However in practice I’m pretty sure that EHR (and care records in general) are going to move to a patient owned model. This would probably mean some provider outside actually owning and storing the data but patients being mindful of their right to have access to general data (not only have access to but act on).

Things that patients could quite easily take from the care settings and make good use of are blood work, actual infection names (most infections result in antibiotics prescribed without the patient being told which organism it is), height/weight, all of their vital signs etc.

In terms of HL7 v2 — it’s not ideal however it is super lightweight — XML (i.e. HL7 v3) is not a good fit for high throughput transactional data (outside of healthcare see BSON, protobufs etc.) HL7 v2 largely suffers from issues around interpretation. There’s a great initiative called FIHR [1] which could help a lot when it comes to CCD.

Kings College Hospital have opened up their HIE [2] which uses a few off the shelve open source components to make working with HL7 very easy.

[0] EMIS/INPS vs TPP in the UK comes to mind. The TPP product pushed EMIS (and more recently INPS) to really up their game.

[1] http://www.hl7.org/implement/standards/fhir/

[2] https://github.com/KingsCollegeHospital/rassyeyanie

Sorry about the multiple submissions (won't happen again) -- I've got the learning passes working quite well but really need interest (a critical mass of voters and comparisons) to perfect it.

I don't know the best approach to achieve this.

Deployments using source control probably aren't wise for most cases -- the index, for the most part, is always growing.

Currently working on an approach that would avoid this type of gaming of rankings by changing the way we collect ratings: https://aeolipyle.co/

yup -- I believe this is a better user experience in terms of capturing ratings (by capitalising on the availability heuristic)

What you're describing technically would work when each person compares every item (and would fall into the domain of condorcet methods).

However in practice the election becomes a graph (rather than list or x/y table) with cyclical dependencies and conflicting comparisons -- it becomes quite hard to resolve -- but it can be.

After you view content (ideally immutable content like a film, music, books or computer games) -- when you offer to rate you are instead promoted on how it faired vs a previous experience. "You've just seen Terminator 2 -- how is it compared to The Matrix?)

In terms of algorithm it's got around issues of merging incomplete Condorcet elections (as not everyone will compare or rank every item) and clustering.

Turning these partial elections into a single order ranking.

A site to discover content using an algorithm that ignores metrics we have begun to game (likes and viewings) and instead builds rankings based on pairwise comparisons.

Would allow discovery of new good content that hasn't employed growth hacks and will also differentiate between equally rated content.

https://aeolipyle.co (algorithm complete -- need to find good use for it.)

iPLATO Healthcare, London, UK (http://www.iplato.net)

We are working on revolutionising the patient healthcare mobile experience in the UK (a market we already lead in) by furthering the healthcare available on the patient's terms.

If you like solving hard problems and love the feel of a start up then join us.

You will be working on the highest throughput mobile patient interaction platform, improving on great mobile UX and helping to make the use of the NHS a great experience.

We are looking for software engineers with:

    5+ years’ experience.
    Strong imperative programming (Java/C++/C# etc.)
    Previous work on a scalable system (message brokers, RDMS optimisation, distributed caching etc.)
    GNU/Linux and basic shell scripting.
    Familiarity with Scrum/kanban methodologies.
    Experience working with TDD/BDD.
    Chef/Puppet/Salt for configuration management.
    Experience with continuous integration/lint with Jenkins/Tinderbox etc.
    Proficient using Git.
    A functional programming language (Clojure, Scala, Haskell etc.)
    Cloud compute provisioning (through VMWare, Openstack, Rackspace etc.)
    Knowledge of highly distributed file systems like HDFS/GlusterFS.

Experience in the NHS or with supervised statistical classification being a distinct advantage.

Please contact me to discuss any of the above: elijah.charles@iplato.net

iPLATO Healthcare, London, UK (http://www.iplato.net)

We are working on revolutionising the patient healthcare mobile experience in the UK (a market we already lead in) by furthering the healthcare available on the patient's terms.

If you like solving hard problems and love the feel of a start up then join us.

You will be working on the highest throughput mobile patient interaction platform, improving on great mobile UX and helping to make the use of the NHS a great experience.

We are looking for software engineers with:

    5+ years’ experience.
    Strong imperative programming (Java/C++/C# etc.)
    Previous work on a scalable system (message brokers, RDMS optimisation, distributed caching etc.)
    GNU/Linux and basic shell scripting.
    Familiarity with Scrum/kanban methodologies.
    Experience working with TDD/BDD.
    Chef/Puppet/Salt for configuration management.
    Experience with continuous integration/lint with Jenkins/Tinderbox etc.
    Proficient using Git.
    A functional programming language (Clojure, Scala, Haskell etc.)
    Cloud compute provisioning (through VMWare, Openstack, Rackspace etc.)
    Knowledge of highly distributed file systems like HDFS/GlusterFS.

Experience in the NHS or with supervised statistical classification being a distinct advantage.

Please contact me to discuss any of the above: elijah.charles@iplato.net

iPLATO Healthcare, London, UK (http://www.iplato.net)

We are working on revolutionising the patient healthcare mobile experience in the UK (a market we already lead in) by furthering the healthcare available on the patient's terms.

If you like solving hard problems and love the feel of a start up then join us.

You will be working on the highest throughput mobile patient interaction platform, improving on great mobile UX and helping to make the use of the NHS a great experience.

We are looking for:

System engineers with experience of Cisco IOS/NX-OS, VMWare/Openstack, chef/puppet/salt, nagios/icinga, GNU/Linux

Software engineers with great imperative and functional programming skills in a high throughput middleware world

Front end engineers for mobile platforms

Experience in the NHS or with supervised statistical classification being a distinct advantage.

Please contact me to discuss any of the above: elijah.charles@iplato.net

if you don't need http/https/svn/gtk support then git can be built without perl, curl, git-svn, python etc. installed

elijah.charles

elijah.charles@gmail.com thanks!

Dell UltraSharp (3008WFP) -- most real estate possible in a single panel

The key tenant to agile is built in 'tolerance' for change in resource and scope with emphasis on pipeline management instead of scheduling.

The reason why classic forms of development fail is because these issues (changes) were the exception instead of the rule in methodologies leading up to the 'agile' generation

You can't get low latency and high throughput with HTTP overhead. The headers will be bigger than transactions for starters.