Every so often I get bored of what I am doing and start trying to draw one of those ‘services roadmap’ kind of diagrams for e-Health. These pretty pictures appear in slide presentations, standards, whitepapers etc, but are not often used as a tool to help map out the road ahead, mainly because (I think) they mix too many conceptual levels together. We do however need some sort of vision of the future for defining services. I like my latest version enough that I thought it would be worth putting up publicly to get reactions and input. Please comment and/or add content to the wiki page.
wolandscat
Woland's cat 
Excellent work.
The only comment I would make is that in my view ‘Patient State’ from a HCP perspective is more than ‘Telemetry State’ & ‘Vital Signs’. I would argue that it includes ‘Current *active* interventions (investigations & treatments) that have or may have a causal effect on ‘Patient State’ presently and/or enduring within the timeframe the HCP is directly responsible for her or him. For example, medications the patient is currently taking, being on a ventilator, presence of a line, IVs being administered, Blood products being administered and so forth. At the very least these give an important if not essential context to the ‘Telemetry State’ & ‘Vital Signs’. For example, a clinician would want to know the haemoglobin is still low *after* a transfusion, or heart rate/respiration decreasing significantly during/after administration of morphine. Heart rate/respiration isolated can mean a lot of things … And no doubt my clinical colleagues could provide a lot more examples. In other words, the ‘Patient Summary’ in the ‘Patient Perspective’ is *also* an essential element of the ‘Health Provider Perspective’ for the ‘Patient State’. The diagram does not quite convey that element, although in any built system that has all these elements and an appropriate UX could supply what is required.
The only other thing to ‘Patient State’ that I would add would be contemporanous reports about their state that may be gleaned from: (1) talking to them directly, “I feel like I want to throw up nurse.”; (2) observations from clinicians about their state, “Patient is unconscious and very pale with a distinct blueness around the mouth.”; or (3) certain kinds of measures of state inputed by patients, such as various patient reported outcome measures (PROMs). You might call these ‘Observations’, but my conception is a bit richer than what is normally understood by these.
Pretty much all of that is taken care of via the ‘EHR’ service, which is in the middle left of the diagram – this is because all content is archetype-based, and can generically be written and retrieved by that one service. The few things I have pulled out as separate services are things for which a dedicated transactional interface is useful, e.g. medications list and so on. These we can imagine having functions like ‘add_medication(..)’, ‘suspend_medication(…)’ etc, and they will know what the correct openEHR archetypes and structures are to use. We may need an extra service that is designed for input of patient data, relating to certain kinds of data, e.g. diabetic or whatever. The default however is that applications know about their data and always just use the appropriate archetypes and templates.