Monday, June 9, 2014

Holiday task number 3: Write some more of this silly story

I came up with a concept for a Blender movie / game / book a year or so ago.  Probably crap, but comments are welcome.

It's only at skeleton stage...

https://docs.google.com/document/d/1fT0bcU2Z_bX3-ax29IQ8WAFQUVt-_TQj45mFqGtFZy0/edit?usp=sharing


Thursday, October 24, 2013

eHealth system up and running

A few posts ago, I mentioned an assignment (for my Paramedic Practice degree) for a small fictional town's health clinic, some appointment rooms, and some remote health professionals that are employed a few days a week.

Well, some planning was done, and some code was in production.

That was until my head of school discovered a Paramedic student was doing a Postgraduate eHealth unit, and promptly un-enrolled me. But that was quickly fixed.

I knew the Uni wanted the traditional old 3rd normal form normalisation, and usual tables containing contacts, and so all that was done.

The real tasty bit was the data-defined application idea I had. I ended up calling it 'LinkPin'.

In a nutshell, and to draw on a terrible analogy:
You write pieces to code to render/manage a type of data(section, group, phone number, digital asset, etc).
You create a simple table structure that allows these 'links' to be connected together, partially like a hierarchy, and partially intended to plan the navigation through a software package.

So after 'Pinning' these 'Link' together, wherever the application is pointing to along this chain (or waterfall of links), it knows how to render the link under it, and any descending from it.

It can produce a user interface that is defined by the data structures under it, not trying to fit data into a structure.

Nevertheless, implementing this would have taken some time.

So I knocked together the application, and handed it in.

Naturally, I used the tools I know and love: PHP, FirebirdSQL, a splash of CSS, and a dollop of HTML.


Its feature set:

  • Client management, current and outdated contact information(historical support)
  • Bookings to see specialists, and notes system to go with the consultancy
  • Booking screen with calendar for each specialist, and automatic blocking out for longer appointments.
  • Daily run sheets for specialists (so they can see their appointment load in the morning)
  • Payment status reports on appointments
  • Reports on Specialist's booking loads, and booking trends for hour of the day
  • Outstanding account reports
  • A WebRTC TeleHealth system for remote client and specialist consultancy
  • ...and more. Oh yes, role-based access control(rudimentary)


I had it hooked up to analytics.google.com, and noticed it was suddenly getting some traffic. Then an email arrived:

Hi Nigel,
Your assignment 3 result: 95%
For details please refer to the PDF file in MyLO. If you have any queries or concerns, please do not hesitate to contact me.
An excellent assignment and a great way to finish the unit. Good luck with the rest of your studies.

It was chuffed! They liked it!
So here it is for you all to play with: http://hopetounregional.com/
(Note: It's no where near production ready, and if it gets abused, I'll rip it down pretty quick...)

If you'd like to see some of the sources behind it, put the words /bookings/ehealth_submission.tgz on the end.

There should be an .sql file in there with the LinkPin architecture. If anyone want's to collaborate on a project, let me know!

N

Sunday, October 20, 2013

First Moodle installation

Had an enquiry about a collaborative system for a research organisation, and I thought, "What better than a Learning Management System (LMS)"

A quick bit of jiggery pokery with Moodle and GoDaddy's outdated MySQL services, and it's alive!

http://foodplantsinternational.org/

Now, to wait for the organisation to realise what they have, and get excited!!

N.

Monday, September 23, 2013

eHealth App Nearly Done

A bit of PHP, a little HTML/CSS and jscript, and it's nearly up and running.

http://karbonindustries.com/health/

If you do read this, please expect some changes to the code as I work on it... :)


Wednesday, August 7, 2013

E-Health project for Uni of Tas: Where to start is easy. Where to stop is the hard part

Yes, I'm doing more health informatics, but this project has a brief set out by the unit coordinator - build an eHealth application for a small fictional town, with a few thousand fictional residents, a sprinkling of clinics and pharmacies, one hospital, and an ambulance service.

There's more to the brief than that, but that'll do for now.

So I got researching the current landscape of eHealth, and found a myriad of vertical solutions for specific problems or procedures, which although they do their featureset proud, interconnecting with other systems up and down the chain appears to be a hideous nightmare.

Then there are bold and brave endeavours like the Australian Govt's eHealth, NEHTA, and the personally controlled electronic health record system, which look fantastic to integrate with (HL7 interconnects, SSL with great certificate management), they are now waiting for more (quite a few already have) software vendors to integrate the NEHTA network with their apps.

So I got thinking...

If the city...no, lets go bigger. If the state's infrastructure were destroyed, and we had to start again from scratch, would we reinstate the little verticals with their strengths and weaknesses, or would we step back, sip a cup of tea amidst our wreck of a civilisation, and consider what we would want feom a holistic health system.

Would we start with traditional requirements engineering of a process, function, or business unit, and hope to additionally design in communication methods built to a standard that other e-prescription, clinical handover, or referral steps to other health provider's systems.

Would we start with an eHealth record management system, and decree that all applications communicate to/via/with it?

Or could we look at who the focus of health should be: the client. You.
Maybe we're writing applications to provide management of your data, and we are forced to make the client work with the system.  We are required to make the health information fit in the box, the entities and relationships that someone decreed, and that's it.

What if the information that was stored was flexible, organic, and could evolve at any time.
What if any application that connected to it was able to adapt on the fly to any change in information hierarchy, inheritance of objects, re-linking of objects?

One scenario got me thinking.
Imagine a family living in a house. 2 guardians, and 3 kids. All happy.

The Entities to store this are easy: one address record in an address table, and 4 contact records in a contacts table with a foreign key to the one address.

Now comes the spanner towards the works.

One of the guardians, for one reason or another, needs to live at address 1 from Sun through to Wednesday, and another address 2 from Thursday through Saturday.

For sure, they'd just pick the mail from their old address when they came around again, but hopefully it highlights a point that if we could allow data, it's structure, and it's constraints to evolve and change, what would our applications look like?


Wednesday, May 15, 2013

Quick Sketch of LabelSleuth

Just recording some design considerations of the LabelSleuth (if that be it's name) :) Graphics similar to mindmap. Central theme(total energy), with branches to seperate components (energy sources(Fat/Carb/Sugars))

Augmented Reality Health Informatics: LabelSleuth (product nutrition information interpreter)

Roughing out a new idea, and documenting here with a datestamp (IP / copyright) LabelSleuth Small app for mobile devices / google glass. Maybe HTML5 using wikitude.com or similar tech. allows camera in device to scan for barcodes of products in view. Quick lookup against cloud database for product informatics, and presents health and nutrition information to the viewer / operator. Information would be superimposed on top of view, and move with visuals as operator moved around. Ideal for comparing product's health information, and understand health information on the labels. Competing products in view could even be displayed if device camera was able to read barcodes as well.