An EHR system is a complicated piece of software to design. Instead of tackling it as a whole, I've decided to split the problem up into 4 separate areas:
Storage Format - How do you represent healthcare information in an EHR system?
Authentication - How do you verify that somebody has access to a record - and what parts of the record do they have access to?
Networking - How will the record be transmitted and shared between all parties?
User Interface - How does the end user interact with this system - and how would software interact with this system?
While there are interactions between these areas, they clearly divide the problem up. This way I can conceptualize and iterate on small problems faster, then select the most successful outcomes, then combine them to create the final system.
When assessing how successful concepts are, I'm looking at three separate qualities, which relate to the goals discussed in the brief:
Potential impact - Could this idea have a large impact on NZ health IT, and more specifically, how could it address the three issues of Complexity, Risk, and Distribution?
Feasibility - Is this concepts reasonably achievable? I don't want to create a design proposal of a system which wouldn't be able to be built. This project is not a speculative design project - all concepts must have firm evidence of feasibility.
Uniqueness - While I will look at existing solutions to these problems, there is opportunity and value to assess unique approaches.
So, with that out of the way, lets move onto the logically first problem to tackle - storage.